#gitlab #gitlab-ci #continuous-deployment #semantic-release
#gitlab #gitlab-ci #непрерывное развертывание #семантический релиз
Вопрос:
Я пытаюсь следовать потоку GitLab с промежуточными и производственными средами. Мне также нужен плагин семантического релиза для обеих сред (при этом мне также нужна ветка для каждой среды, чтобы семантический релиз мог работать, верно?)
Я успешно запустил semantic-release, работающий для промежуточной ветки, он создается vX.X.X-rc.x , как и ожидалось, и также генерирует список изменений. Отлично!
Но как мне правильно работать с этими ветвями? Я думаю, я понимаю, как я мог бы сделать это только с главной веткой и двумя средами, но я не смог найти никакой информации о том, как сделать это с отдельными ветвями.
Я создаю ветку функций, завершаю функцию, объединяю с мастером. Что теперь? Должен ли у меня быть deployment job, который при каждом слиянии с master автоматически объединяет master с промежуточным, запускает semantic-release и затем развертывает его? А затем выполнить ручное развертывание, которое автоматически объединяет промежуточный этап с производственным, запускает semantic-release, а затем развертывает производство?
И, во-вторых, подумайте: как бы я справился с соглашениями о принудительной фиксации сообщений? Если я объединяю функцию с master, появляется сообщение о фиксации feat(x): something something . Но что должно быть в этих автоматических объединениях master to staging и staging to production?
Комментарии:
1. Не уверен, что это соглашение, но у меня есть ветка разработки, которая не запускает SR, главную ветку (для реальных выпусков). Я работаю с dev (с объединением ветвей функций с dev). Затем я объединю из dev в свои ветви «release» (master, beta, alpha, release-candidate или vX.Y.Z для ветвей обслуживания)
2. @AlexandreCassagne спасибо за замечание, это тоже выглядит хорошо. Я впервые читаю о CI / CD (в течение 3 дней подряд), и все, что я нашел, было просто краткими «примерами» либо о потоке ветвей, либо о CI, либо о соглашениях о сообщениях о фиксации — но не все вместе. Я даже не знаю, сколько вещей там должно быть автоматизировано (в идеальном CI) — я имею в виду эти слияния и т.д.
3. На мой взгляд, ветвление по окружению не является отличным подходом к этой проблеме. Я бы не рекомендовал пытаться автоматизировать слияния. Вы столкнетесь с множеством болевых точек. У вас могут быть (ручные) задания для отправки артефактов в различные среды и / или задания, которые выполняются только при наличии тега, соответствующего шаблону семантической версии. В общем, я бы сказал, что все работает лучше, если вы выпускаете только из ветки по умолчанию.
4. @sytech Спасибо, я потратил еще целый день на изучение semantic-release и, думаю, теперь я понимаю это лучше. Имея только одну ветку выпуска, вы имеете в виду как тестирование, так и развертывание в производстве, верно? Какую версию я должен назначить тестовой версии? Я подумал, что настройка предварительной версии в semantic-release — идеальное решение для меня, например, для версии v1.3.2-rc.2, но она работает иначе, чем я думал.
5. У меня есть идея — допустим, у меня есть недолговечное исправление ветки / somebug, и когда я создаю PR для master, я запускаю тестовое развертывание с использованием динамических сред GitLab. Я думаю, это сработало бы, но все же, какую версию я бы назначил ей? Я считаю, что здесь это не имеет значения, но все же что-то было бы лучше, чем 0.0.0.