Релиз-менеджмент в 1С

Публикация № 1580931 11.01.22

Приемы и методы разработки - Инструментарий разработчика - Групповая разработка - Хранилище

git gitsync git2reposync edt

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

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

 

Изображение

 

Введение

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

 

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

Самый распространенный вариант - это основные изменения производим в хранилище, которое можно условно назвать 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, и тогда обычные формы нам покоряются, если изменения только в модуле формы.

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Segate 54 11.01.22 11:09 Сейчас в теме
Сразу вопрос:
Как вы обходите проблему добавления метаданных в дев ветке?
Допустим вы добавили общий модуль в рамках задачи #1 (ОМ1)
Затем еще один в рамках задачи ​#2 (ОМ2)
При этом следующим коммитом вы поменяли(опять же в рамках заявки #2) порядок объектов(Потому что сначала добавили 2й общий модуль в конец, а потом отсортировали объекты по алфавиту)

Задача #2 идет в релиз, Задача #1 еще не готова.
Но при переносе коммитов по задаче #2 в файл configuration.xml попадет информация о ОМ1, т.к. у него менялся порядок.
Но самого объекта ОМ1 в релизную конфигурацию не прилетит.
В следствии чего при сборке возникнет ошибка такого плана:
КРИТИЧНАЯОШИБКА - {Модуль /root/.local/share/ovm/dev/lib/vanessa-runner/src/Классы/КомандаСобратьИзИсходников.os / Ошибка в строке: 88 / {Модуль /root/.local/share/ovm/dev/lib/vanessa-runner/oscript_modules/v8runner/src/v8runner.os / Ошибка в строке: 1400 / Файл объекта не существует - /home/jenkins/workspace/Сборка релиза/mfg_buh/src/cf/CommonModules/Зр_ЦеныСервер.xml


Ну и если у вас есть скрипт сборки релиза по коммитам - напишите в ЛС пожалуйста =) пообщаемся и обменяемся опытом )
2. pumbaE 683 11.01.22 11:27 Сейчас в теме
(1)
Но при переносе коммитов по задаче #2 в файл configuration.xml попадет информация о ОМ1, т.к. у него менялся порядок.
Но самого объекта ОМ1 в релизную конфигурацию не прилетит.

если возникают ошибки то только вручную на откуп человеческому разуму отдаем , т.е. сам cherrypick-инг это упрощение, все еще eсть develop где cf со всеми изменениями и человек решает нужен ли ему этот ОМ1 или надо добавлять свой для себя любимого или перенести код в какой-нибудь общий мусорный ОМ, где все толкутся


(1)
Ну и если у вас есть скрипт сборки релиза по коммитам

этого не понял, чаще всего ведь нас не должна интересовать история , только текущее стабильное состояние
3. VKislitsin 684 11.01.22 11:31 Сейчас в теме
Евгений, а для чего в обратном порядке коммиты GIT обходятся? Я не понял.
readme.md:
обходит коммиты для синхронизации в обратном, т.е. хронологическом порядке, если указываем sha комитов списком abc1234..cbc56778, то первым коммитом для синхронизации из полученного диапазона будет cbc56778
5. pumbaE 683 11.01.22 11:36 Сейчас в теме
(3)
для чего

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

p.s. я знаю что это гит и там не все так однозначно, но
VKislitsin; +1 Ответить
4. Segate 54 11.01.22 11:32 Сейчас в теме
(2) Это не только к общим модулям относится, при любом изменении порядка, и различии дерева метаданных в dev и релиз кандидате - есть шанс нарваться на попадание в манифест конфигурации лишних данных.
И мы пока руками в таком случае правим configuration.xml

мне кажется - это очень костыльно, и хочется понять, как это решается у кого нибудь

этого не понял, чаще всего ведь нас не должна интересовать история , только текущее стабильное состояние


чтобы получить текущиее стабильное состояние - надо черрипиками всю историю изменений пикнуть )
6. pumbaE 683 11.01.22 11:42 Сейчас в теме
(4)
мне кажется - это очень костыльно, и хочется понять, как это решается у кого нибудь

чудес не бывает,
старый способ сравнения -объединения cf файлов средствами 1с и выгрузка в исходники решает такие проблемы, и то это классная проблема, т.к на этапе сборки говорит что есть ошибка, а вот задвоение id элементов форм более коварная ошибка, для этого и нужны тесты
7. Segate 54 11.01.22 11:46 Сейчас в теме
(6) дак в итоге вы в релиз кандидат руками черри-пикаете или скриптом?
8. pumbaE 683 11.01.22 12:04 Сейчас в теме
(7) руками , для скрипта очень просто проблема с определением sha каких коммитов необходимо перенести( git log с фильтром по номеру задачи не сильно надежен/точен) , а так алгоритмически скрипт прост создать ветку cherry pick sha ... и все
9. awk 733 12.01.22 09:05 Сейчас в теме
Евгений, мое почтение.

Перешел на твой репозиторий гитхаба и в очередной раз увидел ответ на вопрос: "Почему писать код и документацию надо на английском?".
10. adapter 569 14.01.22 12:44 Сейчас в теме
как отследить ветки, которые успешно прошли тесты?
11. pumbaE 683 14.01.22 14:25 Сейчас в теме
(10) 1. pull -request 2.тестируем и если тесты прошли успешно, то 3.авто merge и 4.удаляем ветку нет ветки нет проблемы , для отслеживания остаются две главные ветки main и develop
Оставьте свое сообщение