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

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

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

Первый шаг при внедрении непрерывной интеграции — перенос всей кодовой базы в систему контроля версий, например в Git, Mercurial или Perforce. После этого всем членам команды нужно выработать привычку часто делать коммиты изменений. Каждый коммит в ветку main запускает пайплайн, сборку и тестирование нового кода, позволяя быстро получить обратную связь.

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

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

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

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

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

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

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

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

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

Чтобы избежать этих проблем, можно на первом этапе создания сборки упаковать код в контейнер. Контейнер включает в себя все зависимости, необходимые для запуска программы. Тем самым вы гарантируете портативность: ПО можно развертывать в разных средах.

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

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

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

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

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

Релиз вручную (его еще называют «непрерывная доставка») удобен, если:

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

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

CI/CD — это практика DevOps, которая использует автоматизацию для быстрого получения обратной связи на каждом этапе разработки. Она помогает находить и исправлять ошибки сразу после внесения изменений, делая разработку более эффективной. Перемещая проверки на более ранние стадии (по принципу «сдвига влево») и получая обратную связь быстрее, вы можете сразу обнаруживать ошибки. Создание автоматизированного пайплайна помогает применять эти техники на практике.

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

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

Наше решение TeamCity Pipelines помогает автоматизировать существующие CI/CD-процессы.

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

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

TeamCity можно развернуть как на своих серверах, так и в облаке. Это даёт вам свободу выбора места выполнения пайплайнов и возможность легко их масштабировать. Параллелизация тестов и обратная связь в реальном времени помогают быстрее находить и исправлять ошибки для более продуктивной работы.