Пора отпустить ветку develop, если вы не тот человек, который ведёт всю разработку.
Всю целиком.
Это ситуация, которую часто видишь в корпоративной, энтерпрайз, если хотите, scrum-подобной среде. Не вы контролируете релиз в смысле того, что в него попадает, и именно здесь вся концепция ветки разработки как будущей версии не имеет никакого смысла.
Представим типичное scrum-веб-приложение, которое вы делаете/поддерживаете вместе с командой в [Название компании]. Ваши задачи в Jira, вы используете GitHub for Enterprise и следуете стратегии GitFlow (которая прекрасна). И вы мёржите в Develop.
Определение проблемы
- Не обязательно всё, что вы делаете за спринт, попадёт в релиз
- Не обязательно всё, что вы делаете, вообще предназначено для релиза в этой итерации
- Вы и ваши коллеги всё равно захотите вмёржить свой код, даже если он запланирован на следующую итерацию
И вот к чему это приводит
- В итоге в день релиза вам приходится вручную выбирать релиз и вручную применять патчи, создавая версию кода, которую на самом деле никогда не тестировали разработчики, вводившие новые фичи. Это совершенно новая, невиданная вселенная.
- Худшее: вам, возможно, придётся что-то удалять, тем самым не только создавая непредсказуемую вселенную, но и делая возможным, что вы что-то забудете по пути. Это что-то всплывёт в продакшене на следующий день. Такой исход обычно случается ночью.
- Само существование ветки Develop работает как точка путаницы: оно позволяет не думать о целевом релизе фичи, над которой работаешь. Оно позволяет не разговаривать с бизнесом, на который работаешь (да, иногда неясно, какой релиз целевой для фичи).
Как это исправить
Удалите ветку develop. Отпустите её.
Это всего лишь концепция будущего релиза, за которую вам не стоит платить.
Держите только релизные ветки. Направляйте свои pull request в релизные ветки. Свободно мёржите старый релиз в новый, когда это удобно вам и команде. Сделайте правилом: новая версия задеплоена — мёржим код в следующую релизную ветку. Когда неясно, какой релиз целевой: спросите стейкхолдеров. Откатывайте код фичи, как только её целевой релиз изменился (если фиче ещё рано выходить): убедитесь, что стейкхолдеры понимают цену rebase фичи.
Начните снова думать. Держите релизные ветки вечно. Используйте теги, чтобы отслеживать релизы. Держите мелкие изменения в релизных ветках. Отпустите ветку develop (и убедитесь, что вместе с ней уходит и ветка master).
У вас нет концепции ветки develop по умолчанию? Вы вправе вообще её не иметь.
Вы, наверное, можете задуматься о feature flags, но я бы предложил подумать дважды, поскольку это никогда не выходит дёшево. Каждое состояние фичи — это снова та же непротестированная вселенная.
Изначально опубликовано на Medium: https://medium.com/@nettsundere/its-time-to-let-the-develop-branch-go-f69243d546a9