Нарушает ли codefreeze принципы непрерывной доставки? - PullRequest
0 голосов
/ 16 января 2019

Следуя ниже git-flow,

enter image description here


Используя подход CI / CD для SDLC, если отмеченная фиксация прошла конвейер QA, то пришло время создать ветвь релиза из ветвь разработки , потому что, как я понимаю,

Если при объединении с Мастер ветвь сборка prod конвейера не удалась, разработчикам необходимо сначала решить эту проблему и создать новый рабочий коммит в той же ветке Release . Это может привести к замораживанию кода для разработчиков для слияния в ветку Develop по причине слияния ветки Release с веткой Develop (после успешного выполнения конвейера prod) НЕ ДОЛЖЕН генерировать ошибки в конвейере разработки.


Мой вопрос, как показано ниже,

enter image description here

Требуется ли продолжительность слияния Master для других разработчиков на ветке Develop ? Если да, нарушает ли codefreeze принципы непрерывной доставки?

1 Ответ

0 голосов
/ 18 января 2019

Да, я думаю, что такой подход значительно отличается от принципов КИ.Вероятно, он попадает в область действия CI Theatre .А без CI вы не можете говорить о CD.

Общая идея CI состоит в том, чтобы вся разработка была разбита на небольшие, постепенные изменения, разработанные как можно ближе к вершине ветви и сразу интегрированныев филиал, чтобы максимизировать видимость и держать сюрпризы как минимум.Только в таких условиях инструмент CI может эффективно указывать на большинство проблемных коммитов очень быстро.

Уход на боковую ветвь (замороженная или нет), в то время как основная ветвь продолжает двигаться, требует дополнительных усилий для объединения этой веткис мастером (в любом направлении), увеличиваясь в сложности пропорционально сроку службы боковой ветви.Это потому, что слияние пытается объединить 2 больших комка: все коммиты из ветви и все коммиты, выполненные на master, так как ветка была извлечена / синхронизирована - больше не является инкрементным изменением.Возможность сразу определить ошибочный коммит теряется, это решение «все или ничего»: либо вы разрешаете объединение, принимая удар по качеству, либо отклоняете его.Вот почему ИМХО:

Ветви релизов немного отличаются от обычных веток, они могут иметь смысл в некоторых бизнес-случаях.Но только если они остаются верными CI, не подвергаясь слияниям.Смысл ветки релиза - это замораживание - изоляция его от разработки в стволе, которая продолжает эволюционировать к следующему выпуску.Слияние ветки релиза обратно в trunk не имеет большого смысла для меня: изменения для более старой версии не обязательно совместимы с более новой версией, такое объединение просто вызывает проблемы.См. Также мой ответ на Как избавиться от ветки разработки для упрощенного потока Git .Если в ветви релиза есть ценные коммиты (обычная причина для запроса такого слияния), они должны быть проверены на совместимость и дважды зафиксированы в транке как независимые изменения, подчиненные тем же критериям проверки, что и любые другие изменения транка.

Примечание: я не говорю, что стратегии без CI не будут работать - большинство из них работают (я работал с ними годами), но они сложнее, медленнее и дороже.

...