iMedicum. Регламент релизов.

iMedicum

Регламент релизов

проект iMedicum. Владислав Лежнев aka LiVsI

Использованные источники:

Вводная:

  1. git - вспомогательный инструмент, он не пишет наш код и не делает его лучше. Он тупо следит за изменениями в коде
Накатывание релизов из дева, в который хаотично приходят коммиты - это боль!

PS: Да, я люблю git command line.

Что происходит:

  1. Планируем релиз
  2. Реализуем фичи релиза
  3. Тестируем предрелиз
  4. Выкатываем релиз на продакшн
  5. Ловим баги в релизе

Планируем релиз:

  1. Формализируем фичу в тракере, описываем, рисуем, думаем
  2. Выбираем что из беклога выбрать на следующий спринт (планирование спринта)
  3. Оцениваем время
  4. Распределяем работу в командах

Реализуем фичи релиза:

Они взаимосвязаны но изолированы. Их не много. Признак фичи - ее можно втащить в релиз отдельно от других с пользой для проекта.

Ветка MASTER

Это текущее состояние imedicum.ru. ЗАКРЫТА для комитов - туда пушат цельными релизами из QA

Ветка QA

Ветка QA - текущий релиз. После накатывания очередного релиза на MASTER - от этой ветки ветвятся и в нее вливаются только хотфиксы.
Место вливания в MASTER - помечается тегом v0.2. Это текущий релиз, накаченный в мастер к которому можно прилепить только хотфиксы. Точки вливания хотфиксов в мастер - отмечены тегом v0.2.1 Нумерация тегов сквозная.

QA = MASTER + Хотфиксы

Хотфиксы

Хотфиксы вливаются одновременно и в QA и в DEVELOP - чтобы не получилось ситуации открытия уже закрытого бага.
Ветка QA может временно закрываться на период тестирования, и после их окончания открывается для пушей вновь. Итераций по тестированию на протяжении релиза может быть несколько.

Хотфиксы: выкатывание

Багоделы должны учитывать в своей работе, что не всегда смогут запушить в QA
Хотфиксы мелки и это облегчает задачу пуша

Если для хотфикса понадобилась ветка - то ее именование - hotfix/19002

Ветка DEVELOP

Ветка DEVELOP - билд продукта, будующий релиз, от него ветвятся и в него вливаются фичи. В момент релиза - то есть когда закончены все запланированные на спринт фичи, эта ветка сливается с QA.

Ветка DEVELOP: push & merge [1]

Если ваша фича умещается в один комит - можно не создавать ветку фичи, накатывайте в DEVELOP из своей локальной ветки develop.
"Умещается" - определяем по составу изменений: до 7 файлов, до 50 строк в сумме, взаимосвязанных и легких для понимания другими.

Ветка DEVELOP: push & merge [2]

Если фича состоит из ряда изменений, логически отдельных или реализация фичи дольше релизного срока - выносите ее в ветку.
Именование ветки feature/19002

Ветка DEVELOP: push & merge [3]

В ветку DEVELOP фичи вливаются полностью рабочие.
Вливание веток должно проходить без Fast-Forvard, с помошью
git merge feature/NUMBER --no-ff

Фича или работает или нет

А как же интеграция?

Общие сущности symfony2, которые влияют на весь проект в целом:

Перекрестная интеграция

Каждую из этих сущностей, или связный набор - оформляйте отдельным комитом. Если кому нибудь еще понадобится ваше изменение - то станет возмножна операция переноса коммита в другую ветку git cherry-pick ...
И если ваша фича по каким то причинам не пойдет в PRODUCTION - часть вашей работы попадет туда через другую фичу, где будет использоваться общий функционал.

Git

Git

Git

Git

Git

Git

Git

Git

Git

Git

Git

Git

Успешных релизов всем нам!
Вопросы, комментарии, троллинг?

Почитать на досуге