Посоветуйте как правильно организовать работу в отделе (1С + Git)

#1

Имеется хранилище 1С (develop), разработчики захватывают объекты, изменяют, возвращают.
Тестировщики обновляют свои базы из хранилища и проверяют работы (по заявкам). Получается в одном хранилище и проверенные работы и не проверенные. Если тестировщик работу принял, он вносит изменения в боевую базу (изменения касающиеся только конкретной заявки).
При этой схеме и вносить изменения в боевую сложно, и тесты нигде не задействованы. Хотя бы минимальный заслон поставить между разработчиками и внесение их работ в DEVELOP.

Как бы это всё красиво организовать?
Сейчас есть хранилище GIT куда сливаются develop и master, через gitsync.

#2

Посмотрите в сторону ветвления хранилищ. Новая фича - новое хранилище. Технология описана на ИТС

#3

Именно хранилищ 1С ?

Сейчас остановились на варианте ветвиться от master по выполняемой задаче/фичи, после генерить CF и объединять с Develop/Master.
Но нужно как-то заслон в виде тестов на каком-то этапе установить. До внесения изменений от разработчика в Develop.

#4

https://its.1c.ru/db/v8std#content:-2145782938:hdoc:_top:стандарты%20разработки%20разветвленная
Это имеется в виду?

#5

Сделайте между тестовой БД и продуктивной еще одну - препрод, На препроде тестируйте и после удачных тестов переносите в продуктив

#6

Вы описали как сейчас это и работает. Тестировщик врукопашную проверяет. БДД ) Нужно разработчика разворачивать если сборка упала. Например синтаксический контроль.

#7

Да, оно. Вы просто выбирайте, либо вы честно ветвитесь в гите без хранилища, либо ветвитесь хранилищами. Но без хранилища будет тяжело и может быть долго на первом этапе. Есть прецеденты успешной работы в таком режиме (например, @theshadowco будет рассказывать на грядущем ИЭ), но нужна определённая компетенция, чтобы это не доставляло неудобств.

#8

Если вы про советы, то попробуйте переименовать тестировщиков в группу “контроля качества и релиз инженерии” - это первое

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

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

Это фаза про “правильную организацию работы”. Соответственно - как уже правильно было замечено подобные изменения потребуют применения автоматизированных средств на каждом этапе - постановке, разработке, релиз-инженерии. Одним из которых является консольное приложение git и GIT сервер.