GitLab CI/CD
Что-то вроде GitHub Actions, но для GitLab. Настраиваем сборку проекта.
Время чтения: 8 мин
- О GitLab
- Кратко
- Пример
- Как пользоваться
- Основные понятия
- Создаём .gitlab-ci.yml
- Задаём подготовительные команды
- Указываем этапы
- Описываем джобы и задаём команду
- Запуск вручную
- Продолжение при провале
- Выполнение джобов по условию
- Запуск по расписанию
- Серия джобов
Обновлено 24 мая 2022
В этой статье мы говорим про инструменты CI/CD (Continuous Integration и Continuous Delivery). Под этими терминами понимается итерационный процесс сопровождения кода: тестирование и отладка кода, автоматизация рутинных действий, сборка приложений, размещение приложений в магазинах приложений и так далее. Подробно об этом говорится в статье «Что такое CI/CD».
О GitLab
Скопировать ссылку на секцию «О GitLab» Скопировано
GitLab — популярный веб-сервис для совместной разработки и поддержки программного обеспечения. Вы можете работать с Git-репозиториями, управлять задачами, обсуждать правки с вашей командой, писать wiki-документацию, оценивать качество, выпускать релизы и даже мониторить работающие программы — и всё это в одном месте.
Кратко
Скопировать ссылку на секцию «Кратко» Скопировано
GitLab CI — инструмент, встроенный в GitLab для автоматизации рутинных задач, возникающих в процессе разработки программного обеспечения. Спектр таких задач огромен и отличается от проекта к проекту, но основные — это тестирование, статический анализ, проверка стиля написания кода и деплой (выпуск) приложения. GitLab CI — конкурент другого популярного инструмента, GitHub Actions. Эти два сервиса во многом похожи, но есть некоторые отличия.
Пример
Скопировать ссылку на секцию «Пример» Скопировано
Допустим, мы договорились в команде об особых правилах оформления кода при помощи EditorConfig, установили его как дев-зависимость и сделали его доступным с помощью команды npm run editorconfig . Можно запускать проверку каждый раз перед коммитом, но всегда будут ситуации, когда это забудут сделать, и код, оформленный неправильно, попадёт в репозиторий. Здесь приходит на помощь GitLab CI/CD — достаточно создать в корне проекта файл .gitlab-ci.yml со следующим содержанием:
И теперь каждый раз, когда в репозиторий попадает новый код, он будет проверяться на соответствие правилам, а ошибки будут видны в интерфейсе GitLab.
Как пользоваться
Скопировать ссылку на секцию «Как пользоваться» Скопировано
Основные понятия
Скопировать ссылку на секцию «Основные понятия» Скопировано
Основной сущностью в GitLab CI/CD является пайплайн (pipeline) — конвейер, который может состоять из:
- джобов (jobs), описывающих что нужно выполнить;
- этапов (stages), указывающих когда или в какой последовательности нужно выполнить джобы.
Джобы в одном этапе обычно выполняются параллельно. Если все джобы завершились успешно, выполнение переходит к следующему этапу и так далее. Если любой из джобов завершился ошибкой, то выполнение останавливается, и весь пайплайн (обычно) считается проваленным.
Создаём .gitlab — ci . yml
Скопировать ссылку на секцию «Создаём .gitlab-ci.yml» Скопировано
GitLab CI полностью конфигурируется с помощью одного файла в формате YAML, который нужно создать в корне проекта — .gitlab-ci.yml.
Джобы часто могут иметь одинаковые свойства, например, образ среды, в которой выполняются действия, предварительные команды и т. д. Чтобы не повторять их каждый раз, нужно объявить их в секции default . Если какому-то джобу нужны другие параметры, можно указать их внутри этого джоба, и они перезапишут глобальные параметры.
В первую очередь нужно указать Docker-образ (подробнее в статье «Что такое Docker»), в котором будут выполняться джобы. В большинстве случаев нам подойдёт официальный образ Node.js node : lts — это означает, что наши команды будут выполняться внутри операционной системы Linux с установленными Node.js, npm и даже Yarn. Про буквы lts можно почитать в разделе про версионирование Node.js.
Задаём подготовительные команды
Скопировать ссылку на секцию «Задаём подготовительные команды» Скопировано
При работе с CI/CD во фронтенд-проектах чаще всего перед выполнением основного действия необходимо установить зависимости. Для этого мы можем указать их в секции before _ script — эти команды будут выполняться в каждом джобе перед основным действием.
Указываем этапы
Скопировать ссылку на секцию «Указываем этапы» Скопировано
Предположим, что мы хотим запускать сначала проверку кодовой базы с помощью EditorConfig и Stylelint, а потом, если они обе завершатся успешно, запустить тесты. В этом примере можно выделить два этапа: стиль кода и тесты. Определить этапы можно при помощи ключевого слова stages :
Описываем джобы и задаём команду
Скопировать ссылку на секцию «Описываем джобы и задаём команду» Скопировано
Теперь укажем все три джоба. Для этого мы вначале указываем название джоба, указываем его этап при помощи ключевого слова stage и передаём список команд в script . В нашем примере каждый джоб будет запускать по одному npm-скрипту.
А вот схематичное представление конфигурации выше:
Конфигурация сначала проверяет стиль кода и, если он верный, запускает тесты.
Джобы должны иметь уникальные имена — если указать два джоба с одинаковым именем, то из них выполнится только последний — он перезапишет все предыдущие джобы с таким именем!
Продвинутое использование
Скопировать ссылку на секцию «Продвинутое использование» Скопировано
Запуск вручную
Скопировать ссылку на секцию «Запуск вручную» Скопировано
Если мы хотим запускать определённый джоб вручную, то нужно добавить when : manual :
Продолжение при провале
Скопировать ссылку на секцию «Продолжение при провале» Скопировано
По умолчанию при провале любого джоба весь пайплайн отмечается как проваленный, и оставшиеся джобы не выполнятся. Однако бывают ситуации, когда этого поведения хочется избежать. Например, мы добавили джоб с тестами в только что появившейся версии Node.js и просто хотим видеть проблемы, которые потенциально нужно исправить в будущем. Здесь придёт на помощь allow _ failure : true :
Выполнение джобов по условию
Скопировать ссылку на секцию «Выполнение джобов по условию» Скопировано
GitLab даёт доступ к большому количеству переменных окружения с полезной информацией. Например, $ C I _ C O M M I T _ B R A N C H содержит текущую ветку, $ C I _ C O M M I T _ S H O R T _ S H A — короткий хеш коммита, $ C I _ P I P E L I N E _ S O U R C E — источник вызова текущего пайплайна и так далее. С их помощью мы можем запускать определённые джобы при соблюдении заданных условий. Для этого нужно объявить одну или несколько секций rules .
Вот такой джоб будет выполняться только для коммитов в ветку main :
Запуск по расписанию
Скопировать ссылку на секцию «Запуск по расписанию» Скопировано
В отличие от GitHub Actions, в GitLab CI/CD запуск пайплайнов по расписанию настраивается только в веб-интерфейсе. Для этого нужно открыть страницу репозитория и выбрать CI/CD → Schedules. Перед нами откроется список уже существующих правил и кнопка добавления нового. В форме добавления можно указать название правила, выбрать интервал из списка или указать свой в синтаксисе Cron. Последним важным полем является ветка — при срабатывании правила пайплайн запустится, как будто был запушен код в этой ветке. Отличие в том, что переменная $ C I _ P I P E L I N E _ S O U R C E будет содержать значение schedule.
Серия джобов
Скопировать ссылку на секцию «Серия джобов» Скопировано
Ещё одна типичная задача — прогнать тесты в разных версиях Node.js. Можно для каждой версии создать вручную джоб, а можно указать список переменных:
В примере выше мы объявили список NODE _ VERSION из трёх элементов. GitLab создаст три джоба с именами: «Unit Tests [node:14]», «Unit Tests [node:16]» и «Unit Tests [node:17]», а потом в каждом джобе заменит все места использования переменной NODE _ VERSION . Поэтому image в каждом джобе будет разный.
Руководство по CI/CD в GitLab для (почти) абсолютного новичка
Наверное, у каждого разработчика, имеющего хотя бы один пет-проект, в определённый момент возникает зуд на тему красивых бейджиков со статусами, покрытием кода, версиями пакетов в nuget… И меня этот зуд привёл к написанию этой статьи. В процессе подготовки к её написанию я обзавёлся вот такой красотой в одном из своих проектов:
В статье будет рассмотрена базовая настройка непрерывной интеграции и поставки для проекта библиотеки классов на .Net Core в GitLab, с публикацией документации в GitLab Pages и отправкой собранных пакетов в приватный фид в Azure DevOps.
В качестве среды разработки использовалась VS Code c расширением GitLab Workflow (для валидации файла настроек прямо из среды разработки).
Краткое введение
Что такое CI/CD и зачем нужно — можно легко нагуглить. Полноценную документацию по настройке пайплайнов в GitLab найти также несложно. Здесь я кратко и по возможности без огрехов опишу процесс работы системы с высоты птичьего полёта:
- разработчик отпраляет коммит в репозиторий, создаёт merge request через сайт, или ещё каким-либо образом явно или неявно запускает пайплайн,
- из конфигурации выбираются все задачи, условия которых позволяют их запустить в данном контексте,
- задачи организуются в соответствии со своими этапами,
- этапы по очереди выполняются — т.е. параллельно выполняются все задачи этого этапа,
- если этап завершается неудачей (т.е. завершается неудачей хотя бы одна из задач этапа) — пайплайн останавливается (почти всегда),
- если все этапы завершены успешно, пайплайн считается успешно прошедшим.
Таким образом, имеем:
- пайплайн — набор задач, организованных в этапы, в котором можно собрать, протестировать, упаковать код, развернуть готовую сборку в облачный сервис, и пр.,
- этап (stage) — единица организации пайплайна, содержит 1+ задачу,
- задача (job) — единица работы в пайплайне. Состоит из скрипта (обязательно), условий запуска, настроек публикации/кеширования артефактов и много другого.
Соответственно, задача при настройке CI/CD сводится к тому, чтобы создать набор задач, реализующих все необходимые действия для сборки, тестирования и публикации кода и артефактов.
- Почему GitLab?
Потому, что когда появилась необходимость создать приватные репозитории под пет-проекты, на GitHub’e они были платными, а я — жадным. Репозитории стали бесплатными, но пока это не является для меня поводом достаточным переезжать на GitHub.
- Почему не Azure DevOps Pipelines?
Потому что там настройка элементарная — даже не требуются знания командной строки. Интеграция с внешними провайдерами git — в пару кликов, импорт SSH-ключей для отправки коммитов в репозиторий — тоже, пайплайн легко настраивается даже не из шаблона.
Исходная позиция: что имеется и чего хочется
- репозиторий в GitLab.
- автоматическую сборку и тестирование для каждого merge request,
- сборку пакетов для каждого merge request и пуша в мастер при условии наличия в сообщении коммита определённой строки,
- отправку собранных пакетов в приватный фид в Azure DevOps,
- сборку документации и публикацию в GitLab Pages,
- бейджики!11
Описанные требования органично ложатся на следующую модель пайплайна:
- Этап 1 — сборка
- Собираем код, выходные файлы публикуем как артефакты
- Получаем артефакты с этапа сборки, гоняем тесты, собраем данные покрытия кода
- Задача 1 — собираем nuget-пакет и отправляем в Azure DevOps
- Задача 2 — собираем сайт из xmldoc в исходном коде и публикуем в GitLab Pages
Собираем конфигурацию
Готовим аккаунты
Создаём новый проект
- Имя — любое
- Видимость — любая
При нажатии на кнопку Create проект будет создан, и будет совершён переход на его страницу. На этой странице можно отключить ненужные возможности, перейдя в настройки проекты (нижняя ссылка в списке слева -> Overview -> блок Azure DevOps Services)
Переходим в Atrifacts, жмём Create feed
- Вводим имя источника
- Выбираем видимость
- Снимаем галочку Include packages from common public sources, чтобы источник не превратился в
помойкуклон nuget
Жмём Connect to feed, выбираем Visual Studio, из блока Machine Setup копируем Source
Идём в настройки аккаунта, выбираем Personal Access Token
Создаём новый токен доступа
- Имя — произвольное
- Организация — текущая
- Срок действия — максимум 1 год
- Область действия (scope) — Packaging/Read & Write
Копируем созданный токен — после закрытия модального окна значение будет недоступно
Заходим в настройки репозитория в GitLab, выбираем настройки CI/CD
Раскрываем блок Variables, добавляем новую
- Имя — любое без пробелов (будет доступно в командной оболочке)
- Значение — токен доступа из п. 9
- Выбираем Mask variable
На этом предварительная настройка завершена.
Готовим каркас конфигурации
По умолчанию, для настройки CI/CD в GitLab используется файл .gitlab-ci.yml из корня репозитория. Можно настроить произвольный путь до этого файла в настройках репозитория, но в данном случае это не нужно.
Как видно из расширения, файл содержит конфигурацию в формате YAML . В документации подробно описано, какие ключи могут содержаться на верхнем уровне конфигурации, и в каждом из вложенных уровней.
Сначала добавим в файл конфигурации ссылку на docker-образ, в котором будет происходить выполнение задач. Для этого находим страницу образов .Net Core в Docker Hub. В GitHub есть подробное руководство, какой выбрать образ для разных задач. Нам для сборки подойдёт образ с .Net Core 3.1, поэтому смело добавляем первой строкой в конфигурацию
Теперь при запуске пайплайна с хранилища образов Microsoft будет скачан указанный образ, в котором и будут исполняться все задачи из конфигурации.
Следующий этап — добавить stage‘ы. По умолчанию GitLab определяет 5 этапов:
- .pre — выполняется до всех этапов,
- .post — выполняется после всех этапов,
- build — первый после .pre этап,
- test — второй этап,
- deploy — третий этап.
Ничего не мешает объявить их явно, впрочем. Порядок, в котором указаны этапы, влияет на порядок, в котором они выполняются. Для полноты изложения, добавим в конфигурацию:
Для отладки имеет смысл получить информацию об окружении, в котором исполняются задачи. Добавим глобальный набор команд, который будет выполняться перед каждой задачей, с помощью before_script :
Осталось добавить хотя бы одну задачу, чтобы при отправке коммитов пайплайн запустился. Пока что добавим пустую задачу для демонстрации:
Запускаем валидацию, получаем сообщение, что всё хорошо, коммитим, пушим, смотрим на сайте на результаты… И получаем ошибку скрипта — bash: .PSVersion: command not found . WTF?
Всё логично — по умолчанию runner’ы (отвечающие за исполнение скриптов задач, и предоставляемые GitLab’ом) используют bash для исполнения команд. Можно исправить это дело, явно указав в описании задачи, какие теги должны быть у исполняющего пайплайн раннера:
Отлично! Теперь пайплайн выполняется.
Внимательный читатель, повторив указанные шаги, заметит, что задача выполнилась в этапе test , хотя мы не указывали этап. Как можно догадаться, test является этапом по умолчанию.
Продолжим создание скелета конфигурации, добавив все задачи, описанные выше:
Получили не особенно функциональный, но тем не менее корректный пайплайн.
Настройка триггеров
Из-за того, что ни для одной из задач не указаны фильтры срабатывания, пайплайн будет полностью исполняться при каждой отправке коммитов в репозиторий. Так как это не является желаемым поведением в общем случае, мы настроим фильтры срабатывания для задач.
Фильтры могут настраиваться в двух форматах: only/except и rules. Вкратце, only/except позволяет настраивать фильтры по триггерам ( merge_request , например — настраивает задачу на выполнение при каждом создании запроса на слияние и при каждой отправке коммитов в ветку, являющуюся исходной в запросе на слияние) и именам веток (в т.ч. с использованием регулярных выражений); rules позволяет настраивать набор условий и, опционально, изменять условие выполнения задачи в зависимости от успеха предшествующих задач ( when в GitLab CI/CD).
Вспомним набор требований — сборка и тестирование только для merge request, упаковка и отправка в Azure DevOps — для merge request и пушей в мастер, генерация документации — для пушей в мастер.
Для начала настроим задачу сборки кода, добавив правило срабатывания только при merge request:
Теперь настроим задачу упаковки на срабатывания на merge request и добавление коммитов в мастер:
Как видно, всё просто и прямолинейно.
Также можно настроить задачу на срабатывание только если создан merge request с определённой целевой или исходной веткой:
В условиях можно использовать перечисленные здесь переменные; правила rules не совместимы с правилами only/except .
Настройка сохранения артефактов
Во время выполнения задачи build job у нас будут созданы артефакты сборки, которые можно переиспользовать в последующих задачах. Для этого нужно в конфигурацию задачи добавить пути, файлы по которым нужно будет сохранить и переиспользовать в следующих задачах, в ключ artifacts :
Пути поддерживают wildcards, что определённо упрощает их задание.
Если задача создаёт артефакты, то каждая последующая задача сможет их получить к ним доступ — они будут располагаться по тем же путям относительно корня репозитория, по которым были собраны из исходной задачи. Так же артефакты доступны для скачивания на сайте.
Теперь, когда у нас готов (и проверен) каркас конфигурации, можно переходить собственно к написанию скриптов для задач.
Пишем скрипты
Возможно, когда-то давно, в далёкой-далёкой галактике, собирать проекты (в том числе и на .net) из командной строки было болью. Сейчас же собрать, протестировать и опубликовать проект можно в 3 команды:
Естественно, есть некоторые нюансы, из-за которых мы несколько усложним команды.
- Мы хотим релизную, а не отладочную сборку, поэтому к каждой команде добавляем -c Release
- При тестировании мы хотим собирать данные о покрытии кода, поэтому потребуется подключить анализатор покрытия в тестовые библиотеки:
- Во все тестовые библиотеки следует добавить пакет coverlet.msbuild : dotnet add package coverlet.msbuild из папки проекта
- В команду запуска тестов добавим /p:CollectCoverage=true
- В конфигурацию задачи тестирования добавим ключ для получения результатов покрытия (см. ниже)
Собираем данные покрытия кода
Coverlet после запуска тестов выводит в консоль статистику по запуску:
GitLab позволяет указать регулярное выражение для получения статистики, которую потом можно получить в виде бейджа. Регулярное выражение указывается в настройках задачи с ключом coverage ; в выражении должна присутствовать capture-группа, значение которой и будет передано в бейдж:
Здесь мы получаем статистику из строки с общим покрытием по линиям.
Публикуем пакеты и документацию
Оба действия у нас назначены на последний этап пайплайна — раз уж сборка и тесты прошли, можно и поделиться с миром наработками.
Для начала рассмотрим публикацию в источник пакетов:
Если в проекте не присутствует файл конфигурации nuget ( nuget.config ), создадим новый: dotnet new nugetconfig
Зачем: в образе может быть запрещён доступ на запись к глобальным (пользовательской и машинной) конфигурациям. Чтобы не ловить ошибки, просто создадим новую локальную конфигурацию и будем работать с ней.
- name — локальное имя источника, не приниципиально
- url — URL источника из этапа «Готовим аккаунты», п. 6
- organization — название организации в Azure DevOps
- gitlab variable — имя переменной с токеном доступа, добавленной в GitLab («Готовим аккаунты», п. 11). Естественно, в формате $variableName
- -StorePasswordInClearText — хак для обхода ошибки отказа в доступе (не я первый на эти грабли наступил)
- На случай ошибок может быть полезным добавить -verbosity detailed
- Отправляем все пакеты из текущей директории, поэтому *.nupkg .
- name — из шага выше.
- key — любая строка. В Azure DevOps в окне Connect to feed всегда в качестве примера приводят строку az .
- -skipduplicate — при попытке отправить уже существующий пакет без этого ключа источник вернёт ошибку 409 Conflict ; с ключом отправка будет пропущена.
Теперь настроим создание документации:
- Для начала, в репозитории, в ветке master, инициализируем проект docfx. Для этого из корня надо выполнить команду docfx init и в интерактивном режиме зададим ключевые параметры для сборки документации. Подробное описание минимальной настройки проекта здесь.
- При настройке важно указать выходную директорию ..\public — GitLab по умолчанию берёт содержимое папки public в корне репозитория как источник для Pages. Т.к. проект будет располагаться во вложенной в репозиторий папке — добавляем в путь выход на уровень вверх.
- Скрипт:
- nuget install docfx.console -version 2.51.0 — установит docfx; версия указана для гарантии правильности путей установки пакета.
- .\docfx.console.2.51.0\tools\docfx.exe .\docfx_project\docfx.json — собираем документацию
Лирическое отступление про docfx
Раньше при настройке проекта я указывал источник кода для документации как файл решения. Основной минус — документация создаётся и для тестовых проектов. В случае, если это не нужно, можно задать такое значение узлу metadata.src :
- metadata.src.src: «../» — выходим на уровень вверх относительно расположения docfx.json , т.к. в паттернах не работает поиск вверх по дереву директорий.
- metadata.src.files: [«**/*.csproj»] — глобальный паттерн, собираем все проекты C# из всех директорий.
- metadata.src.exclude: [«*.tests*/**»] — глобальный паттерн, исключаем всё из папок с .tests в названии
Промежуточный итог
Вот такую простую конфигурацию можно составить буквально за полчаса и пару чашек кофе, которая позволит при каждом запросе слияния и отправке в мастер проверять, что код собирается и тесты проходят, собирать новый пакет, обновлять документацию и радовать глаз красивыми бейджиками в README проекта.
Кстати о бейджиках
Ради них ведь всё и затевалось!
Бейджи со статусами пайплайна и покрытием кода доступны в GitLab в настройках CI/CD в блоке Gtntral pipelines:
Бейдж со ссылкой на документацию я создавал на платформе Shields.io — там всё достаточно прямолинейно, можно создать свой бейдж и получать его с помощью запроса.
Azure DevOps Artifacts также позволяет создавать бейджи для пакетов с указанием актуальной версии. Для этого в источнике на сайте Azure DevOps нужно нажать на Create badge у выбранного пакета и скопировать markdown-разметку:
Добавляем красоты
Выделяем общие фрагменты конфигурации
Во время написания конфигурации и поисков по документации, я наткнулся на интересную возможность YAML — переиспользование фрагментов.
Как видно из настроек задач, все они требуют наличия тега windows у раннера, и срабатывают при отправке в мастер/создании запроса на слияние (кроме документации). Добавим это во фрагмент, который будем переиспользовать:
И теперь в описании задачи можем вставить объявленный ранее фрагмент:
Названия фрагментов должны начинаться с точки, чтобы не быть интерпретированными как задача.
Версионирование пакетов
При создании пакета компилятор проверяет ключи командной строки, и в их отсутствие — файлы проектов; найдя узел Version, он берёт его значение как версию собираемого пакета. Выходит, чтобы собрать пакет с новой версией, нужно либо обновить её в файле проекта, либо передать как аргумент командной строки.
Добавим ещё одну хотелку — пусть младшие два номера в версии будут годом и датой сборки пакета, и добавим пререлизные версии. Добавлять эти данные в файл проекта и проверять перед каждой отправкой можно, конечно — но можно ведь это делать и в пайплайне, собирая версию пакета из контекста и передавая через аргумент командной строки.
Условимся, что если в сообщении коммита есть строка вида release (v./ver./version) <version number> (rev./revision <revision>)? , то мы будем из этой строки брать версию пакета, дополнять её текущей датой и передавать как аргумент команде dotnet pack . В отсутствие строки — просто не будем собирать пакет.
Данную задачу решает следующий скрипт:
Добавляем скрипт в задачу pack and deploy job и наблюдаем сборку пакетов строго при наличии заданной строки в сообщении коммита.
Итого
Потратив примерно полчаса-час времени на написание конфигурации, отладку в локальном powershell и, возможно, пару неудачных запусков, мы получили несложную конфигурацию для автоматизации рутинных задач.
Конечно, GitLab CI/CD гораздо обширнее и многограннее, чем может показаться после прочтения этого руководства — это совершенно не так. Там даже Auto DevOps есть, позволяющий
Теперь в планах — сконфигурировать пайплайн для развёртывания приложений в Azure, с использованием Pulumi и автоматическим определением целевого окружения, что будет освещено в следующей статье.
Почему настройка CI&CD является одним из главных приоритетов для IT компании
Обычно, над созданием программы трудятся: программисты, каждый из которых пишет свою часть кода программы, а затем, вручную, все части соединяются в одну основную ветку готового кода программного продукта; тестировщики, которые проверяют код на наличие ошибок; менеджеры/руководители проектов, которые следят, чтобы все делалось и делалось вовремя. Потом, все это вручную соединяется и получается готовая пользовательская программа или какой-либо сервис, которым мы пользуемся в обычной жизни, например, браузер, которым мы привыкли пользоваться, или мессенджеры на наших мобильных устройствах.
Получается, один большой сборочный механизм, который работает на 1 общую цель — выпуск программы. И весь процесс занимает очень много времени, если делать все вручную. Но современная IT сфера не стоит на месте. Каждая команда разработчиков хочет оптимизировать весь процесс создание программ так, чтобы большинство действий делалось автоматизировано. И для этого, существует система автоматизированной разработки CI & CD.
CI & CD помогает автоматизировать многие процессы при создании программного продукта, ускорить время релиза (выпуска) программы, минимизировать ошибки человеческого фактора, и, освободить команду для выполнения других задач.
В этой статье, мы постараемся наиболее просто объяснить принцип системы CI & CD.
Итак, что же такое CI & CD и как она работает?
CI (Continuous Integration или Непрерывная интеграция) – это автоматическая сборка программного обеспечения и его тестирование на корректность.
CD (непрерывная доставка или Continuous Delivery) – это автоматическая установка изменения кода на серверах компании.
При использовании CI & CD, разработка программного продукта проходит несколько этапов и используется подсистемы, которые подключаются на определенных этапах разработки.
К ним относится:
- система контроля версий Git, в которой пишутся и хранятся все версии кода;
- система jenkins — для автоматизации процессов сборки и тестирования этого кода;
- облачный сервис — AWS.
На этой картинке показан весь цикл CI & CD
Давайте подробней рассмотрим каждый этап цикла
1 этап — CODE.
На этом этапе, разработчик пишет код, проводит начальное тестирование своего кода, чтобы не было ошибок, фиксирует изменения кода в своей рабочей ветке в git (система контроля версий), затем разработчик соединяет свой модифицированный код программы с рабочим кодом программы из основной ветки (основная ветка git — это ветка, из которой в последующем клиенты получают готовую программу), затем,
2 этап — BUILD
система, выбранная в качестве инструмента для CI “видит”, что есть изменения в коде и запускает процесс автоматической сборки и автоматического тестирования программы — Jenkins,
Для разработчиков, есть возможность пройти курсы по изучению Jenkins на русском у нас . После прохождения данного курса, Вы будете знать, как автоматизировать процесс сборки, тестирования и развертывания кода программы — что необходимо для этого этапа.
3 этап — TEST
если автоматические тестирование системой CI прошло успешно, программный продукт отдается для ручного тестирования команде тестировщиков, при этом, ему присваивается версия кандидата для дальнейшего выпуска, например, v1.0.0-1,
4 этап — RELEASE
после исправления недочетов программы, найденных во время ручного тестирования, выпускается версия для клиента, например, v.1.0.0 (при этом, версии кандидатов для выпуска каждый раз увеличиваться. Например, при выпуске новой версии кандидата, после первого исправления, версия кандидата станет v1.0.0-2 ), затем
5 этап — DEPLOY
после выпуска пакета для клиентов, запускается автоматизированный процесс установки пакета на серверах компании – CD, после чего, клиент может увидеть результат разработки через интерфейс программного продукта, с помощью, облачного сервиса — AWS.
Менеджеры и руководители проектов, у нас могут пройти обучение AWS на русском и Jenkins на русском языке. Это поможет повысить Ваши знания и квалификацию и поможет перейти на новый уровень организации Вашей работы.
6 и 7 этапы — OPERATE.MONITORING
Осуществляется поддержка новой версии программы и ее мониторинг. После этого,
8 этап — PLANE
Менеджеры проекта начинают разрабатывать новый функционал для программы, собирают запросы на исправление недочетов, которые нашли пользователи и добавляют это в план, затем
9 этап — CODE.
Петля повторяется, начиная с процесса кодирования — CODE.
В этом и есть главное преимущество CI&CD что, при разработке программного продукта, программистам надо только написать код и код должен пройти ручное тестирование, а остальные процессы (тестирование, сборка, доставка кода) происходят в автоматическом режиме.
Если Вам захотелось освоить этот механизм и в деталях узнать, как он работает — приглашаем пройти наши профессиональные онлайн курсы linux и DevOps, в которых Вы познакомитесь с каждой подсистемой Linux, Git, Jenkins и AWS в отдельности и получите практический опыт работы с ними
Name already in use
gitlabhq / doc / ci / quick_start / index.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Tutorial: Create and run your first GitLab CI/CD pipeline (FREE)
This tutorial shows you how to configure and run your first CI/CD pipeline in GitLab.
Before you start, make sure you have:
- A project in GitLab that you would like to use CI/CD for.
- The Maintainer or Owner role for the project.
If you don’t have a project, you can create a public project for free on https://gitlab.com.
To create and run your first pipeline:
If you’re using GitLab.com, you can skip this step. GitLab.com provides shared runners for you.
Create a .gitlab-ci.yml file at the root of your repository. This file is where you define the CI/CD jobs.
When you commit the file to your repository, the runner runs your jobs. The job results are displayed in a pipeline.
Ensure you have runners available
In GitLab, runners are agents that run your CI/CD jobs.
To view available runners:
- Go to Settings > CI/CD and expand Runners.
As long as you have at least one runner that’s active, with a green circle next to it, you have a runner available to process your jobs.
If you don’t have a runner
If you don’t have a runner:
-
on your local machine. for your project. Choose the shell executor.
When your CI/CD jobs run, in a later step, they will run on your local machine.
Create a .gitlab-ci.yml file
Now create a .gitlab-ci.yml file. It is a YAML file where you specify instructions for GitLab CI/CD.
In this file, you define:
- The structure and order of jobs that the runner should execute.
- The decisions the runner should make when specific conditions are encountered.
To create a .gitlab-ci.yml file:
On the left sidebar, select Repository > Files.
Above the file list, select the branch you want to commit to. If you’re not sure, leave master or main . Then select the plus icon ( ) and New file:
For the Filename, type .gitlab-ci.yml and in the larger window, paste this sample code:
This example shows four jobs: build-job , test-job1 , test-job2 , and deploy-prod . The comments listed in the echo commands are displayed in the UI when you view the jobs. The values for the predefined variables $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH are populated when the jobs run.
Select Commit changes.
The pipeline starts and runs the jobs you defined in the .gitlab-ci.yml file.
View the status of your pipeline and jobs
Now take a look at your pipeline and the jobs within.
Go to CI/CD > Pipelines. A pipeline with three stages should be displayed:
View a visual representation of your pipeline by selecting the pipeline ID:
View details of a job by selecting the job name. For example, deploy-prod :
You have successfully created your first CI/CD pipeline in GitLab. Congratulations!