Цикл непрерывной интеграции. Схема иллюстрирует классический процесс Continuous Integration — методологию разработки, при которой код проходит через автоматизированный цикл проверок и сборки. Процесс начинается с этапа Coding, где разработчики пишут код, затем изменения проходят через Merge для объединения с основной веткой. После слияния запускается Build для компиляции приложения, далее следует Test для автоматического тестирования, и Deploy для развёртывания в тестовой среде. Завершается процесс этапом Release — выпуском готовой версии продукта. Круговая форма диаграммы подчёркивает непрерывность и цикличность процесса: после релиза команда возвращается к написанию нового кода, запуская следующую итерацию разработки.
Как настроить CI/CD для Cloud Functions из SourceCraft
Интеграция Yandex Cloud Functions с SourceCraft позволяет сократить время развёртывания на 70% и существенно упростить процесс автоматизации.
15 сентября 2025 г.
20 минут чтения
Краткий пересказ YandexGPT
- CI/CD (Continuous Integration и Continuous Delivery) — это подходы, которые упрощают процесс разработки: изменения кода автоматически тестируются и разворачиваются в рабочем окружении без прерывания работы сервиса.
- SourceCraft — платформа Яндекса для совместной разработки, которая объединяет репозиторий кода, инструменты код-ревью, планирование задач и встроенный CI/CD.
- Continuous Integration (CI) предполагает регулярное объединение кода разработчиков в общую базу и автоматическую проверку сборки и тестов при каждом внесении изменений.
- Continuous Delivery (CD) расширяет принципы CI и включает автоматическое развёртывание обновлений, проверку их работоспособности и сбор обратной связи.
- Полный CI/CD-цикл включает внесение изменений в код, сборку и тестирование проекта, пометку кода тегом версии или формирование релиза, автоматическое развёртывание обновления на целевое окружение.
- GitHub Flow использует простую схему ветвления для непрерывного развёртывания: главная ветка репозитория (обычно main) содержит стабильный код, а разработчики работают над новыми функциями в отдельных feature-ветках.
- В SourceCraft система CI/CD настраивается через единый конфигурационный файл .src.ci.yaml, который описывает все необходимые процессы автоматизации для проекта.
- Workflow в SourceCraft могут запускаться при различных условиях (триггерах), например при загрузке изменений в ветку или создании пулл-реквеста.
- Для взаимодействия с Yandex Cloud Functions SourceCraft использует сервисный аккаунт — специальную учётную запись для автоматизированных операций CI/CD.
- Пример CI/CD-пайплайна показан на примере функции CropImage с тремя окружениями: integration, test и prod.
- Для защиты продакшн-окружения используются такие подходы, как тегирование версий функций и разделение окружений по каталогам в Yandex Cloud.
Непрерывная интеграция и доставка (CI/CD) упрощают процесс разработки. Изменения кода автоматически тестируются и разворачиваются в рабочем окружении, функция продолжает работать, а обновление происходит в фоне без прерывания сервиса.
SourceCraft — платформа Яндекса для совместной разработки. Она объединяет репозиторий кода, инструменты код‑ревью, планирование задач и встроенный CI/CD. Код функций хранится в Git‑репозитории SourceCraft. Встроенный механизм CI/CD автоматически собирает изменения и отправляет их в облако. Интеграция с Yandex Cloud Functions обеспечивает быструю доставку изменений до облачных функций.
Это первая из двух частей статьи про CI/CD. В ней Илья Шикалов, технический менеджер проектов Yandex Cloud расскажет о принципах CI/CD и работе в SourceCraft. Илья рассмотрит подготовку конфигурационного файла .src.ci.yaml в SourceCraft и подключение облачных функций через сервисный аккаунт. На примере функции CropImage разберёт полный CI/CD‑процесс: от изменений в репозитории до автоматического развёртывания в разных окружениях. А в конце разберёт защиту продакшн‑среды через тегированные версии и раздельные каталоги в Yandex Cloud.
Во второй части статьи покажем, как настроить аналогичный процесс через GitHub Actions для команд, предпочитающих нативные инструменты GitHub.
Принципы Continuous Integration и Continuous Delivery
Continuous Integration (CI, непрерывная интеграция) — подход к разработке программного обеспечения. Разработчики регулярно объединяют свой код в общую базу. Каждая загрузка изменений (push) или запрос на слияние кода (pull request) автоматически запускает сборку проекта и тесты.
Система проверяет корректность сборки приложения и успешность прохождения всех тестов. CI позволяет находить проблемы интеграции на ранней стадии, когда небольшие изменения легко исправить.
Continuous Delivery (CD, непрерывная доставка) расширяет принципы CI. Система не только собирает и тестирует код, но и автоматически развёртывает обновления, проверяет их работоспособность и собирает обратную связь.
Цель CD — поддерживать в репозитории актуальную версию кода, готовую к выпуску на продакшн‑серверы. Команда поддерживает одну или несколько стабильных веток (например, main), из которых можно развернуть приложение в любой момент.
Экосистема Continuous Delivery. Схема представляет комплексную экосистему Continuous Delivery, где центральная практика непрерывной поставки поддерживается шестью взаимосвязанными компонентами. Continuous Integration обеспечивает регулярное слияние кода в основную ветку, Continuous Testing автоматизирует проверку качества на всех этапах, а Continuous Deployment отвечает за автоматическое развёртывание изменений. Continuous Monitoring предоставляет постоянный контроль работоспособности системы в продакшене, Continuous Feedback собирает обратную связь от пользователей и систем, а Continuous Development поддерживает непрерывный процесс разработки новых функций. Круговая структура диаграммы подчёркивает, что все шесть компонентов работают синхронно, образуя единый цикл поставки программного обеспечения, где каждый элемент усиливает эффективность остальных.
Как работает полный CI/CD‑цикл
Разработчик вносит изменения в код. Система CI собирает и тестирует проект до успешного завершения всех проверок. Конвейер CD помечает код тегом версии или формирует релиз.
После этого система автоматически развёртывает обновление на целевое окружение. Новая версия приложения начинает обслуживать пользователей. Базовый сценарий предполагает автоматическое развёртывание каждого изменения из основной ветки напрямую в продакшн. Для критичных бизнес‑процессов такой подход несёт риски — поэтому добавляют промежуточные этапы контроля. Код сначала разворачивают на пре‑прод окружении (промежуточная среда, идентичная продакшну) для сквозного тестирования всей системы. Релиз‑менеджер вручную подтверждает готовность версии, и только после этого изменения попадают в продакшн.
GitHub Flow для развёртывания функций
GitHub Flow использует простую схему ветвления, которая хорошо подходит для непрерывного развёртывания.
Параллельная разработка через feature‑ветки. Схема демонстрирует классическую модель ветвления GitHub Flow для управления параллельной разработкой функционала. В основе лежит ветка Main, содержащая стабильный production‑ready код, от которой ответвляется Feature Branches для изолированной разработки новых возможностей. Процесс разработки представлен последовательностью коммитов — голубые блоки показывают фиксацию изменений как в feature‑ветке, так и в основной ветке, где могут параллельно вноситься критические исправления. Жёлтые блоки Merge обозначают точки интеграции, где проверенный код из feature‑ветки вливается обратно в Main через pull request. Стрелки визуализируют направление потока изменений: от создания feature‑ветки через серию коммитов до финального слияния с основной веткой. Такая архитектура позволяет нескольким разработчикам работать над разными функциями одновременно без риска дестабилизации основного кода.
Главная ветка репозитория (обычно main) содержит только стабильный код, готовый к выпуску. Разработчики работают над новыми функциями или исправлениями в отдельных ветках — их называют feature‑ветками (ветки для новых функций). Они ответвляются от main.
После завершения работы разработчик открывает запрос на слияние кода (пулл‑реквест, pull request, PR). Команда проверяет изменения, после чего ветка сливается обратно в main. В основную ветку попадает только проверенный код — это обеспечивает качество выпуска.
Автоматизация развёртывания
Поскольку основная ветка всегда остаётся готовой к продакшну, можно настроить автоматический процесс. События в репозитории запускают развёртывание в соответствующие окружения.
Типичная схема автоматизации включает следующие правила:
-
Изменения в любой feature‑ветке разворачивают обновление функции в промежуточном окружении (интеграционная среда).
-
Создание пулл‑реквеста в
mainзапускает развёртывание на тестовое окружение для финальной проверки. -
Слияние пулл‑реквеста в
mainавтоматически обновляет функцию в продакшн‑окружении.
Именно такую логику реализуют CI/CD‑инструменты SourceCraft. Система автоматизации берёт на себя сборку, тестирование и развёртывание, позволяя команде разработки сосредоточиться на коде.
Workflow‑файл для SourceCraft
Система CI/CD в SourceCraft настраивается через единый конфигурационный файл в корне репозитория. У этого файла формат YAML и название .src.ci.yaml.
Файл описывает все необходимые процессы автоматизации для проекта. В отличие от GitHub Actions, где можно хранить несколько файлов для разных задач, SourceCraft использует один файл конфигурации. Он содержит описание всех цепочек обработки кода.
Полный цикл DevOps. Схема представляет классический DevOps‑конвейер, состоящий из семи последовательных этапов разработки и поставки программного обеспечения. Процесс начинается с Plan — этапа планирования функционала и архитектуры, переходит к Code — написанию кода разработчиками, затем следует Build — компиляция и сборка приложения. На этапе Test выполняется автоматизированное тестирование, после чего создаётся Release — версия для выпуска, которая проходит Deploy — развёртывание в продакшн‑среде, и завершается Operate — мониторингом и поддержкой работающей системы. Схема чётко визуализирует границы двух ключевых практик: Continuous Integration охватывает этапы от написания кода до тестирования, обеспечивая регулярную интеграцию изменений, а Continuous Delivery расширяет процесс от тестирования до развёртывания, гарантируя готовность кода к выпуску в любой момент. Этап тестирования выступает связующим звеном между CI и CD, подчёркивая критическую важность качества кода как для интеграции, так и для поставки.
Типы workflows в проекте
Файл .src.ci.yaml содержит несколько workflows, каждый со своим условием запуска (триггером) и шагами выполнения:
-
CI/CD Integration запускается при загрузке изменений в любую ветку с префиксом
feature. Система выполняет сборку кода, затем развёртывает новую версию функции в интеграционное окружение — стенд для отладки и тестирования. -
CI/CD Test запускается при создании пулл‑реквеста в ветку
main. Система развёртывает текущую версию функции на тестовое окружение. Команда проводит финальное тестирование перед выпуском. -
CI/CD Prod запускается при изменениях в
mainпосле пулл‑реквеста. Система автоматически развёртывает обновлённый код функции в продакшн‑окружении. -
CI/CD Custom — дополнительный workflow для демонстрации гибкости настройки. Настраивается аналогично Integration, но вместо готового шага развёртывания использует скрипт, который вызывает интерфейс командной строки Yandex Cloud (CLI) для расширенных возможностей.
Условия запуска workflows
Секция on: в конфигурационном файле задаёт условия запуска workflows — триггеры. Файл указывает два типа событий: push (загрузка изменений) и pull_request (запрос на слияние).
Событие push запускает два workflows — Integration и Prod. Они фильтруются по ветке: изменения в main запускают CICD Prod, а изменения в feature‑ветке запускают CICD Integration. Событие pull_request привязано к CICD Test.
Кроме условий на ветки, добавлен фильтр по пути. Workflows реагируют только на изменения в директории src/, где находится код функций. Изменения в других файлах и папках, например в документации, не запускают процесс развёртывания.
Шаги выполнения workflows
Каждый workflow содержит шаги выполнения: сборку приложения и развёртывание Yandex Cloud Functions. Сборка включает установку зависимостей и компиляцию кода.
SourceCraft предоставляет готовые шаги — их называют «кубиками». Они решают распространённые задачи автоматизации. Стандартные workflows Integration, Test и Prod используют встроенный блок развёртывания функции Yandex Cloud Functions.
Достаточно указать имя функции и папку с кодом — платформа сама собирает образ и обновляет функцию.
Гибкая настройка через CLI
Когда функциональности готовых блоков недостаточно, можно выполнять произвольные команды. Workflow CICD Custom развёртывает функцию через прямой вызов утилиты yc — это Yandex Cloud CLI с нужными параметрами.
Такой вариант требует больше настроек, но даёт максимальную гибкость. Через CLI можно работать с любыми ресурсами Yandex Cloud, не только с функциями.
Подготовка файла к работе
Перед запуском workflows файл .src.ci.yaml заполняется корректными значениями. В шаблоне заменяются все временные заменители (плейсхолдеры) на реальные данные.
Это имена и идентификаторы функций для каждого окружения, ID облака и каталогов, имя сервисного аккаунта и другие параметры. В конфигурации указывается секрет с ключом — о его настройке расскажем дальше.
Сервисный аккаунт для Yandex Cloud Functions
SourceCraft автоматически управляет ресурсами в облаке через сервисный аккаунт Yandex Cloud. Сервисный аккаунт — это специальная учётная запись для взаимодействия сервисов. В том числе, для автоматизированных операций CI/CD. Она не привязана к личным учётным данным разработчиков.
Для развёртывания функций создаётся отдельный сервисный аккаунт.
Создание и настройка сервисного аккаунта включают в себя три шага:
-
Создание аккаунта. Сервисный аккаунт создают через консоль управления Yandex Cloud или командную строку. Рекомендуем использовать понятное имя (например,
functions‑cicd‑sa). -
Назначение ролей. Аккаунту назначают роль
functions.admin(администратор функций) в Yandex Cloud Functions. Эта роль позволяет создавать и обновлять функции. Права выдают в нужном каталоге — например, в каталоге тестового окружения. -
Создание ключа доступа. Для сервисного аккаунта создают авторизованный ключ в формате JSON. В консоли Yandex Cloud можно скачать файл с ключами: публичным и приватным.
Интеграция с SourceCraft:
-
Добавление ключа как секрета. Ключ сохраняют в SourceCraft как защищённую переменную (секрет). В интерфейсе SourceCraft есть раздел настроек репозитория для хранения секретов CI/CD. Содержимое JSON‑файла копируют и сохраняют как новый секрет с именем (например,
YC_SERVICE_KEY). -
Указание секрета в конфигурации. В workflow‑файле .src.ci.yaml все действия с авторизацией в Yandex Cloud ссылаются на добавленный секрет через переменную или встроенную функцию платформы. Имя секрета в файле должно точно совпадать с именем из предыдущего шага.
Результат настройки
После выполнения этих шагов конвейер автоматизации SourceCraft получает доступ к Yandex Cloud Functions. При запуске workflows платформа подставляет ключ сервисного аккаунта из секрета. Система может выполнять операции — например, вызывать API для создания новой версии функции.
CI/CD‑пайплайн на примере функции CropImage
Рассмотрим применение описанных принципов на практике с облачной функцией CropImage. Для неё настроены три окружения:
-
integration — отдельная функция
cropimage‑integrationдля разработки и интеграционного тестирования; -
test — функция
cropimage‑testдля тестового окружения перед продакшном; -
prod — функция
cropimage‑prodдля боевого окружения.
Все три функции созданы в Yandex Cloud как пустые шаблоны, готовые к обновлению кода из репозитория. Исходный код находится в каталоге src/ репозитория SourceCraft.
Файл конфигурации .src.ci.yaml добавлен в корень репозитория. Он содержит четыре процесса автоматизации (workflow) для разных ситуаций: Integration, Test, Prod и Custom.
Этапы CI/CD‑процесса
|
Этап |
Действия и результаты |
|
Разработка в feature‑ветке |
Разработчик создаёт изменения в новой feature‑ветке, отделённой от main. Изменения затрагивают код функции в папке src/. После загрузки изменений срабатывает триггер workflow CICD Integration. SourceCraft запускает сборку проекта. Система развёртывает код в интеграционном окружении. В Yandex Cloud создаётся новая версия функции cropimage‑integration с обновлённым кодом. Команда сразу видит результат изменений на промежуточной среде. Можно выполнить интеграционные тесты или проверить функциональность вручную. |
|
Создание пулл‑реквеста |
Разработчик создаёт пулл‑реквест из feature‑ветки в main для проверки изменений. Команда проводит код‑ревью и тестирование. Это событие запускает workflow CICD Test. Конвейер автоматизации развёртывает текущую версию на тестовое окружение cropimage‑test. Команда проводит финальное тестирование — проверяет корректную работу с новыми изменениями. Автоматические тесты выполняются в рамках этого же конвейера. |
|
Слияние с основной веткой |
После прохождения код‑ревью и одобрения изменений пулл‑реквест сливается с основной веткой main. Коммит в main автоматически инициирует workflow CICD Prod. Этот конвейер развёртывает обновление на продакшн (cropimage‑prod). Боевая функция получает новую версию кода и начинает обслуживать реальные запросы. |
|
Альтернативный workflow через CLI |
В репозитории настроен экспериментальный workflow CICD Custom. Он подключён к тому же триггеру, что и Integration — загрузка изменений в feature‑ветку. В конфигурации .src.ci.yaml у CICD Custom те же условия запуска. Но шаг развёртывания выполняется не готовым блоком автоматизации («кубиком»), а командой yc — интерфейсом командной строки Yandex Cloud (CLI). После добавления изменений в код и загрузки в feature‑ветку запускается пайплайн CICD Custom. Логи выполнения показывают шаги развёртывания через CLI. Функция cropimage‑integration получает обновлённый код. Этот опыт подтверждает гибкость настройки — можно настраивать любые действия в CI/CD, выходящие за рамки стандартных сценариев. |
Особенности конфигурации
Во всех workflow предусмотрено условие — они реагируют только на изменения внутри каталога src/.
Такое ограничение защищает от случайного запуска развёртывания при правках, не влияющих на код, — например, изменений в документации.
Защита продакшна: теги версий и отдельные каталоги
Автоматическое развёртывание устраняет многие ручные ошибки. Но обновления не должны нарушать работу критичных сервисов. Для облачных функций в бизнес‑процессах особенно важна стабильность продакшн‑окружения.
Рассмотрим два подхода для защиты от нежелательных эффектов непрерывных обновлений.
Тегирование версий функций
Yandex Cloud Functions позволяет помечать определённую версию функции пользовательским тегом. Если у функции есть тегированная версия, внешние системы могут вызывать её именно по тегу, а не по последней версии.
Развёртывание новой версии не затронет пользователей, которые обращаются к закреплённому тегу. Например, можно пометить тегом текущую стабильную версию перед экспериментами с новым кодом. Все клиенты, вызывающие функцию по этому тегу, продолжат работать со старой версией. Тег обновляется вручную на новую версию только после проверки.
Помеченные версии не удаляются автоматически системой управления версиями. Старые неименованные версии могут удаляться по мере накопления. Тегирование позволяет зафиксировать ключевую функцию в стабильном состоянии на время изменений.
Разделение окружений по каталогам
Другой способ — изолировать продакшн‑среду от тестовых на уровне облака. Создаётся отдельный каталог Yandex Cloud для боевого окружения. Функции продакшна развёртываются в этом каталоге.
Процессы CI/CD для тестовых сред работают под сервисным аккаунтом без прав на продакшн‑каталог. Для продакшн‑развёртывания используется отдельный сервисный аккаунт с доступом только к боевому каталогу. Настраивается соответствующий процесс автоматизации (workflow), запускающийся при загрузке изменений в main.
Если тестовый конвейер автоматизации по ошибке попробует изменить что‑то в продакшне, у него не будет технической возможности — права не позволят.
Оба подхода можно совмещать. В реальных сценариях DevOps‑команды дополнительно применяют другие меры. Например, поэтапный вывод новой версии, мониторинг метрик и контроль качества.
Теги и раздельные каталоги — простые и эффективные инструменты для повышения надёжности. Команда выбирает нужный уровень защиты исходя из требований надёжности и характера проекта.
