Условия и ограничения
Предполагаем, что
- Разработка ведется в конфигураторе (без использования EDT, что не позволяет использовать git)
- Поток изменений относительно большой, и работает группа разработчиков (иначе можно точечно обновлять конфигурацию)
- Изменения вносятся в конфигурацию (расширения сопровождаются проще)
Что бы хотелось получить
- Организовать перенос изменений максимально безошибочно в рабочую базу
- При этом максимально упростить для разработчика процедуру переноса, исключить человеческий фактор при переносе изменений. В том числе избежать порочной практики необходимости использования обрамления изменений (Вида "// +++ это начало // --- это окончание")
- Получить историю изменений версий
На мой взгляд, программист должен направлять свое внимание (ресурс которого ограничен) на правильную реализацию задачи, а не на сопутствующие вещи, вроде подготовки списка измененных объектов или оформления обрамлений в коде.
Вариант решения
В итоге у меня получилось подобрать только один вариант реализации, позволяющий избежать проблем на всех этапах разработки/развертывания. Было бы неплохо, если бы их было больше. Если есть варианты, которые я не увидел, пишите в комментариях.
За основу берем "Технологию разветвленной разработки конфигураций". Можно сказать, что это максимум, который можно выжать из хранилищ. И это своего рода ветвление для хранилищ.
Описание
Будем использовать одно хранилище (основное в терминах технологии). Так как перенос между хранилищами становится уже непростым, и это не подпадает под наши требования.
Использование хранилища разработки (хранилище проекта в терминах технологии) необязательно и остается на усмотрение разработчика. Обычно мало кто любит использовать хранилища из-за их медлительности, не смотря на то, что они дают возможность отслеживания изменений.
Из измененной типовой конфигурации делаем конфигурацию со своим именем и своей нумерацией версий.
"Считаем, что исходная типовая конфигурация становится библиотекой со своими собственными номером версии и обработчиками обновления, а доработанная конфигурация выступает в качестве основной конфигурации с собственным именем и своей нумерацией версий, разработанной на базе этой библиотеки."
В итоге из версий хранилища формируем файл поставки и получаем как-бы свою типовую конфигурацию. На рабочей базе устанавливаем конфигурацию из файлов поставки, без возможности изменения. Все объекты остаются "на замке". К хранилищу рабочую базу не подключаем. Обновление такое же как у типовых на поддержке.
Существующую доработанную рабочую базу, стоящую на частичной поддержке можно перевести на такой режим. И, что немаловажно, вернуть обратно на частичную поддержку от типовой.
Разработка
Для разработки формируем разработческую базу на которой будем дорабатывать
- копируем рабочую базу
- последовательно файлами поставок обновляем ее до последнего состояния хранилища
У нас получается база, где все объекты на замке. Для разработки снимаем только те объекты с замков, которые необходимо изменить, меняем.
В случае, если в процессе доработки необходимо синхронизироваться (внести появившиеся после того как копировали доработки), так же последовательно обновляем свою базу из файлов поставок новых версий. Процесс аналогичен обновлению доработанной типовой. Все объекты на замках обновятся автоматически и внимание нужно будет уделить только "дважды измененным". Довольно простой процесс.
Когда разработка завершена и протестирована, переносим доработки в основное хранилище. Для этого
- в основном хранилище захватываем измененные объекты (которые без замков)
- формируем файл поставки
- обновляем базу разработчика из файла поставки. Решаем конфликты, если они возникли, аналогично процессу синхронизации описанному выше
- из базы разработчика выгружаем cf
- В хранилище добавляем сравнением/объединением полученный cf. На этом шаге не нужно ничего анализировать, т.к. все уже сделано в п.4. А захват объектов не дает другим что-то изменить.
- Снимаем захват объектов
Не нужно помнить (писать, выкрыживать) какие объекты были изменены, не нужны обрамления. Процесс переноса максимально упрощен.
Одно ограничение: одна доработка - одна база. Иначе процесс переноса несколько усложняется.
Выпуск релиза
Перенос изменений в рабочую базу будем называть релизом. На мой взгляд, перед каждым выпуском релиза, нужно проверять конфигурацию на работоспособность. Хотя бы критические операции проверить. Когда делалась доработка вы проверили, что она соответствует бизнес требованиям. Когда выпускаете релиз, проверяете, что доработки не повлияли друг на друга, что помещение в хранилище было верным и т.д.
Это можно делать автоматически или вручную. Обычно автоматические тесты не используются и проверка выполняется вручную.
Для получения базы для проверки действуем так же как получение базы для разработки. Копируем рабочую базу и файлами поставок доводим копию до нужной версии.
Полученную базу проверяем.
Если принято решение о выпуске релиза, рабочая база файлами поставок так же доводится до нужной версии.
Можно отметить, что релиз может быть не обязательно на последнее состояние хранилища. Любая версия по вашему усмотрению.
Если рабочая база большого размера
Размер рабочей базы может быть очень большим. Держать копию рабочей базы для каждой доработки может быть накладно. Тут можно пойти несколькими путями.
- Использовать автотесты при разработке. Создать начальную базу и разработку вести в рабочей базе созданной от начальной базы. Размер будет небольшой. Бонусом является внедрение автотестов при выпуске релиза. Подробнее см. Тестер
- Уменьшить размер базы копии с рабочей базы, каким либо образом обрезая информацию (через обработки, обмены и т.д.)
- Разрабатывать несколько задач в одной базе. Тут уже в ручном режиме нужно отделять одну обработку от другой в процессах разработки и переноса.
Дополнительные возможности
- Общие плюшки, которые можно использовать при наличии общего хранилища (или git репозитория)
- Можно навешивать проверки АПК/SonarQube
- Выгружать хранилище в репозиторий git, где видеть кто что поменял и по какой задаче (git blame).
- Можно автоматизировать сборку файлов поставки и получать каждое утро готовые файлы релиза.
- При наличии автотестов можно их прогонять каждую ночь и сразу видеть, если кто-то что-то сломал
Другие варианты
Содержат на мой взгляд те или иные значительные недостатки, не позволяющие их использовать при значительных объемах доработок.
Использовать сразу репозиторий git
Используем "Загрузить конфигурацию из файлов"/"Выгрузить конфигурацию в файлы". Выгруженные файлы помещаем в репозиторий git.
На мой взгляд такой подход неудобен, т.к. конфигуратор напрямую с данными файлами работать не умеет. А постоянная выгрузка загрузка сильно усложняют работу. К тому же мы начинаем зависеть от работоспособности не основного функционала платформы по выгрузке в файлы, который может начать сбоить.
Подключение рабочей базы к хранилищу
Неудобно, если вам нужно обновить рабочую базу сразу на несколько релизов. По сути вы должны синхронно обновлять хранилище и рабочую базу, что бы пройти процедуры обновления базы данных.
Хранилищ уже должно быть два, так как для разработки нужно отдельное хранилище. И возникают вопросы перемещения доработок из одного хранилища в другое. Здесь больше поле для ошибок, на мой взгляд. Не знаю как можно автоматизировать процесс переноса из одного хранилища в другое.
Прямая доработка конфигурации
Может использоваться, если количество доработок небольшое, а процесс сравнения/объединения на рабочей базе можно провести без раздумий, при подготовленном cf для объединения.
Для доработки делаем копию рабочей базы. Дорабатываем, тестируем. Переносим обратно в рабочую базу наши доработки. При этом параллельно другую доработку проводить не рекомендуется.
Заключение
Данная технология опробована мой на практике только частично. В частности, разрабатывал, получая и помещая изменения в центральное хранилище, как это описано в разделе Разработка. Показалось довольно удобным. Целиком использовать рабочую базу как описано не доводилось. Но кажется неплохой идеей ).
Статья больше предмет на подумать, чем руководство к действию. Но в то же время теория кажется стройной и законченной ).
Замечания приветствуются.
