Джин Ким - Руководство по DevOps

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

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

• убедиться, что пакеты, созданные во время непрерывного процесса интеграции, подходят для развертывания в производство;

• с одного взгляда показать готовность производственных сред;

• обеспечить запускаемый одним нажатием кнопки и самообслуживаемый метод развертывания в производство любой подходящей версии упакованного кода;

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

• выполнить smoke-тест, чтобы убедиться, что система работает правильно и параметры конфигурации, в том числе такие элементы, как строки подключений к базам данных, корректны;

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

Цель — обеспечить, чтобы развертывание выполнялось быстро, мы не хотим ждать часами, пока сможем определить, успешно ли развертывание нашего кода или нет, а затем еще столько же времени тратить на развертывание кода, исправляющего обнаруженные ошибки. Сейчас мы имеем такие технологии, как контейнеры, и можем завершить развертывание даже в самых сложных средах в течение нескольких секунд или минут. Данные, опубликованные в докладе 2014 State of DevOps Report, подготовленном компанией Puppet Labs, свидетельствуют, что при высокой производительности время развертывания измеряется несколькими минутами или часами, в то время как при низкой производительности — месяцами.

Рис. 18. Компании с высокой производительностью выполняют развертывание гораздо быстрее и также гораздо быстрее восстанавливают работу производственных сервисов после инцидентов (источник: доклад 2014 State of DevOps Report, подготовленный компанией Puppet Labs)

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

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

Как писал Ноа Сассман, архитектор тестирования компании Etsy, «в восемь утра, когда начинается обычный рабочий день, примерно 15 человек и их псов организуют очередь: все они ждут, чтобы коллективно развернуть до 25 наборов изменений до конца дня».

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

Целью компании Etsy было сделать развертывание в производство легким и безопасным, с наименьшим количеством шагов и минимальным количеством формальностей. Еще до того, как разработчик зафиксирует код, он запустит на своей рабочей станции все 4500 модульных тестов, что займет менее одной минуты. Все вызовы внешних систем, таких как базы данных, закрыты заглушками.

После того как инженеры зафиксируют изменения в основной ветке кода, мгновенно запускаются более семи тысяч автоматизированных тестов основной ветке на серверах непрерывной интеграции (CI — continuous integration). Сассман пишет: «Методом проб и ошибок мы пришли к выводу, что примерно 11 минут — это подходящий срок для максимальной продолжительности работы автоматизированных тестов в течение цикла. Это оставляет запас времени на повторный запуск тестов во время развертывания, если что-то сломается, и нужно будет вносить исправления, не выходя слишком далеко за принятый двадцатиминутный лимит времени».