Что нужно знать о непрерывной доставке

Непрерывная доставка предполагает автоматизацию ручных шагов, необходимых для выпуска ПО. В ее основе лежит непрерывная интеграция (continuous integration, CI).

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

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

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

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

При непрерывном развертывании изменения в коде сразу отправляются в продакшн, если успешно проходят все тесты, а непрерывная доставка включает еще и ручной этап перед выпуском ПО.

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

Подробнее о различиях между подходами

Последний этап CI/CD — это развертывание изменений в продакшн. В случае непрерывной доставки решение о выпуске принимается вручную, хотя сам процесс релиза автоматизирован.

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

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

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

• Начните с CI: обычно стоит сначала внедрить непрерывную интеграцию, а уж затем — непрерывную доставку. CI касается в основном команды разработчиков и дает возможность привыкнуть к автоматизации сборки, тестирования и развертывания без вовлечения других отделов.
• Делайте упор на быструю обратную связь: чем раньше вы находите проблемы, тем быстрее идет разработка. Например, можно параллельно запускать автоматизированные UI-тесты для разных платформ и отложить длительные и ресурсоемкие тесты производительности до успешного прохождения предыдущих этапов.
• Привлекайте больше людей: в основе CI/CD лежит философия DevOps, которая предполагает, что команды разработчиков не замыкаются на своей работе и рассматривают весь процесс разработки в комплексе. К проектированию CD-пайплайна стоит привлечь всех, кто участвует в процессе релиза: от специалистов по эксплуатации и безопасности до маркетологов и службы поддержки.
• Автоматизируйте тесты: без автоматизированных тестов не обойтись, так как они позволяют быстро убедиться, что программа ведет себя так, как задумано. Если у вас еще нет автоматических тестов, начните с самых важных областей и постепенно покрывайте больше.
• Используйте один и тот же артефакт сборки: чтобы избежать несоответствий, развертывайте во всех средах тот же артефакт сборки, который был создан на этапе CI.
• Обновляйте тестовые среды автоматически: в идеале, новые тестовые окружения нужно создавать для каждой новой сборки в CI/CD-пайплайне. Используйте контейнеры и подход «инфраструктура как код», чтобы быстро обновлять тестовые окружения.
• Учитывайте потребности других команд: исключением к предыдущему пункту могут быть промежуточные среды, используемые командами поддержки, продаж или маркетинга. Им может быть удобнее обновлять такие среды по запросу, чтобы избежать перебоев в работе.
• Применяйте DevSecOps: нередко считают, что команда по безопасности препятствует частым релизам из-за необходимости проводить аудиты и готовить длинные отчеты Используя подход DevSecOps, вы сможете с самого начала внедрить требования безопасности прямо в пайплайн.
• Не забывайте про ручное тестирование: иногда ручные проверки помогают найти неожиданные ошибки. Необязательно требовать ручного тестирования для каждого изменения в коде: сделайте его опциональным или настройте отдельные пайплайны, которые запускаются раз в неделю или раз в месяц.
• Автоматизируйте релиз: в случае непрерывной доставки решение о выпуске в продакшн принимается вручную, но сам процесс релиза должен быть автоматизирован. Тогда вы сможете одной командой выполнять развертывание в продакшн любой зеленой сборки.

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

Непрерывная доставка дает множество преимуществ:

• Частые релизы ускоряют вывод продуктов на рынок и доставку новых функций, исправлений и улучшений пользователям.
• Непрерывный процесс тестирования дает быструю обратную связь по проделанной работе. Если в результате внесенных изменений появилась уязвимость, приложение начало зависать или произошли сбои в работе API, вы узнаете об этом гораздо раньше, чем при обычном процессе тестирования перед релизом.
• Чем раньше обнаруживаются проблемы, тем эффективнее процесс разработки: изменения еще свежи в памяти, и меньше шансов, что они успели затронуть новый код.
• Автоматизация повторяющихся задач сборки, тестирования и релиза гарантирует, что они выполняются последовательно, и снижает вероятность ошибок, освобождая время команды для более важных дел.
• Вкладываясь в автоматизацию тестов, вы обеспечиваете более тщательное тестирование своего ПО. Оно может включать стабильное тестирование на разных платформах, проверку соответствия требованиям доступности или оценку производительности продукта.
• Автоматическое обновление окружений и развертывание сборок помогает эффективнее использовать инфраструктуру, будь то локальные серверы или облачные ресурсы.
• Автоматическое развертывание в тестовых окружениях позволяет продуктовым командам, маркетологам и специалистам поддержки заранее познакомиться с новыми функциями без дополнительных усилий со стороны разработчиков.
• С непрерывной доставкой вы полностью контролируете, когда выпускать обновления. Вы сможете доставлять улучшения пользователям еженедельно, ежедневно или даже ежечасно.

Внедрить непрерывную доставку не всегда просто. Вот с чем вы можете столкнуться:

• Совместная работа нескольких команд: скорее всего, потребуется тесное взаимодействие между разными отделами, например, операционистами, администраторами инфраструктуры, специалистами по безопасности. На первом этапе это может быть тяжело, но в долгосрочной перспективе повысит эффективность работы.
• Затраты времени: автоматизация сборки, тестирования и релиза требует времени. Чтобы облегчить себе задачу, делайте все постепенно. Кроме того, собирая метрики, например о количестве ошибок и времени сборки, и сравнивая их с затратами на ручные процедуры, вы сможете продемонстрировать преимущества нового подхода всем заинтересованным сторонам.
• Проблемы масштабирования: по мере масштабирования процесса непрерывной доставки вы, скорее всего, захотите запускать несколько сборок и тестов параллельно. В этот момент сдерживающим фактором может стать количество доступных серверов. Оптимизировав производительность пайплайна, можно подумать о переходе на облачную инфраструктуру, которая дает практически неограниченные возможности масштабирования.

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

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

Чтобы перенять это мышление, попробуйте изменить понимание того, что такое «готовность»: новая функция (или исправление ошибки), которую вы реализуете, готова не тогда, когда вы передаете написанный код на тестирование, а тогда, когда она попадает в продакшн. Если на какой-либо стадии пайплайна обнаружится ошибка, оперативное информирование и совместная работа позволят быстрее решить проблему, чем если бы вам пришлось писать длинные отчеты для последующего согласования. Вот что представляет собой непрерывная доставка.

Другие советы по организации непрерывной доставки ищите в нашем руководстве по лучшим практикам CI/CD.

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

И хотя в некоторых организациях предпочитают выполнять финальный шаг процедуры релиза вручную, для других логичным завершением CI/CD-пайплайна является автоматизация релиза в продакшн — технология, называемая непрерывным развертыванием. Подробнее об этом рассказывается в следующем разделе этого руководства.

TeamCity — CI/CD-платформа, которая поддерживает огромное число различных инструментов сборки, фреймворков тестирования, контейнеров и поставщиков облачной инфраструктуры. Где бы ни размещались ваши билд-серверы — локально, в облаке или и там, и там, — TeamCity обеспечит максимально эффективное выполнение задач сборки.

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