Каталог решений - Релиз-менеджмент в 1С

Упрощенная модель управления релизами

Введение

Выпуск релиза — сложная, ответственная процедура. Все, что наговокодили программисты, релиз-менеджер собирает в единую кучу и принимает все удары на себя, хотя он просто граблями посгребал все в единое целое. Поэтому релиз-менеджера выбирают самого спокойного, опытного, способного выдержать вал критики в свой адрес. В данной статье не будем рассматривать самый правильный вариант релиз-менеджмента, т.к. самого правильного не существует, только различные варианты, которые применимы в том или ином случае.

Релиз менеджмент говнокода — блаженная неизвестность иллюзии

Самый распространенный вариант — это основные изменения производим в хранилище, которое можно условно назвать develop (условно рабочий код; вечно с незаконченными кусками кода; с просьбами “а дайте форму заказ клиента, я быстро”) и перенос через сравнение/объединение необходимых доработок в cf файле взятым из прода (для этого необходимо проинформировать какие метаданные необходимо отметить для объединения, какие куски кода в модулях в конкретных процедурах необходимо перенести) и получившийся cf файл уже отправляют на тестирование в базу pre-prod, там происходит тестирование и если все ок, то и в релиз, после обновления prod получаем новый продуктовый cf, колесо релиз-менеджмента делает полный оборот и начинаем новый виток.

Старый конь борозды не портит — ну и на этом в принципе положительное все.

Как же можно упростить и ускорить сам процесс релиза? Самое очевидное — разбить один долгий, нудный процесс на несколько мелких. Пусть не релиз-менеджер сравнивает и объединяет готовые доработки для релиза, а сами программисты. Когда они сделали у себя и на их базах проверили, что все работает и соответствует критериям приемки, только тогда переносят. Для этого создадим еще одно хранилище и назовем его условно main в котором будем хранить версии того, что должно пойти в релиз (хранилище нужно, чтоб видеть историю, хоть и маленькую, когда один дятел затирает перенесенные изменения другого, по неопытности или специально, неважно) в таком случае задачи, которые должны попасть в релиз, не выстраиваются в одну большую очередь для итогового переноса, а мелкими итерациями переносятся в предполагаемый релиз во время долгого цикла разработки. Конечно, это работает, если у вас часто задачи готовы до времени дедлайна, ибо если так, то не имеет смысла что-либо улучшать, у вас итак полный дзен…

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

Мучительная правда реальности

Основная проблема вышеописанного способа не очень сильно решилась, просто убрали релиз-менеджера из уравнения и описали более понятные действия/процессы программистов, бизнес-аналитиков и тестировщиков (возможно, все три роли одним лицом и выполняются). Релиз-менеджер все равно не мог выполнять ни контроль качества кода, ни мелкий рефакторинг (пока задашь вопрос программисту, если тот сделает исправление, то опять запускать сравнение/объединение, короче печаль и боль, проще забить; визуально глянул, вроде работает ну и грець з ним). Итого убрали релиз-менеджера, перекинули на самих программистов перенос задач, готовых для релиза, но сильно лучше-то не стало… Вместо одного большого сравнения раз в 2 недели, теперь сами программисты сидят и запускают сравнение/объединение, отмечают свои объекты, ждут, ожидают, под конец спринта начинают ожидать не только в develop метаданные для захвата, но уже и в main, напряженность растет, обиды копятся, надо опять что-то оптимизировать.

Git, gitsync

“Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, и есть утка”. Так вот, такая организация develop/main хранилища очень похожа на git-flow, только без hotfix веток (ибо тяжело, да и расширения в таких случаях спасают). Каждый программист подключен к develop ветке/хранилищу (синхронизируется с помощью любого конвертера ) при начале работы с какой-либо задачей программист захватывает необходимые объекты и в своей базе начинает доработки, один в один feature ветка, только без pull-request и code-review, при окончании работы, проверяет работу в его урезанной базе, помещает все измененные метаданные только для этой задачи с комментарием, привязанным к определенной задаче, и минуя pull-request feature/3556 сразу попадает в develop ветку, но в плане релиза тут есть существенные отличия git-flow предполагает, что все что есть в develop это протестировано и готово к релизу, а что не готово то висит во feature ветках, ну и пусть там висит, с учетом особенностей 1С хранилища в develop у нас куча мала из коммитов готового к релизу и не готового. А если мы немного прогрессивные и у нас уже конвертируется хранилище в определенную (develop) ветку git-a (это не сложно или даже 8.2.xxxx не помеха), то у нас возможность cherrypick-нуть необходимые коммиты в ветку ReleaseCandidate, которую создали на основании main и туда переносим необходимые коммиты, с полученной ветки RC можно собирать cf (runner compile -s .\src -o 1cv8.cf), который можно деплоить в тестовую базу автоматически или вручную, кто как пожелает и проводить тестирование.

Единственное пожелание — это атомарность изменений к конкретной задаче, неважно, сколько раз по этой задаче делали изменения, главное в хронологическом порядке переносить изменения.

git2reposync

Маленькая утилита https://github.com/pumbaEO/git2reposync/releases, которая в отличие от gitsync позволяет синхронизировать в обратную сторону изменения из git в хранилище 1С. Качаем c releases, устанавливаем opm install -f git2reposync-*.ospx. Алгоритм простой, линейный: создаем пустую файловую базу, подключаемся к хранилищу, переключаемся на необходимый коммит в git (чаще всего это HEAD), получаем комментарий git show -s sha, проверяем, был ли этот коммит уже когда-либо синхронизирован с хранилищем, чтобы повторно не помещать, собираем из исходников cf файл, рекурсивно захватываем все объекты и запускаем сравнение/объединение с указанием пути к файлу mergesettings.xml. В файле у нас прописано рекурсивно брать все из внешнего cf файла, единственное, что требует корректировки — это необходимо под свою конфигурацию заполнить Name, version, Vendor, как пример можно взять с https://github.com/pumbaEO/git2reposync/blob/main/templates/mergesettingsRecursor.xml#L4 и, наконец-то, рекурсивно помещаем все объекты с комментарием от гита gitt2reposync sync -c HEAD -u admin -m .\testgit\mergesettingsRecursor.xml .\repo_develop .\testgit

На этом, в принципе, и все, дошли до логического конца. Далее ожидает автотестирование — тяжело, трудно, но логически понимаем, что верное направление. Можно включить плагин edt и разрабатывать в гибридном варианте, часть с хранилищем, другая часть — самые "провинившиеся" — делают доработки в edt, и ночью запускаем синхронизацию с хранилищем. Можно плагин runner использовать для сборки cf с помощью vannessa-runner compile, и тогда обычные формы нам покоряются, если изменения только в модуле формы.

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