Пишу про полезные материалы про IT, и собираю свой ламповый нетворкинг тут - https://t.me/+434aQiGpZtAyNTU6. Присоединяйтесь!

Оглавление.

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

В вакансиях все чаще требуется опыт работы с одним из инструментов в этой инфраструктуре – Jenkins, Travis, AWS, Gitlab CI/CD.

⚠️Я предлагаю вам посмотреть на этот процесс, глазами простого разработчика. Чем ему может помочь автоматизация. Что в конечном итоге скрывается под этой аббревиатурой, и как уже начать получать дивиденды в своей ежедневной рабочей практике.

Первые шаги

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

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

Я пытался пару лет подступиться к этому вопросу. Стильно, модно, молодежно. Да, дает кучу преимуществ. Но все попытки переварить официальную документацию, заканчивались неудачей. А видео уроки или материалы в общем доступе – чаще всего давали рецепт автоматизации какого-то конкретного кейса, который либо частично, либо полностью отличался от моего приложения.

Мне не хватало именно взгляда на основные шаги – что, зачем и как мы делаем. А уже потом реализации практических задач.

CI – continuous integration

Что же скрывается за термином "непрерывной интеграция". Когда мы работаем над созданием программного продукта – в одиночку, или в рамках команды, мы стараемся добавить в наш проект, несколько строк кода. Новый функционал, исправление или доработки. Суть не особо важна. В конечном счете – либо появляется новый код, либо появляются изменения в старом. И нам нужно убедиться, что эти новые изменения, не содержат ошибок, которые могут вызвать проблемы или неработоспособность приложения. ⛔️

❗️Рассмотрим на примере стандартного подхода к разработке, на основании git. Стандартный флоу – у нас есть 2 ветки – master, для сборки продукта, и develop – для разработки. Разработчик, получая очередную задачу, создает ветку от develop. Локально осуществляет реализацию, делает коммит, пуш, и МР (запрос на слияние).

Потенциально его код может содержать ошибки – проблемы с системами линтинга. Если речь про экосистему JS – то за основу можно взять инструмент Eslint. На других языках – по аналогии. Например в Python - это может быть Flake8 и т.д.

Может не проходить процедура сборки – в нашем случае npm run build (если мы используем webpack или Vite). В компилируемых языках – это процесс компиляции. В общем и целом – исходный код нашего приложения, может требовать некоторых подготовительных процедур, чтобы получить версию приложения, которую можно запускать в некоторой среде для эксплуатации.

В идеальном мире – мы как разработчики, можем локально запускать все необходимые проверки, и тестовые процедуры - компиляция, сборка и т.д.

npx eslint . –fix npm run build

И если все проходит успешно – отправлять наш коммит в общее хранилище кода.

Мы, к сожалению, или, к счастью, разрабатываем наше ПО, в реальном мире. Привет Нео :-).

Можно забыть, проигнорировать или наконец не знать – и пропустить проверки. Случится это может по самым разным причинам. Как итог – в кодовую базу попадает код с ошибками.😱

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

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

CI/CD инструменты. Gitlab

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

Так кстати, довольно часто делают. Если Вы знакомы с экосистемой JS/NodeJS, то могли слышать про библиотеку Husky. Эта штука помогает внедрить скрипты автоматизации. Например перед выполнением команды git commit. Мы настраиваем запуск сборки и линтера, они запускаются перед коммитом. И сам коммит создается, только если предыдущие шаги успешно завершились. Чем Вам не continuous integration? 😮

В целом да. Но более продвинутые системы, как обычно бывает, предоставляют более мощную, в плане функционала систему.

Мой выбор пал на Gitlab CI/CD, по двум причинам. Во-первых, это знакомый инструмент. Во-вторых – он предоставляет необходимый функционал, и настройка под мои задачи, в общем и целом, довольна проста. Можно было бы сделать на другой платформе – можно выбирать. Из тех, которых я касался – Github actions и Jenkins. На Github – в целом аналогично. Поэтому тут выбор я бы отнес к разделу внусовщины, или специфических кейсов. А вот Jenkins чуть посложнее. Тут уже надо более глубоко погрузится в настройку самой среды. С AWS поработать не удалось.

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

Какие основные части, которые нам понадобятся?

Вся настройка сводится к заполнению файла .gitlab-ci.yml, в корне репозитория. При этом, в разных ветках, содержимое файла может быть разным. По умолчанию можно ориентироваться на то, что в текущей ветке, этот файл будет содержать все CI/CD процессы, относящиеся к этой ветке.

Среда для выполнения кода

Сервис gitlab предоставляет Вам необходимые вычислительные мощности. Бесплатно из коробки. В базовом варианте это сводится к тому, что где-то на сервере, для наших нужд создается Docker контейнер. В котором специальная программа Runner, выполняет команды из файла .gitlab-ci.yml.

На этом этапе достаточно этой информации – при определенных действиях, например при пуше ветки в репозиторий, будет создан Docker контейнер, в котором некоторый инструмент выполнил команды автоматизации, которые мы перечислили в файле .gitlab-ci.yml.

Сам процесс выполнения шагов называют pipeline. Вы сами определяете, какие шаги (этапы) будут в вашем случае выполняться. Что здесь интересно для нас. Gitlab предоставляет визуальный интерфейс, для заполнения .gitlab-ci.yml файла. Он находится в репозитории, в основном меню, Build => Pipeline editor. В самом начале, здесь предложат создать и заполнить файл с настройками.

По этому пункту – весь процесс здесь, рассматривают как некоторое множество задач, называемых внутренним термином Pipeline. Пока ничего сложного.

Jobs

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

Пример базовой конфигурации

Давайте уже перейдем, хоть к минимальной, но практике. Настроим нашу первую Jobs, которая успешно отработает. Тем самым, мы убедимся, что не боги обжигают горшки, искорка появится в наших глазах, и наконец-то мотивация поднимется на достаточный уровень, чтобы уже разобраться и победить CI/CD. 🫡

Перейдем в Pipeline editor, выберем ветку develop, и нажмем кнопку Configure pipeline. Мы попадем в окно визуального редактора. По идее, команды можно писать в файле .gitlab-ci.yml напрямую. Преимущества визуального редактора – он хорошо подсвечивает ошибки в yaml синтаксисе, и иногда дает базовые подсказки. В остальном – дело вкуса.

Для визуальной и логической компоновки ваших Jobs, здесь есть так называемые стадии -stages. Не более чем группировка. В процессе работы pipeline – можно будет смотреть, какая стадия и какая jobs в ней выполняется.

Добавим первую стадию check

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

Здесь lint – название для Jobs.
Image – настройка образа.
ubuntu:22.04 название и версия Docker образа.

Если вы не знакомы с системой контейнеризации, на этом этапе имеет смысл посмотреть какие-то базовые руководства. Или дождаться моего материала. Если в двух словах – Docker, программа для запуска контейнеров. Контейнер – по сути операционная система, запущенная в рамках хост среды. Основной операционной системы, на том устройстве, где вы работаете. К примеру – вы можете установить на свою машину с Windows 10, Docker. И через него создать и запустить контейнер (программу, процесс), с установленной, выбранной операционной системой. Штука, близкая к виртуализации, с небольшими отличиями. 😨

Для нас здесь достаточно того факта, что для наших задач, Gitlab где-то запускает выбранную операционную систему, и в ней начинает выполнять наши шаги (команды) автоматизации. Очень важный вопрос – касательно операционной системы. Вообще, эту настройку можно не указывать – тогда gitlab автоматически установит образ ruby. Операционную систему, и среду для выполнения кода на этом языке.

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

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

Для теста выведем в консоль фразу “Gitlab CI/CD works!”

В выводе мы увидим подготовку и запуск контейнера. Некоторые предварительные команды настройки. И выполнение команд из нашего скрипта.

Это работает! 🫡

Какие итоги?

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

PS. Вам удалось лучше разобраться с базовыми основами CI/CD? Чего не хватило в материале? Оставляйте комментарии или присоединяйтесь ко мне в телеграм - https://t.me/+434aQiGpZtAyNTU6

Удачи

CI/CD для чайников — разберитесь, и начните наконец-то автоматизировать рутину в разработке. Часть1. Введение