(dev и release)

Интересует особенность работы с непротестированными доработками, когда работа закончена, в хранилище выгружено, но тестирование тестировщиками/пользователями не выполнялось, а рабочую базу обновлять из хранилища уже нужно.

(0) Пока тестирование не прошло не обновлять.
Как вариант временно выключить не проверенные модули потом обновить и опять включить свой модуль продолжить тестировать.

Могу конечно ошибиться но так есть..

(0) Обновляйте помолясь...

(0) а что тут собсна обсуждать?

обновляете базу release из dev, загоняете туда тестировщиков. исправляете ошибки в обеих базах.

исправили ошибки - обновляете прод.

что тут еще придумать можно?

(0) слова надо особые знать! Записывай: "Отче наш, иже еси на небеси..."

есть практика, которую SAP у себя зашил в ПО, это когда нельзя провести обновления в реальную базу без предварительного обновления в тестовую базу, после тестирования в которой можно далее проводить обновление в продакшн.

если попробовать реализовать такое, то получается, что для разработчиков имеется хранилище, и ответственный админ/разработчик переносит готовое к тестированию либо в хранилище для тестировщиков, либо в отдельную "царь базу" тестирования, на которой все проводят тестирования (имею ввиду уже не разработчики).

тогда ваша работа будет выглядеть так:
base_development + repository (development)
base_testing + repository (testing)
base_poduction

но это все так, баловство, если посмотреть "правильные выступления" то надо slack, git, vanessa, все это приправлено DevOpsом, который за этим всем следит, то можете почувствовать что выбрали не ту профессию и пора переквалифицироваться в электрика, оператора станка ЧПУ и прочее )

(7) Да, потому и задал вопрос об УДОБНОЙ работе с хранилищем, а не разведение бюрократии и введение новых должностей в цепочку ради поддержания цепочки.

(8) то что в (7) это не бессмысленная бюрократия, это правильно, технологически красиво, но объем ваших задач и бюджет на их решение скорей всего не соответствует приведенной схеме работы

(0) Логично что два хранилища конфигураций завести dev и prod/release
Разработка и первое тестирование в хране dev
Затем перенос ручками или через cf в хран release, там окончательное тестирование перед переносом на прод и обновление прода

Была практика использования 3-х хранилищ: dec/qa/prod.
Разработчики коммитят в dev, тестируют в своей базе и если все ок, просят администратора перенести изменения только по необходимым объектам в qa.
Далее тестируется в qa и если все ок, то также пообъектно переносится в prod.

(11) администратора ?
отдельно выделенного прога?

а если там для переноса надо много перелопатить для совмещения?
ну последовательность задач нарушилась например

(12) ну да, администратора, т.к. его время стоит дешевле.
В целом, это пообъектный метод, если же какие-то определенные процедуры/функции, то явно указывается.

Необходимый список изменений можно получить, если взять за правило комитить в хранилище с определенным комментарием, например #123. Тогда и все изменения можно выгрузить платформенно. На Infostart`е была даже какая-то подобная конфигурация

(13) Эмм.
При большой реальной разработке очень часты ситуации когда задача зависает в тесте не на дни или недели а месяцы.

И уже вперед помещаются в прод более поздние задачи, которые в дев сделаны с учетом что там код более старых задач (зависших на тесте)

Каким местом можно это легко перенести если процедуры/функции и даже метаданные отличаются.
И требуется нехилый уровень чтобы правильно перенести/совместить с переделкой.

А потом еще раз когда зависшая задача из теста в прод пойдет.

А еще могут напрямую в проде (сервис или сами проектные) править, не помещая свои изменения в дев...

1. рабочая база НЕ подключена к хранилищу
2. на рабочую базу все обновления всегда накатывает ОДИН человек
3. хранилище общее на всех разрабов, разрабы в хранилище кладут только функционал который сами проверели (тут важно не класть "полуфабрикаты")
4. тестировщик получает из хранилища и тестирует в своей базе, если все устраивает маркирует все изменения в хранилище номером версии и передает ее "накатывателю"
5. "накатыватель" (если принимает решение накатить) на базе тестировщика меняет версию (и версию кладет в общее хранилище) сохраняет cf и ее накатывает на продакт, заодно описывает/закрывает задачи учетной системе

(15)
Где хранятся "полуфабрикаты"?
Хранить их в базе/базах разрабов это опасно и неудобно, как другим следить за прогрессом и как совместная разработка?

(15) То что ты описал это очень небольшая проектная командочка
И маленький проект или уже саппорт, после завершения проекта

В реальном проекте когда много разрабов и текучка (она обязательна в больших командах) даже промежуточные "полуфабрикаты" надо куда-то складывать в общее хранилище
Обычно переходят с хранов на Гит и туда помещают все что наработано за день в свою ветку задачи
И уже когда готово пулл-реквест идет в общую ветку на тест

(17) гит для 1с ну очень не удобен (хотя я понимаю есть секта свидетелей гит и их разубедить невозможно)
(16) обычно есть некий "архитектор" он накидывает новых объектов уже в привязке к правам и подсистемам, далее разрабы работают с конкретными модулями/формами

по поводу "ветка задачи" большинство задач это менее 1 дня, крупные задачи как правило следует дробить на более мелкие. По этому заводить ветку на задачу просто не имеет смысла.

Сделал задачу, сам проверил - положил в хранилище.
В твоей схеме должен быть отдельный человек который из кучи веток собирает релиз (каждый день), это наверно удобно для конечных разрабов (они не парятся на предмет совместимости доработок) и разумеется это очень удобно когда ты даешь конкретные задачи "на сторону и когда текучка", но когда свой собственный отдел из пяти человек то это абсолютно не удобно, а отдел в 5...10 человек тянут практически любой большой проект.

(18) Гит для 1С да, не очень
Только хардкор, только перфокарты, старая школа

(18)

Некоторые задачи невозможно дробить на мелкие
Ибо они взаимосвязаны и должен один делать чтобы погрузиться и не мешать друг другу


Все не так
Это надо изучить и попробовать, чтобы понимать как оно работает
Не требуется никакой отдельный человек чтобы из веток собирать релиз, точней это любой может в любой момент

а что, схему "куяк куяк и в продакшн" уже отменили?...

(0) погугли технологию разветвлённой разработки, через гноилище

+(22) по сути это тот же github flow