В GoHealth мы помогаем людям найти и зарегистрироваться в наиболее подходящих планах медицинского страхования. Частью процесса является заполнение заявки на регистрацию через наш веб-интерфейс, которая затем отправляется в страховую компанию, предоставляющую план. Вот где вступает в дело моя команда — мы владеем потоком пользователей для регистрации и интегрируемся с крупными страховыми компаниями США, такими как Humana или Anthem.

Когда я присоединился к команде по регистрации, мы выпускали специальные выпуски. У нас не было регулярного графика выпуска, что означало, что мы выпускали выпуски, когда чувствовали, что пришло время — обычно мы чувствовали сильное желание выпускать до критических исправлений или сроков, установленных бизнесом. Это часто приводило к разрыву между выпусками в четыре-шесть недель. Большие релизы означают большие проблемы — каждый релиз содержит слишком много изменений, трудно рассуждать о том, что на самом деле входит в релиз, а тестирование превращается в кошмар. Менее частые выпуски также означают, что людям нужно напоминать себе, как выполнять выпуск как с точки зрения процесса (например, кого уведомлять), так и с точки зрения выполнения (например, какие кнопки нажимать для развертывания приложения). В результате вокруг каждого релиза было много беспокойства и опасений.

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

Мы встали на путь улучшения нашего цикла выпуска, и хотя всегда есть место для улучшения, мы дошли до того, что придерживаемся регулярного двухнедельного цикла выпуска, иногда снижаясь до выпуска или трех выпусков в неделю. Вот что мы сделали и узнали в процессе.

Придерживайтесь расписания

Планирование следующего релиза через две короткие недели после последнего проблемного релиза — сложная задача, но нужно с чего-то начинать. Поэтому выберите свой график и придерживайтесь его. Может даже показаться, что для релиза недостаточно изменений — и это хорошо! Мало изменений означает, что релиз будет простым. Небольшой релиз имеет гораздо больше шансов на успех и побудит всех придерживаться частых релизов. Менее громоздкий выпуск позволяет вам точно настроить свои процессы. Так что на самом деле мы выпустили релиз через две недели, а затем еще через две, и с тех пор мы продолжали выпускать его регулярно.

Создание контрольных списков

Когда вы делаете что-то часто, вам нужно быть особенно эффективным. Мы продолжали оценивать, как у нас дела — как путем осознанного выполнения релиза, так и путем сбора отзывов на наших ретроспективных встречах.

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

  • Документация по процессу выпуска
  • Список заданий развертывания
  • Панели мониторинга и ведение журнала

Как только мы хорошо разобрались в процессе, мы создали контрольный список, чтобы описать все шаги в выпуске:

  • Какие системы выпускать
  • Люди, которых нужно уведомить
  • Необходимы человеческие проверки (например, обратная совместимость)
  • Зоны тестирования

Создание документации и контрольных списков очень помогло нам привлечь больше людей к процессу релиза.

Автоматизируйте развертывание

Что на самом деле сработало очень хорошо, так это технологический ландшафт, который мы используем. Фактический выпуск — это не более чем нажатие кнопки, потому что мы упаковываем все наши приложения в контейнеры Docker и развертываем их на AWS через Jenkins. В частности, AWS Elastic Container Service (ECS) отлично подходит для нашего варианта использования — приложения и файлы докеров просты, а саму среду легко отслеживать. Полезно иметь замечательную команду по проектированию надежности сайта и группы по инструментам, которые поддерживают строительные блоки и инфраструктуру в отличном состоянии.

Автоматизируйте подготовку релиза

Важная часть увеличения частоты релизов — сделать подготовку к релизу быстрее и проще. У нас есть несколько внутренних инструментов, которые помогают нам видеть развернутые версии, различия исходного кода между развернутой и следующей версиями, а также состояние тестирования. Мы отслеживаем требования с помощью сценариев спецификаций и тикетов Jira, а инструменты помогают нам увидеть, какие сценарии будут развернуты в выпуске.

Автоматизируйте тестирование

Частые релизы создают большую нагрузку на ручное тестирование. При переходе на частые релизы казалось, что тестирование одного релиза начинается одновременно с завершением другого, что оставляет очень мало времени для фактической добавленной части QA — тестового анализа. Наш ответ? Автоматизируйте это! (Вы можете начать видеть образец здесь). У нас уже есть специальная команда QA Automation, которая реализует наши спецификации тестирования. Видя нагрузку на ручных тестировщиков, мы начали уделять больше внимания автоматизации регрессионного тестирования, чтобы ручные тестировщики могли сосредоточиться на тестировании новых функций и внесении изменений в спецификации.

При сотрудничестве всей команды мы можем автоматически запускать регрессионные наборы и даже проверять развернутые версии без вмешательства человека — это спокойствие, необходимое для частых выпусков.

Сделайте каждое изменение доступным для публикации

Если вы хотите выпускать часто, вы не можете оставлять свою основную ветку в неразвертываемом состоянии слишком долго — любой объединенный PR должен быть немедленно готов к выпуску. Если есть незавершенная функциональность, вам нужно защитить ее с помощью флага функции.

Флаги функций не должны быть чем-то замысловатым — нам хорошо подходят простые настройки свойств.

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

Отметить все версии

Один из главных вопросов, на который нам всегда нужно ответить: «Что будет в релизе?» Для каждого выпуска мы определяем, какие изменения кода входят в выпуск, и для каждой строки кода мы видим, почему она существует, благодаря соответствующему тикету Jira.

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

Важнейшим фактором реализации является публикация библиотек и контейнеров в Nexus. Мы помечаем каждый коммит git, из которого мы публикуем библиотеку. Нам потребовалось немного усилий, чтобы стать последовательными, но это спасение, когда вы пытаетесь выяснить, что могло пойти не так.

Иметь план отката

У каждого релиза есть план отката — мы записываем текущие рабочие версии приложений на случай, если нам понадобится откатить релиз. Откат использует тот же процесс, что и развертывание новой версии. Благодаря этому процесс хорошо понятен и является безопасным выбором по умолчанию, если мы столкнемся с проблемами во время выпуска.

Иногда бывает так, что выпуск сложно откатить из-за изменений среды или других внешних зависимостей. В таких случаях мы ищем меры на уровне кода (например, дополнительный код для обеспечения обратной совместимости) и действуем очень осторожно.

Вывод

Улучшения, которые привели нас к более быстрым выпускам, не являются ракетостроением и очевидны задним числом. Суть изменений заключается в расстановке приоритетов и командной культуре, а не в технологических вызовах, как это бывает со многими улучшениями.

В конце концов, придерживаться правильных методов релиза — это как ходить в спортзал: все знают, что это полезно, но для этого нужна решимость.

Вам интересно узнать больше? Приходите работать с нами! Свяжитесь с нами по адресу [email protected] и присоединяйтесь к нашей команде.

Автор: Михал Костич

Следите за нами в Интернете и социальных сетях!

GoHealth.sk | Фейсбук | Инстаграм | ЛинкедИн | Ютуб