GitLab - это опенсорсный сервис для хранения и управления Git-репозиториями с лисичкой на логотипе, то есть то место, где разработчики хранят свой код, чтобы при работе над общим проектом они могли вливать туда ветки со своими изменениями и подтягивать изменения других разрабов себе. Тут все стандартно: можно создавать репозитории и ветки в них, выполнять различные операции с ветками, редактировать код, управлять доступами, короче, весь джентельменский набор. И тут у нас есть большое различие с гитхабом: прикол в том, что он является облачным сервисом, где код хранится на серваках майкрософта, а гитлаб может работать как в облаке, так и на твоих собственных серверах, или как это называют в айти тусовочке - on-premise, что кстати весьма нравится большим компаниям, которые хотят чтобы их код и сопутствующие штуки-дрюки находились у них, а не где-то там в каком-то непонятном облаке. Ну и помимо хранения кода, тут наверчено куча всяких дополнительных штук: конечно, сейчас без этого никуда, одним только репозиторием никого не удивишь. Например, система мердж реквестов (merge request), которые в других местах называются пулл реквестами (pull request). Это нужно для того, чтобы проводить код ревью того кода, который ты хочешь влить в другую ветку. Здесь можно посмотреть внесенные изменения, назначить ревьюера, кто будет смотреть твой код, оставлять комменты, ставить апрувы, сливать ветки, короче, все что нужно для процесса код ревью. Помимо этого, есть всякие бизнесовые свистелки-перделки, типа системы управления задачами, чтобы можно было организовать работу в одном месте, или интеграции с другими сервисами, типа слака или джиры. Ну а вишенка на этом рыжем торте - это встроенный инструмент управления CI/CD.
То есть, если мы хотим все автоматизировать, то нам не нужно ставить отдельный CI/CD инструмент, как например дженкис и настраивать его связь с репозиторием - нас уже заранее посетил экзибит и встроил CI/CD пайплайны в наш репозиторий, чтобы все было в одном месте и нам было фантастически удобно! Такая же фича есть и у гитхаба, которая называется GitHub Actions но помни про ограничения: гитхаб на своей тачке не развернуть.
Так, теперь давай посмотрим как работает GitLab CI/CD. Гляди: у тебя есть твой гитлаб сервер, на котором находятся твои репозитории с кодом. Так же там хранится конфигурация пайплайнов, об этом подробнее расскажем далее, сейчас просто важно, то что сервер знает, что от него в итоге хотят. И этот сервер соединён с несколькими другими отдельными серверами, которые называются GitLab Runner, на которых как раз и выполняется та работа, которую мы описали в пайплайне. Пайплайн, если что, это такая последовательность действий которые мы хотим чтобы были выполнены автоматически - проверить код, затем запустить тесты, затем собрать проект, потом выкатить на сервак, налить чайку, вытряхнуть ковер и так далее. А раннер это так называемый агент, то есть программа, которая устанавливается на сервер, докер контейнер или в облако, и выполняет инструкции, которые лежат в специальном файле на основном гитлаб сервере. И эти раннеры могут быть развернуты на разных операционных системах, в зависимости от потребностей. Ну а если ты пользуешься облачным решением, то для тебя все эти сервера уже настроены, просто бери и пользуйся, не забудь только подписку оплатить. А в случае, если мы хотим сделать все сами, то путь самурая тут такой - сначала разворачиваешь у себя сам гитлаб, затем устанавливаешь раннер, затем этот раннер нужно зарегистрировать на гитлаб сервере, то есть подружить раннер и сервер. После этого раннеры станут видны на сервере и их можно начинать использовать. Окей, надо теперь научиться запускать на них процессы из пайплайна. Как это делается? Ну, поскольку у нас тут уже есть сам репозиторий с кодом, то пайплайны будут привязаны к нему, и происходит это путем того, что мы в нашем проекте создаем файл который должен называться .gitlab-ci.yml и который будет находится прямо в репозитории, так что гитлаб автоматом подтянет пайплайны для этого репозитория. Файл этот можно создать прямо в интерфейсе гитлаба, либо просто у себя внутри проекта и запушить его на сервер. А что же в нем нужно писать? Ну смотри, мы хотим выполнять действия в несколько этапов - сначала протестировать код, затем если все ок сделать сборку, затем задеплоить его на сервер и так далее. Каждая такой отдельный минимальный этап тут называется job. Тут мы используем декларативный стиль описания всего этого добра, то есть пишем то, что мы хотим получить, а не как это делать. Если работал с ансиблом, терраформом или дженкинсом то понимаешь в чем суть. Кстати, есть такая тема – GitFlic - это российская платформа для хранения репозиториев и работы с исходным кодом, которая точно будет работать без риска блокировки. Что можно делать на GitFlic? Тут есть и реестры пакетов и контейнеров, интеграция с Yandex.Cloud, поддержка S3, распределенный координатор для CI/CD, функционал правил для push-операций. А если потребуется миграция, то можно легко перенести свои проекты из GitLab Из приятного: команде до 5 человек можно работать бесплатно. В общем, бери на заметку и изучай, какие есть достойные альтернативы иностранным сервисам, таким как GitLab и GitHub.
Итак, первым делом мы пишем название нашей джобы. А внутри мы уже указываем параметры, по сути то самое, что мы хотим выполнить внутри этого шага. Далее идет первый обязательный параметр под названием script. Там мы указываем команды которые должны выполниться на раннере - например, установить зависимости, запустить тест, вывести сообщение. Теперь когда мы запушим этот файл в репозиторий, гитлаб увидит его, подтянет все данные и начнет выполнять джобы. И в следующие разы когда будем что-то пушить в ветку, наш пайплайн будет выполняться. Джобы, кстати, будут выполняться одновременно, а если во время выполнения скрипта произошла ошибка, то гитлаб пометит этот этап как зафейленный и ты сможешь посмотреть в логах что именно пошло не так. Однако, мы не всегда хотим, чтобы все запускалось параллельно - обычно мы хотим, чтобы сначала прошел один этап, например тесты, и только если они были успешны, уже тогда запускать следующий этап деплоя. Смысла одновременно тестировать и деплоить не очень много. Тут для удобной организации пайплайна используются стейджи (stages), которые позволяют логически сгруппировать джобы. Для этого нам нужно сделать блок стейджес , и написать там название этих этапов, а затем в в каждой джобе указать к какому стейджу она относится И теперь сначала будут выполнятся все джобы из тест стейджа, а только потом, если на предыдущем этапе все было успешно, джобы из деплой стейджа. Тут еще можно сделать так, чтобы джобы выполнялись не автоматически, а чтобы нужно было ручками зайти на гитлаб сервер и нажать пуск. Например, мы не хотим, чтобы все выливалось сразу на сервер, потому что не все части проекта готовы и мы не хотим все ломать. Тогда пишем атрибут when со значением manual и все будет как мы хотим. Что тут еще интересного есть? Да много всего! Например, возможность хранить всякие логины и пароли в переменных и доставать их во время выполнения скрипта, например если нужно куда-то подключиться. При этом в самом файле будут видны только названия переменных, и задавать их может только пользователь с особыми правами - всем остальным не нужно об этом знать. Для этого сначала в настройках проекта нужно все их указать, а затем используя знак доллара - вытащить в gitlab-ci.yml файле. Ну, а если тебе просто нужны не секретные переменные, а просто те значения, которые часто используются внутри скрипта, то их можно задать через блок variables написав там название переменной и затем ее значение, и дальше так же использовать через знак доллара. И кстати, от места где этот блок написан зависит область видимости - если пишем на самом верхнем уровне, то во всех джобах, а если внутри джобы - то очевидно только внутри нее Есть еще один тип переменных - это те, которые уже предопределены, и их можно брать и пользоваться. Например название ветки, имя комита, название стейджа, айди раннера, адрес сервера, какую длину волос оставить парикмахеру тебе на висках и куча других. И снова удобства! Например, мы хотим, чтобы чтобы какой-нибудь тест запускался только тогда, когда мы пушим в мейн ветку - на других не надо. Это легко сделать - добавляем блок rules, там пишем атрибут if и там уже условия. И вот тут мы как раз мы берем переменную где хранится название ветки и сравниваем его с нужной и если все ок, то джоба запустится. Круто же! По правде говоря, чего тут только нет. Инструмент обширный и его можно очень гибко настроить. Интересно? Записывайся на наш бесплатный урок курса по девопс, где помимо гитлаба, ты поработаешь еще и с дженкинсом, который не менее популярен, а так же с целой кучей инструментов, таких как docker, kubernetes, terraform, ansible, и другие тулзы, которые используют в работе девопс инженеры. А, и еще: стоит упомянуть одну особенность - мы можем запускать джобы не только прямо в операционной системе раннера, но и в изолированных docker контейнерах, которые будут создаваться в процессе работы пайплайна. И это очень удобно - мы можем указать image который нужен для нашей задачи, в котором уже будут все необходимые инструменты. Если тебя напрягли слова image, контейнер или докер, то посмотри наш видос про это, там все поподробнее рассказали. Если ты будешь использовать имейдж node.js, то у тебя будет доступна и сама нода, и нпм, то есть не нужно ставить их отдельно перед запуском. Это очень удобно, если ты планируешь гонять пайплайны от разных проектов на раннере - все изолированно и готово для работы. И чтобы это сделать, нужно просто написать в нашем ямл файле атрибут image, и в нем указать название имеджа с докерхаба, и нужный тег. Кстати, если нужно, то можно подключить дополнительные контейнеры, указав их в блоке services. Например, чтобы каждый раз не устанавливать базу данных при запуске контейнера, можно просто запустить ее в дополнительном. Вот такая классная штука этот гитлаб - настоящий швейцарский нож в мире CI/CD. И по традиции финальный вопрос - как ты думаешь, что из всех функций гитлаба можно отнести к CI, а что к CD?