Организация групповой разработки

Проектный кейс: Организация групповой разработки

Схема объединения разработки

Для разработки конфигурации было принято решение использовать следующую схему: 

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

Этап 1: Разработка

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

Также он добавляет задачу в общий файл описания релизов. Данный файл имеет следующую структуру:

• Номер релиза;

• Краткое описание задачи;

• Номер задачи;

• Разработчик;

• Аналитик;

• Дата выполнения тестирования на базе разработчика;

• Дата помещения доработок в тестовую базу;

• Дата проверки аналитиком доработок в тестовой базе;

• Дата выпуска релиза;

• Список измененных объектов метаданных;

• Комментарий для сборщика релиза.

Общий файл описания релизов

Каждый разработчик фиксирует:

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

Этап 2: Тестирование

1. после завершения реализации задачи аналитик проверяет доработки на базе разработчика;
2. при наличии правок возвращает задачу на исправление;
3. после успешного тестирования он проставляет в файле описания релизов в соответствующей строке задачи дату тестирования на базе разработчика и дает разрешение разработчику на помещение изменений в хранилище и перенос в тестовую базу;
4. аналитик снова проверяет доработки, но уже на общей тестовой базе с “боевыми” данными;
5. после окончания тестирования доработок он отмечает в файле дату проверки на тестовой базе.

Этап 3:  Выпуск внутреннего релиза

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

• Заходит тестовую базу в режиме Конфигуратор и вызывает сборку поставки: Поставка - Создать файл поставки; 

• Заходит в рабочую базу в режиме конфигуратора и обновляет основную конфигурацию файлом поставки: Поддержка - Обновить конфигурацию - Выбрать файл поставки;

• Блокирует работу пользователей в базе;

• Обновляет конфигурацию базы данных;

• Разрешает работу пользователей и оповещает их о возможности начать работу.

После обновления ответственный проставляет дату выпуска релиза по каждой задаче, которая вошла в этот релиз. Если по каким-то причинам доработки по задаче не попали в релиз, ответственный переносит строку с задачей в новый релиз и в комментариях описывает причину непопадания.

Такой подход позволяет:

• минимизировать количество ошибок в “боевой” базе, т.к. непротестированные изменения не будут перенесены и не смогут нарушить работу пользователей;
• обеспечить полное отсутствие необходимости объединять изменения разработчиков и контролировать целостность структуры конфигурации, за нас это делает хранилище;
• откатиться к предыдущей версии в случае ошибки.

Данный метод имеет и свои минусы, например, невозможность одновременной работы с одним объектом нескольким разработчикам. В нашем случае этот подход являлся самым оптимальным, т.к. численность команды была относительно небольшой и задачи разработчиков практически не пересекались по объектам метаданных. Имеются также более простые и более сложные схемы, о которых можно прочитать в статьях https://infostart.ru/1c/articles/646867/ и https://its.1c.ru/db/v8std/content/709/hdoc.