Комментарии 8
Мне кажется вы придумали GitFlow
Почти. Мы начинали работать по GitFlow, а потом немного расширили модель, «развалив» ветку develop на две: dev и release.
Да, на первый взгляд одно и то же, различие в деталях. В GitFlow для каждого релиза стартуют отдельную ветку, которая потом сливается с мастером. Использование release branch полезно, когда нужно релизить несколько версий одновременно, но мы предпочли сфокусироваться на коротком цикле выпуска. У нас ветка релиза всегда одна, каждый следующий планируемый релиз просто вливается в неё из dev. Ветки dev & release друг от друга по сути почти не отличаются и больше похожи на develop из GitFlow. А то что в GitFlow называется release branch у нас не прижилось. Ветки обрабатываются сервером сборки абсолютно одинаково, результаты сборки деплоятся на разных стендах. В ветке release ведется разработка также как и в dev, но границы возможных изменений в release жестко ограничены, чтобы процесс был сходящимся. Также существенная разница приоритетах усилий по тестированию и исправлению ошибок — основное внимание уделяется ветке release, dev тестируется и правится по остаточному принципу. Все усилия фокусируются на стабилизации и выпуске релиза.
Подскажите пожалуйста:
Спасибо.
- Сколько разработчиков работают одновременно?
- Я правильно понимаю, что проект состоит из одного репозитория?
- Что если в разработке в данный момент находятся фичи аля Proof Of Concept или разные реализации одной задачи для проверки производительности или еще что то, которые не нужно нести в релиз? Они в каких-то отдельных ветках? Кто и как часто следит за их обновлением? Или такого не бывает?
- Как осуществляется поддержка старых версий, работающих у клиентов? Ну например нужно поправить баг в пред-пред-стабильной версии. Небольшой. Или это не релевантно и везде используется только последняя версия?
Спасибо.
1. Одновременно работают 6 разработчиков. Планируем расти.
2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
правильно понимаю, что у вас 1 релиз в месяц?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Codefreeze и непрерывная поставка