Автор: Никишова Елизавета, Петрухин Пётр
Проектный кейс: Организация групповой разработки
Для разработки конфигурации было принято решение использовать следующую схему:
- создано одно общее хранилище, к которому были подключены базы разработчиков (у каждого разработчика своя отдельная база)
- общая тестовая база, которая периодически (в идеале один раз в сутки) выгружалась из продуктивной.
Этап 1: Разработка
Разработчик выполняет доработки по задаче (получает объекты из хранилища и производит их модификацию), производит первичное тестирование и передает ее на проверку аналитику.
Также он добавляет задачу в общий файл описания релизов. Данный файл имеет следующую структуру:
-
Номер релиза;
-
Краткое описание задачи;
-
Номер задачи;
-
Разработчик;
-
Аналитик;
-
Дата выполнения тестирования на базе разработчика;
-
Дата помещения доработок в тестовую базу;
-
Дата проверки аналитиком доработок в тестовой базе;
-
Дата выпуска релиза;
-
Список измененных объектов метаданных;
-
Комментарий для сборщика релиза.
Каждый разработчик фиксирует:
- краткое описание задачи,
- ее номер,
- измененные объекты метаданных,
- свое имя и имя проверяющего,
- дату помещения в тестовую базу (после проверки аналитиком),
- комментарий для ответственного за выпуск релиза.
Этап 2: Тестирование
- после завершения реализации задачи аналитик проверяет доработки на базе разработчика;
- при наличии правок возвращает задачу на исправление;
- после успешного тестирования он проставляет в файле описания релизов в соответствующей строке задачи дату тестирования на базе разработчика и дает разрешение разработчику на помещение изменений в хранилище и перенос в тестовую базу;
- аналитик снова проверяет доработки, но уже на общей тестовой базе с “боевыми” данными;
- после окончания тестирования доработок он отмечает в файле дату проверки на тестовой базе.
Этап 3: Выпуск внутреннего релиза
После того, как все доработки, помещенные в тестовую базу, проверены аналитиками, можно выпускать релиз, это делает ответственный за выпуск релиза. Ответственный за выпуск релиза выполняет следующие действия:
-
Заходит тестовую базу в режиме Конфигуратор и вызывает сборку поставки: Поставка - Создать файл поставки;
-
Заходит в рабочую базу в режиме конфигуратора и обновляет основную конфигурацию файлом поставки: Поддержка - Обновить конфигурацию - Выбрать файл поставки;
-
Блокирует работу пользователей в базе;
-
Обновляет конфигурацию базы данных;
-
Разрешает работу пользователей и оповещает их о возможности начать работу.
После обновления ответственный проставляет дату выпуска релиза по каждой задаче, которая вошла в этот релиз. Если по каким-то причинам доработки по задаче не попали в релиз, ответственный переносит строку с задачей в новый релиз и в комментариях описывает причину непопадания.
Такой подход позволяет:
-
минимизировать количество ошибок в “боевой” базе, т.к. непротестированные изменения не будут перенесены и не смогут нарушить работу пользователей;
-
обеспечить полное отсутствие необходимости объединять изменения разработчиков и контролировать целостность структуры конфигурации, за нас это делает хранилище;
-
откатиться к предыдущей версии в случае ошибки.
Данный метод имеет и свои минусы, например, невозможность одновременной работы с одним объектом нескольким разработчикам. В нашем случае этот подход являлся самым оптимальным, т.к. численность команды была относительно небольшой и задачи разработчиков практически не пересекались по объектам метаданных. Имеются также более простые и более сложные схемы, о которых можно прочитать в статьях https://infostart.ru/1c/articles/646867/ и https://its.1c.ru/db/v8std/content/709/hdoc.
