Ежедневный цикл разработки Build Boss

Интеграция небольшого социального слоя поверх Непрерывной интеграции и git flow

Автор: @kenny_pizza

В процессе веб-разработки моя личная продуктивность часто опускается в лужи. Отчасти это связано с тем, что многие ветки master и staging иногда могут лишь смутно приближаться к тому, что находится в реальном времени, и это раздражает при работе. Иногда пропасть между окружениями довольно велика, они были спагеттифицированы, горячо пропатчены и трипл-ролл-бэкированы. Или это называлось Good-good-master-use-this-branch-version-2?

Этот цикл разработки - моя неоправданная попытка сохранить чистоту staging и master, упростить протокол git, ускорить циклы разработки и позволить командам получить лучшее представление о происходящем. Это моя попытка выяснить этот момент в Joel Test: Daily Builds.

Этот процесс представляет собой цикл разработки, основанный на успешной модели ветвления Git, но приглушенный.

Требования:

• Нужны легко развертываемые среды разработки/тестирования (здесь они называются feature-environments, что-то вроде Rushes или Dailies).
• Иметь ветки фич и дисциплину jira
• Slack (или, не дай бог, другой корпоративный чат-сервис).

Преимущества:

• Быстрые циклы небольших улучшений приводят к интересным побочным эффектам
• Легче отслеживать прогресс на ежедневной основе
• Ежедневные журналы изменений для всеобщего обозрения
• Дисциплина тегов релизов
• Откат - это просто
• Вращающийся состав Build Bosses гарантирует, что каждый в команде знает ставки и знает свой путь к процессу развертывания
• Вероятно, гораздо меньше конфликтов ветвей, поскольку изменения должны распространяться только вверх от staging к master
• Требует всего час или около того времени от Build Boss и регрессионного тестировщика QA в день (если только что-то не сломается), но прививает дисциплину и создает преимущества, которые распространяются на всю команду.
• Можно сократить до ежедневных, двухнедельных или еженедельных.

Предостережения:

• Вероятно, лучше всего подходит для команд, работающих над одним репо, но я хотел бы реализовать его на основе всего продукта, возможно, он может быть сложен иерархически?
• Горячие патчи должны быть доставлены из feature -> staging -> master, как и feature
• Отнимает некоторое время от рабочего дня каждого

Разработка фич

Когда разработчик получает задание от jira, он отделяет ветку фич от ветки Master, помечает ее именем тикета jira и связывает с тикетом. Разработчик создает новую среду, в которой полный набор функций платформы может быть доступен для QA и других заинтересованных сторон (например, тестовый сервер). Это называется функциональной средой После разработки функция передается в QA со ссылкой на функциональную среду для ознакомления. Если заинтересованные стороны согласны с тем, что работа завершена, это отмечается на jira счастливым лицом или чем-то подобным. Один разработчик может работать над несколькими функциями одновременно, но функции должны разрабатываться независимо друг от друга в своих собственных средах.

Мастер интеграции

Бросьте кости, чтобы узнать, кто из разработчиков возьмет мантию "Босса интеграции" на неделю. Заведите slack-канал Build Boss's Lair. Они получают модный значок эмодзи на своем статусе в slack, чтобы все могли их найти. Каждое утро, когда люди наконец приходят в офис и пьют кофе, Build Boss объединяет staging с master, создавая тег релиза. Затем Build Boss объявляет новую мастер-версию на канале slack. Скорее всего, это будет незначительное исправление. Начальник сборки включает журнал изменений в новую версию, что вызывает "хип-хип-хип-ура" со стороны разработчиков. Staging и master теперь синхронизированы, и релиз запущен. Журнал изменений теперь можно разослать по электронной почте по всей компании, передать сторонней компании или передать другим заинтересованным лицам, которые хотят следить за происходящим. Ветви функций, которые были включены в эту последнюю сборку, теперь УДАЛЕНЫ НАВСЕГДА.

Интеграция в Staging

Чуть позже, может быть, до обеда, Build Boss призывает к интеграции в staging на канале slack. Если у кого-то из разработчиков есть фича, которая была отмечена счастливым лицом для QA, эти фичи могут быть предложены Build Boss для включения в staging (важно отметить, что ветка staging в этот момент должна быть идентична master). Люди делают свои PR, а Build Boss одобряет или отклоняет PR, в зависимости от своих чувств, расположения звезд или ее суждения о том, насколько сложной станет ветка staging после слияния. Затем Build Boss сливает все в staging, отклонив некоторые PR из-за низкого качества кода или чего-то еще. Если что-то задерживается, то так тому и быть. Каждый день, скорее всего, будет только два или три незначительных изменения и обновления функций.

Регрессионный раунд

После раунда Staging Integration, где-то после обеда, Build Master относит свои краткие заметки из журнала изменений, отражающие текущее состояние staging branch, в QA, где проводится краткий регрессионный тест. Это простая проверка на вменяемость, дымовой тест. Эти функции уже должны были быть проверены QA во время разработки (по просьбе разработчика функции), этот шаг нужен только для того, чтобы убедиться, что их объединение не вызвало землетрясения. Некоторые части этого этапа могут быть автоматизированы. Что-то сломалось? Сегодня релиза нет. Staging возвращается к состоянию последней метки релиза мастер-ветки Не сломалось? Отлично. Вам больше ничего не нужно делать сегодня (кроме своей обычной работы, конечно). QA и Build Boss могут весь оставшийся день копаться в staging, если захотят. Среда постановки будет находиться в этой стадии до утра следующего дня во время раунда мастер-интеграции.

Примечания:

• Разработчик функций несет ответственность за то, чтобы его функции были проверены QA, и за то, чтобы они были включены в ежедневный раунд Staging Integration.
• Разработчик функций обязан убедиться, что все готово к интеграции в Staging Integration и Master Integration, чтобы пройти регрессионные тесты после каждого этапа. Это включает в себя предварительную загрузку базы данных и настройку развертывания. Если что-то сломается, Build Boss выкинет эту функцию из staging до тех пор, пока она не будет готова.
• Ветка Staging предназначена для того, чтобы объединить входящие функции и убедиться, что они хорошо работают вместе. Она не предназначена для демонстрации заинтересованным лицам новых возможностей! Это должно быть сделано на окружениях функций.