Нарушает ли codefreeze принципы непрерывной доставки?
Следуя ниже git-flow,
Используя подход CI/CD для SDLC, если отмеченная фиксация прошла конвейер QA, то пришло время создать ветку Release из ветки Develop, потому что я понимаю, что
Если при объединении с веткой Master сборка конвейера prod не удалась, разработчикам необходимо сначала решить эту проблему и создать новый рабочий коммит в той же ветке Release. Это может привести к замораживанию кода для разработчиков для слияния в ветке Develop, по причине слияния ветки Release с веткой Develop (после успешного выполнения конвейера prod) НЕ ДОЛЖНО генерировать ошибки в конвейере dev.
Мой вопрос, как показано ниже,
Требуется ли продолжительность слияния Master для других разработчиков в ветви Develop? Если да, нарушает ли codefreeze принципы непрерывной доставки?
1 ответ
Да, я думаю, что такой подход значительно отличается от принципов КИ. Это, вероятно, попадает в сферу деятельности CI Theatre. А без CI нельзя говорить о CD.
Общая идея, лежащая в основе CI, заключается в том, чтобы вся разработка была разбита на небольшие, постепенные изменения, разработанные как можно ближе к вершине ветви и немедленно интегрированные в ветку, чтобы максимизировать видимость и свести к минимуму сюрпризы. Только в таких условиях инструмент CI может эффективно указывать на большинство проблемных коммитов очень быстро.
Уход за боковую ветвь (замороженная или нет), в то время как ведущая ветвь продолжает двигаться, требует дополнительных усилий для объединения этой ветки с ведущей (в любом направлении), увеличивая трудности пропорционально продолжительности жизни боковой ветви. Это потому, что слияние пытается объединить 2 больших комка: все коммиты из ветви и все коммиты, выполненные на master, так как ветка была извлечена / синхронизирована - больше не является инкрементным изменением. Возможность сразу определить ошибочный коммит теряется, это решение "все или ничего": либо вы разрешаете объединение, принимая удар по качеству, либо отклоняете его. Вот почему ИМХО:
- говорить о выполнении CI на ветках почти сразу
- CI (как методология) в значительной степени является синонимом разработки на основе соединительных линий (TBD).
Ветви релизов немного отличаются от обычных веток, они могут иметь смысл в некоторых бизнес-случаях. Но только если они остаются верными CI, не подвергаясь слияниям. Смысл ветки релиза - это замораживание - изоляция его от разработки в стволе, которая продолжает эволюционировать к следующему выпуску. Слияние ветки релиза обратно в trunk не имеет большого смысла для меня: изменения для более старой версии не обязательно совместимы с более новой версией, такое объединение просто вызывает проблемы. Смотрите также мой ответ на Как избавиться от развивающейся ветки для упрощенного потока Git. Если в ветви релиза есть ценные коммиты (обычная причина запроса такого слияния), они должны быть проверены на совместимость и дважды зафиксированы в транке как независимые изменения, подчиненные тем же критериям проверки, что и любые другие изменения транка.
Примечание: я не говорю, что стратегии без CI не будут работать - большинство из них работают (я работал с ними годами), но они сложнее, медленнее и дороже.