Комментарии 4
А что мешает использовать обычную модель релизов, пусть даже ежедневно, для какой цели нужна такая скорость публикации изменений?
Здесь речь идет больше про "стабильную" ветку, а не про релизы. Когда в стабильную ветку попадает ломающий код, он мгновенно распространяется по другим веткам и почти всегда мешает работе других команд. Поэтому, чтобы не заниматься поиском виновных, дешевле не допустить появления ломающего кода. При условии сохранения той же пропускной способности на влитие без потери качества.
Ну, в вашей схеме явно есть баг, который может всплыть совершенно неожиданно.
При такой скорости изменений, может возникнуть ситуация когда вы, к примеру, откидываете "бракованную" ветку и она после фикса становится в конец очереди. А какова вероятность, что где-то следом за "бракованной" веткой не идет ветка, с новыми требованиями к тому же функционалу? В итоге ваша "бракованная" ветка, после устранения ошибки перетрет обновленные бизнес-требования.
И еще, в вашей схеме должно соблюдаться правило покрытия тестами не менее 80% кода. Иначе как вы по-другому будете уверенны, что ветка действительно "зеленая"?
Я еще больше скажу, судя по вашему водопаду изменений на полноценный код-ревью расчитывать не приходится. Что не позволяет быть уверенным, что ветка действительно "зеленая"
Спасибо за комментарий. Описанная выше ситуация с "бракованной веткой" и обновленными требованиями решается либо за счет git merge стратегии, либо, как это часто бывает, возникнут merge конфликты в Pull Request, которые нужно будет решить в ручном режим, прежде чем отправлять на влитие в master.
Что же касается "зеленой" ветки и покрытия, то тут каждый проект/репозиторий сам определяет, что такое "зеленая" ветка. Это может быть % покрытия кода, производительность, соответствие код-стайлу, безопасность и тд.
Pull Request всегда отображает разницу между 2 ветками в режиме реального времени, что не накладывает никаких временных ограничений на код-ревью. Даже если между текущим PR'ом и центральной веткой просочится другой PR, он тоже будет зеленый. Т.к. сначала все собирается, проверяется, а только потом оказывается в центральной ветке, а не наоборот.
MergeQueue и зелёный Master: часть 1-я