В этой статье мы воспользуемся замечательным инструментом Gitlab CI/CD для автоматизации непрерывной интеграции. На примере PHP проекта, который включает в себя этапы: composer install, то есть установка всех зависимостей и библиотек; этап тестирования, запуск юнит тестов; и наконец деплой на сервер, в качестве которого будет выступать облачный PAAS Heroku; познакомимся с понятиями конвейера или pipeline, конфигурацией через gitlab-ci.yml, артефактами, разделением всего этого на stages и запуском jobs. Поехали…

Вводная

Что такое Gitlab?

Gitlab это такой Github на стероидах, по крайнем мере был им. Сейчас после покупки Github-a Microsoft, после колоссальных вложений, на Github-е начали появляться новые фишки: Github Actions, проверка кода и, после многолетнего ожидания, впервые появились бесплатные приватные репозитории 😮. Молодец Microsoft. А ведь старички знают, все эти штуки изначально были в Gitlab.  СI/CD и пайплайн одним из первых появился на Gitlab. Помню, когда пайплайн только только начал внедряться в Bitbucket, на Gitlab он уже существовал давно. Еще Bitbucket для бесплатного пользования pipeline предлагал 500 минут в месяц, в то время как Gitlab, уже на тот момент, предлагал 2000 минут для бесплатного аккаунта!

Конечно не забываем о такой киллер фиче, как установка Gitlab на собственном сервере. Интересно, когда такое Github  внедрить…

Что такое CI/CD Pipeline?

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

PHP «MVP»

Что из себя должен представлять минимальный PHP проект. Естественно он должен собираться через composer, иметь отделенный от корня проекта entrypoint(public/index.php), запускаться на PHP > 7, и конечно же иметь автотесты. Много автотестов, которые запускаются автоматически 🙂

Также он должен быстро доставляться до клиента, то есть на прод.

Gitlab CI/CD дает нам такие прекрасные возможности и нужно ими воспользоваться. У нас будут три шага, от начала написания кода, до доставки всего этого на сервер.

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

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

Deploy — деплой на сервер, внесение изменении в видимый продукт.

Что ж, приступим…

Как начать?

Начать нужно с создания файла .gitlab-ci.yml в корне проекта. .gitlab-ci.yml — конфиг файл, в котором описывается что нужно запускать и как нужно запускать. Естественно он имеет свою семантику, о которой можно почитать в очень подробном справочнике https://docs.gitlab.com/ee/ci/yaml/, но все необходимое я опишу ниже.

В конечном итоге, наш файл будет выглядеть так:

gitlab-ci.yml — основное

Начнем с самого начала

stages — из каких шагов будет состоять пайплайн. Если не указаны  stages, Gitlab сам автоматически создаст stages build test deploy, но лучше всегда явно указывать шаги. То что, имена совпали с Gitlab-овскими случайность, похоже ребята из Gitlab согласны с тем из каких, минимально допустимых, шагов должен состоять CI/CD. Имена для stages можете выбирать любые, хоть my-awesome-build

Следующее указать какие jobs будут выполняться в stage.

jobs — это название работы(composer, test, deploy), который будет выполняться в каком то шаге, их может несколько в одной stage. Обязательное поле.

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

script— действия, которые должна выполнить job, обязательное поле.

Например, описание всей работы будет такой — посадить помидоры на даче. Тогда, в огороде нужно выкопать яму(stage), трое ребят(jobs) должны использовать для этого лопаты (script).

Этих ключевых слов достаточно для настройки базового пайплайна.

Текущий пайплайн состоит из трех шагов:

Сборка проекта (composer) — сюда входит процесс установки всех зависимостей через composer install. После этого шага билд должен быть готов к выполнению своих обязанностей или проще говоря к запуску кода.

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

Деплой(deploy) — доставка продукта на сервер. В данном случае проект будет заливаться на внешнее облако Heroku.

gitlab-ci.yml — подробнее

На шаге build есть операция кэширования

Основное предназначение — снизить время выполнения шага за счет сохранения часто используемых файлов. Цель была закешировать установленные библиотеки vendor, чтобы во первых, не устанавливать их снова при следующем шаге, во вторых, передать их в следующий stage. Но выяснилось что shared runners, который используется по умолчанию на официальном сайте, не поддерживают общий кеш.

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

https://docs.gitlab.com/ee/ci/caching/index.html#how-archiving-and-extracting-works

Как раз с этим я и столкнулся, поэтому этот кусок кода закомментирован. Но кэширование все же мощный инструмент оптимизации при должной настройке сервера Gitlab.

Runner, по простому, эта среда в которой будет выполняться job.

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

Также артефакты будут доступны для скачивания по ссылке после завершения пайплайна.

Например, в шаге test используется phpunit, который находится в папке vendor. В самом test не проводиться установка библиотек, а берется из предыдущего шага через правило

deploy — для деплоя используется утилита dpl от компаний TravisCI. Основное это указать название app и сохранить АПИ ключ Heroku в переменную Gitlab. Настройка Heroku выходить за рамки статьи. А вот сохранить переменные окружения в Gitlab можно в настройках проекта /settings/ci_cd.

only — означает запускать только при условии, в данном случае только на ветке мастер

Запуск

После создания в корне проекта gitlab-ci.yml, запушьте в репозиторий код. Пайплайн запуститься автоматически при обнаружений gitlab-ci.yml.

Состояине пайпланов можно посмотреть по ссылке https://gitlab.com/Carsak/weather-forecast/pipelines. Если на каком либо шаге произошла ошибка пайплайн высветить его красным.

Если все сделано правильно, а код написан корректно, то все шаги будут зелеными 🙂

Поздравляю! Автоматизация процесса непрерывной интеграции и развертывания прошла успешно

Пример пайплайна можно посмотреть по адресу https://gitlab.com/Carsak/weather-forecast