Рабочий процесс CDS — ключевая особенность платформы OVH CI / CD. Этот структурный выбор добавляет дополнительную концепцию к конвейерам и заданиям CI / CD и после более чем трех лет интенсивного использования, безусловно, является важной особенностью.



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

Основной элемент: «Работа».

Задание состоит из шагов, которые будут выполняться последовательно. J О.Б. выполняется в специальной рабочей области (т.е. файловая система). Новое рабочее пространство назначается для каждого нового запуска задания.



Стандартная сборка работа выглядит следующим образом:



Вы можете использовать «встроенные» действия, такие как checkoutApplication, скрипт, jUnit, загрузка / скачивание артефактов.

• Действие c heckoutApplication клонирует ваш репозиторий Git
• Действие сценария выполняет вашу команду сборки как «make build».
• Действие artifactUpload загружает ранее созданные двоичные файлы
• Действие jUnit анализирует данный XML-файл в формате Junit, чтобы извлечь результаты его тестирования.

Конвейер: как организовать работу с этапами

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



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

Возьмем реальный вариант использования: конвейер, на котором построена CDS. Этот конвейер состоит из четырех этапов: 

• Этап «Build Minimal» запущен для всех веток Git. Основная цель этого этапа — скомпилировать Linux-версию двоичных файлов CDS. 
• Этап «Сборка другой ОС / Arch» запускается только  в основной ветке. На этом этапе компилируются все бинарные файлы, поддерживаемые os / arch: linux, openbsd, freebsd, darwin, windows-386, amd64 и arm.  
• Этап «Пакет» запущен для всех веток Git. На этом этапе готовится образ докера и пакет Debian.
• Наконец, запускается этап «Публикация» независимо от ветки Git. 

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

Рабочие процессы CDS: как организовать ваши конвейеры

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

Возьмем пример. Один рабочий процесс для создания и развертывания трех микросервисов:  

• Создайте каждый микросервис 
• Разверните их на подготовительной стадии 
• Запустите интеграционные тесты в тестовой среде 
• Разверните их в производственной среде, а затем повторно запустите интеграционные тесты в производственной среде.

Для строительной части существует только один конвейер для управления, который используется три раза в рабочем процессе с разными контекстами приложения / среды каждый раз. Это называется «контекст конвейера».

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



Давайте посмотрим на реальный вариант использования. Это рабочий процесс, который создает, тестирует и развертывает CDS в производственной среде в OVH ( да, CDS создает и развертывает себя! ):

1. Для каждого коммита Git запускается рабочий процесс
2. Пользовательский интерфейс упакован, все двоичные файлы подготовлены, а образы докеров созданы. Задание «UT» запускает модульные тесты. Задание «ИТ» устанавливает CDS в эфемерной среде и запускает в ней интеграционные тесты. Часть 2 автоматически запускается при всех коммитах Git.
3. В части 3 развертывается CDS в нашей подготовительной среде, а затем запускаются интеграционные тесты. Он запускается автоматически, когда текущая ветвь является главной.
4. И последнее, но не менее важное: часть 4 развертывает CDS в нашей производственной среде.

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





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



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

Больше чем “Pipeline as Code”… “Workflow as Code”

С CDS нет никаких компромиссов. Некоторые пользователи предпочитают рисовать рабочие процессы через веб-интерфейс, другие предпочитают писать код на yaml. CDS позволяет делать и то, и другое!

Есть два способа хранить рабочие процессы: либо в базе данных CDS, либо в репозитории Git с исходным кодом. Мы называем это «Рабочий процесс как код».

Это позволяет иметь рабочий процесс в одной ветке, а затем развивать его в другой ветке. CDS создаст экземпляр рабочего процесса на лету на основе кода yaml, присутствующего в текущей ветке.

CDS — это программное обеспечение с открытым исходным кодом OVH, которое можно найти на github.com/ovh/cds, с документацией на ovh.github.io/cds.