Новый gitlab 12.0 с визуальными ревью и списком зависимостей / хабр

Краткое введение

Что такое CI/CD и зачем нужно — можно легко нагуглить. Полноценную документацию по настройке пайплайнов в GitLab найти также несложно. Здесь я кратко и по возможности без огрехов опишу процесс работы системы с высоты птичьего полёта:

разработчик отпраляет коммит в репозиторий, создаёт merge request через сайт, или ещё каким-либо образом явно или неявно запускает пайплайн,
из конфигурации выбираются все задачи, условия которых позволяют их запустить в данном контексте,
задачи организуются в соответствии со своими этапами,
этапы по очереди выполняются — т.е. параллельно выполняются все задачи этого этапа,
если этап завершается неудачей (т.е. завершается неудачей хотя бы одна из задач этапа) — пайплайн останавливается (почти всегда),
если все этапы завершены успешно, пайплайн считается успешно прошедшим.

Таким образом, имеем:

пайплайн — набор задач, организованных в этапы, в котором можно собрать, протестировать, упаковать код, развернуть готовую сборку в облачный сервис, и пр.,
этап (stage) — единица организации пайплайна, содержит 1+ задачу,
задача (job) — единица работы в пайплайне. Состоит из скрипта (обязательно), условий запуска, настроек публикации/кеширования артефактов и много другого.

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

Краткое введение

разработчик отпраляет коммит в репозиторий, создаёт merge request через сайт, или ещё каким-либо образом явно или неявно запускает пайплайн,
из конфигурации выбираются все задачи, условия которых позволяют их запустить в данном контексте,
задачи организуются в соответствии со своими этапами,
этапы по очереди выполняются — т.е. параллельно выполняются все задачи этого этапа,
если этап завершается неудачей (т.е. завершается неудачей хотя бы одна из задач этапа) — пайплайн останавливается (почти всегда),
если все этапы завершены успешно, пайплайн считается успешно прошедшим.

Таким образом, имеем:

пайплайн — набор задач, организованных в этапы, в котором можно собрать, протестировать, упаковать код, развернуть готовую сборку в облачный сервис, и пр.,
этап (stage) — единица организации пайплайна, содержит 1+ задачу,
задача (job) — единица работы в пайплайне. Состоит из скрипта (обязательно), условий запуска, настроек публикации/кеширования артефактов и много другого.

Шаг 5 — Начальная настройка конфигурации через веб-интерфейс

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

Первый вход в систему

Откройте доменное имя вашего сервера GitLab в вашем браузере:

При первом входе откроется диалоговое окно установки пароля для учетной записи администратора:

В начальном диалоговом окне ввода пароля укажите и подтвердите защищенный пароль для административной учетной записи. Нажмите кнопку Change your password (Изменить пароль), когда будете готовы.

После этого вы перейдете на стандартную страницу входа в систему GitLab:

Здесь вы можете войти в систему с помощью только что заданного пароля. Учетные данные:

Имя пользователя: root
Пароль:

Введите эти значения в поля для существующих пользователей и нажмите кнопку Sign in (Вход). После входа в приложение откроется начальная страница, куда вы сможете добавлять проекты:

Теперь вы можете внести простые изменения и настроить GitLab желаемым образом.

Изменение настроек профиля

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

Чтобы внести необходимые изменения, нажмите значок пользователя в правом верхнем углу интерфейса. Выберите пункт Settings (Настройки) в выпадающем меню:

Откроется раздел настроек Profile (Профиль):

Измените имя и адрес электронной почты с Administrator и [email protected] на более подходящие значения. Введенное имя будет отображаться другим пользователям, а адрес электронной почты будет использоваться для определения аватара по умолчанию, отправки уведомлений, в действиях Git через интерфейс и т. д.

После завершения настройки нажмите кнопку Update Profile settings (Обновить настройки профиля):

На указанный адрес электронной почты будет отправлено письмо с подтверждением. Следуйте указаниям в письме, чтобы подтвердить учетную запись и начать ее использовать с GitLab.

Изменение имени учетной записи

Нажмите Account (Учетная запись) в левой панели меню:

Здесь вы можете найти свой частный токен API или настроить двухфакторную аутентификацию. Однако пока что нас интересует раздел Change username (Изменить имя пользователя).

По умолчанию первой административной учетной записи присваивается имя root. Поскольку это имя широко известно, безопаснее заменить его другим именем. Изменится только имя учетной записи, права администратора у вас сохранятся. Замените root предпочитаемым именем пользователя:

Нажмите кнопку Update username (Обновить имя пользователя), чтобы внести изменения:

При следующем входе в GitLab обязательно используйте новое имя пользователя.

Добавление ключа SSH для своей учетной записи

В большинстве случаев вы захотите использовать с Git ключи SSH для взаимодействия с проектами GitLab. Для этого вам нужно добавить свой открытый ключ SSH в учетную запись GitLab.

Если вы уже создали на локальном компьютере пару ключей SSH, вы можете просмотреть открытый ключ с помощью следующей команды:

Вы увидите большой блок текста, выглядящий примерно так:

Скопируйте этот текст и вернитесь на страницу настройки профиля в веб-интерфейсе GitLab.

Если вместо этого вы получите сообщение, выглядящее следующим образом, это будет означать, что на вашем компьютере не настроена пара ключей SSH:

В этом случае вы можете создать пару ключей SSH, для чего нужно ввести следующую команду:

Примите параметры по умолчанию, а при желании укажите пароль для локальной защиты ключа:

После этого вы сможете просматривать свой открытый ключ с помощью следующей команды:

Скопируйте отображаемый блок текста и вернитесь в настройки профиля в веб-интерфейсе GitLab.

Нажмите пункт SSH Keys (Ключи SSH) в левом меню:

Вставьте в указанное место открытый ключ, скопированный с локального компьютера. Присвойте ему описательное название и нажмите кнопку Add key (Добавить ключ):

Теперь вы должны иметь возможность управлять проектами и хранилищами GitLab с локального компьютера без ввода учетных данных GitLab.

Упростите ваш рабочий процесс

Работа с GitLab Container Registry проста и безопасна. Вот несколько примеров того, как использование GitLab Container Registry может упростить процесс разработки и развертывания ПО:

Проводите сборку образов Docker с помощью GitLab CI с последующим их хранением в GitLab Container Registry.
Привязывайте образы к веткам, тегам исходного кода или используйте любой другой способ, подходящий для вашего процесса разработки. Созданные образы можно быстро и легко сохранить на GitLab.
Используйте собственные образы сборок, хранящиеся в вашем реестре, для тестирования приложений.
Пусть остальные участники команды также участвуют в разработке образов. Это не потребует от них дополнительных усилий, так как используется тот же рабочий процесс, к которому они привыкли. GitLab CI позволяет проводить автоматическую сборку образов, унаследованных от ваших, что в свою очередь позволяет с легкостью добавлять фиксы и новые фичи в базовый образ, используемый вашей командой.
Настройте CaaS на использование образов напрямую из GitLab Container Registry, получив таким образом процесс непрерывного развертывания кода. Это позволит проводить автоматическое развертывание приложений в облако (Docker Cloud, Docker Swarm, Kubernetes и т. п.) каждый раз, когда вы собираете или тестируете образ.

Добавляем новые файлы на ПК и переносим их в удалённый репозиторий

Папка с файлами нашего репозитория хранится на рабочем столе. Чтобы продолжить работу, откроем проект в редакторе кода: можно выбрать любую программу, и GitHub Desktop предлагает воспользоваться Atom.

Выбор редактора кода — дело вкуса. Мы будем работать с репозиторием в Visual Studio Code — это бесплатный редактор от компании Microsoft.

Папка с нашим тестовым репозиторием в Visual Studio Code

Создадим HTML-файл, добавим базовую структуру и посмотрим на боковое меню — HTML-файл подсвечен зелёным цветом. Это означает, что в проекте появились изменения и они ещё не добавлены в репозиторий на GitHub.

Редактор кода подсвечивает зелёным цветом новые файлы

Переходим в GitHub Desktop — созданный HTML-файл появится во вкладке Changes. Для его сохранения пишем коммит и переходим во вкладку History для просмотра изменений. Если изменения сохранились, нажимаем на Push origin и отправляем изменения в удалённый репозиторий.

Мерж чужого кода в ваш код

Когда начинаете работу над задачей, всегда создавайте feature-ветку от последнего коммита в . Только если ваша работа требует изменений из определённой ветки, начните с этой ветки. Если впоследствии вам понадобилось замержить другую ветку, обязательно объясните необходимость этого в сообщении мерж-коммита. Пока вы не запушили вашу ветку в общий репозиторий, можно ребейзить её на или другую ветку. Не нужно мержить стабильные ветки в свои feature-ветки, если в этом нет строгой необходимости. Линус Торвальдс вообще запрещает мержить стабильные ветки в feature-ветки, за исключением крупных релизов.

Главные фичи GitLab 12.0

Визуальные ревью кода

STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD

GitLab позволяет пользователям автоматически создавать приложения для ревью для каждого мердж-реквеста. Любой может посмотреть изменение проекта или пользовательского интерфейса.

В GitLab 12.0 обсуждать эти изменения еще удобнее благодаря инструментам визуального ревью, доступным прямо в приложении для ревью. Один небольшой фрагмент кода — и дизайнеры, менеджеры продуктов и все, кого это касается, могут быстро оставлять фидбэк по мердж-реквесту, не выходя из приложения.

Список зависимостей проекта

ULTIMATE, GOLD

Теперь из левого меню можно открыть список зависимостей проекта (иногда их называют спецификации или BOM (Bill of Materials)).

В BOM видно, какие компоненты входят в проект, а это важно для специалистов по безопасности или соответствию требованиям. Отчет можно не только посмотреть, но и экспортировать как JSON

Ограничение доступа по IP-адресу

ULTIMATE, GOLD

Если в компании строгий контроль, она может запретить доступ к своим ресурсам с внешних IP-адресов. Особенно эта фича полезна для компаний, которые используют VPN, потому что теперь можно запретить трафику за пределами указанной подсети доступ к ресурсам в пользовательском интерфейсе GitLab.

Строгий контроль над самым ценным кодом компании теперь можно настраивать на уровне группы в самоуправляемых экземплярах или на GitLab.com, и это очень просто.

Синхронизация файлов с веб-терминалом

ULTIMATE, GOLD

В GitLab 12.0 изменения, внесенные в Web IDE, теперь можно синхронизировать с веб-терминалом. Изменения в Web IDE можно тестировать в веб-терминале до отправки в проект.

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

Примечание: GitLab.com поддерживает интерактивные веб-терминалы только через приватные раннеры.

Интеграция Git для JupyterHub

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Деплой JupyterHub через интеграцию Gitlab с Kubernetes позволяет без лишних усилий приступить к работе с записными книжками Jupyter, с помощью которых можно создавать и отправлять документы с живым кодом, диаграммами и даже инструкциями.

Начиная с GitLab 12.0 расширение Git для JupyterLab автоматически настраивается при установке JupyterHub на кластер Kubernetes. Эта интеграция позволяет полностью контролировать записные книжки и выполнять команды Git в Jupyter. Команды Git можно выполнять на вкладке Git на левой панели или в командной строке Jupyter.

Начало

Развертывание: в данном примере результатом развертывания должно быть появление набора HTML-файлов в вашем бакетe (bucket) S3, который уже настроен для хостинга статических вебсайтов).

Добиться этого можно множеством различных способов. Мы будем использовать библиотеку от Amazon.

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

Пуш кода в репозиторий и развертывание — это два разных процесса

Важно: эта команда , что вы передадите ей переменные окружения и. Также от вас может потребоваться указать

Попробуем автоматизировать этот процесс с использованием GitLab CI.

Переносим удалённый репозиторий на ПК

Перейдите на сайт desktop.github.com и скачайте GitHub Desktop — это приложение, которое позволит синхронизировать удалённый репозиторий на GitHub и файлы на вашем компьютере без командной строки терминала:

Скачиваем приложение под свою операционную систему.
Открываем приложение и проходим авторизацию — нужно указать электронную почту и данные вашего GitHub-аккаунта.
Приложение синхронизируется с удалённым репозиторием и предложит выполнить одно из следующих действий: создать новый репозиторий, добавить локальную папку с компьютера в GitHub Desktop или клонировать существующий репозиторий в папку компьютера.

Мы создали тестовый удалённый репозиторий, поэтому выберем третий вариант — клонировать существующий репозиторий в папку компьютера.

После установки GitHub Desktop запросит синхронизацию с GitHub-аккаунтом. Если аккаунта нет, приложение предложит его создать
Рабочее пространство в GitHub Desktop — мы можем клонировать репозиторий, создать новый или перенести нужные файлы с компьютера
Выбираем репозиторий, сохраняем его на рабочем столе и жмём кнопку Clone

После клонирования репозитория в рабочем пространстве появятся три вкладки: Current Repository, Current Branch и Fetch origin.

Current Repository — раздел позволяет переключаться между несколькими репозиториями, отслеживать невнесённые изменения (вкладка Changes) и смотреть историю коммитов (вкладка History).
Current Branch — раздел позволяет переключаться между несколькими ветками проекта.
Fetch origin — раздел обновляет внесённые изменения и синхронизирует файлы локального и удалённого репозитория.

Обратите внимание на раздел Current Repository и вкладку Changes. В левом нижнем углу есть окно для добавления коммитов и комментариев — это означает, что вы можете записывать каждый шаг, не посещая сайт GitHub

Рабочее пространство для работы с клонированным репозиторием
История изменений нашего репозитория

Создание CI/CD для проекта

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

Переходим в GitLab на страницу проекта и кликаем по Set up CI/CD:

* данной кнопки может и не быть.

… или можно просто в корне проекта создать файл:

vi .gitlab-ci.yml

Задаем содержимое нашего сценария:

stages:
— test
test:
stage: test
script: echo $CI_PROJECT_DIR/

* Из расширения файла понятно, что формат текста должен быть yml, а значит, отступы имеют значения. В данном примере мы создаем pipeline с одним единственным этапом, которое называется test. По данному заданию будет запускаться скрипт вывода значения переменной $CI_PROJECT_DIR — путь, по которому клонируется проект и где выполняется задание (если установлен $builds_dir, эта переменная устанавливается относительно данного значения. Список возможных переменных можно посмотреть на официальном сайте в разделе документации GitLab CI/CD environment variables.

После сохранения файла ждем несколько секунд и перезапускаем страницу — мы должны увидеть успешный результат выполнения сценария CI/CD:

Кликнем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:

Мы должны увидеть ход процесса выполнения задания и результат его работы:

На этой же странице справа можно вручную запустить задание еще раз:

CI/CD создан. Теперь необходимо подготовить систему к синхронизации данных.

Как генерировать?

Для генерации воспользуемся функциональностью , с его помощью будет формироваться файл () с логом изменений, основанный на заголовках коммитов. Добавляются только те коммиты, которые включают в себя определенную метку (Git trailers). GitLab использует эти метки для того, чтобы сгруппировать изменения по категориям.

Для генерации нужно выполнить POST запрос:

gitlab-host — это адрес на котором расположен сервер GitLab с вашим репозиторием.
id — это project id вашего репозитория, который можно посмотреть в настройках на вкладке «General».

Также нужно передать токен доступа для api, который можно получить в настройках на вкладке «Access Tokens». (или в настройках вашего профиля, на вкладке «Access Tokens».) И как минимум, обязательный атрибут «version» — версия, для которой генерируется лог изменений.

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

Для того, чтобы GitLab мог автоматически находить последний тег, нужно чтобы и версия, и имя тега были оформлены в соответствии с семантикой версионирования.

Если мы хотим именовать как-то по-другому или использовать другой диапазон коммитов, то на помощь приходят атрибуты:

from — название ветки, последний коммит которой станет началом диапазона. Сам коммит не будет включен в список.
to — название ветки, последний коммит которой станет концом диапазона. Сам коммит будет включен в список.
branch — название ветки, в которой будет обновлен/создан файл .

Например, выполним несколько запросов с исходными данными:

Project id — 111
Gitlab-host — https://gitlab.com/
API access token — token
Имя последнего тега — 0.9.0
Имя ветки по умолчанию — main

Результатом выполнения будет новый раздел в ветке main, с подзаголовком 1.0.0 и диапазоном включенных коммитов 0.9.0..main.

Результатом выполнения будет новый раздел в ветке develop, с подзаголовком 1.0.0 и диапазоном включенных коммитов release_0.9.0..develop.

Работа в команде

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

Проблема в том, что при текущей настройке CI не поддерживает работу с ветками — при пуше в любую ветку на GitLab происходит развертывание текущего состояния на S3.

К счастью, это легко исправить — просто добавьте в задачу .

Мы хотим избежать развертывания каждой ветки на сайте

С другой стороны, было бы неплохо иметь возможность предпросмотра изменений, внесенных из веток для выделенной функциональности (feature-веток).

Создание отдельного пространства для тестирования

Патрик (разработчик, которого вы недавно наняли) напоминает вам, что существует такая функциональность, какGitLab Pages. Как раз то, что нужно — место для предпросмотра новых изменений.

Для размещения вебсайта на GitLab Pages ваша конфигурация CI должна удовлетворять трем простым требованиям:

Задача должна иметь имя
Должен присутствовать раздел , а в нем содержаться папка
В этой самой папке должно находиться все, что вы хотите разместить на сайте

Содержимое папки public будет размещено по адресу

После добавления кода из примера для сайтов на чистом HTML файл настройки CI выглядит следующим образом:

Всего в нем содержатся две задачи: одна () проводит развертывание сайта на S3 для ваших читателей, а другая () на GitLab Pages. Назовем их соответственно «Production environment» и «Staging environment».

Развертывание всех веток, кроме master, будет проводиться на GitLab Pages

GitLab flow: релизные ветки

Ветки релизов понадобятся вам только если вы выпускаете ПО для внешних клиентов. В таком случае каждая минорная версия будет храниться в отдельной ветке (, и т.п.).

Стабильные (stable) ветки должны создаваться от ветки . Их нужно создавать как можно позже, чтобы минимизировать добавление хотфиксов в несколько веток. После того, как релизная ветка создана, в неё можно включать только исправления серьёзных багов. Следуйте правилу «upstream first»: всегда, когда это возможно, сначала делайте мерж исправлений в , и только оттуда — cherry-pick в релизную ветку. Благодаря этому правилу вы не забудете сделать cherry-pick исправлений в и не встретите тот же самый баг в следующем релизе. Правило «upstream first» применяется в том числе в и Red Hat. Каждый раз, когда в релизную ветку добавляется исправление бага, нужно повысить третье число в номере версии (по правилам семантического версионирования). Обозначьте эту версию новым тегом в git. В некоторых проектах используется ветка , которая всегда указывает на тот же коммит, что и последний релиз. Ветка (или в правилах git flow) в таком случае не нужна.

Установка Gitlab Runner

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

Само создание ранера выполняется в одну команду. Можно создать сколько угодно ранеров.

Мало создать раннер, теперь его нужно зарегистрировать в GitLab. Зарегистрировать можно на уровне всего GitLab, тогда сборки будут выполняться для любого проекта; на уровне группы — выполнятся только для группы, и на уровне проекта.

Заходим в контейнер.

Внутри контейнера выполним команду регистрации. Регистрация происходит в интерактивном режиме.

Отвечаем на вопросы:

Тут все просто:

Адрес вашего gitlab.
Токен авторизации. Посмотреть его можно в настройках гурппы/проекта в разделе CI/CD Runners.
Название раннера.
Теги ранера, можно пропустить нажав Enter.
Исполнитель сборки. Вводим docker.
Образ, который будет использоваться по умолчанию, если не установлен другой.

После этого в настройках проекта можно посмотреть доступные раннеры.

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

Проблема кэширования

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

В итоге файл конфигурации выглядит так:

После изменения перезапускаем раннер.

¶ Как создавать репозиторий?

Шаг 1. Зайдите в свой аккаунт на GitLab и нажмите на иконку «Groups» в верхней панели.

Шаг 2. Затем перейдите во вкладку «Your group».

Шаг 3. Выберите команду с названием вашего учебного проекта.

Шаг 4. Вы перешли на страницу своей команды. Теперь нужно создать репозиторий. Для этого нажмите на кнопку «New project».

Если у вас уже есть нужный вам репозиторий, то перейдите к шагу 6.

Шаг 5. Напишите название вашего репозитория и добавьте нужные данные. Готово!

Шаг 6.

Перенос существующего репозитория
Если у вас уже есть репозиторий на MIEM GitLab, то его легко можно перенести:

Для этого зайдите на страницу нужного вам проекта. Далее перейдите в настройки.

Опуститесь до раздела «Advanced» и разверните его с помощью кнопки «Expand».

Найдите внутри блок «Transfer project» и с помощью селектора выберите новое расположение.

Перенос существующего репозитория с другой платформы

Если проект был создан на другой платформе (Github, Bitbucket и т.д.), то при создании нового репозитория откройте вверху вкладку «Import project» вместо «Blank project», а затем выберите » Repo by URL».

Подробнее о миграции проектов.

При этом вся информация по коммитам будет перенесена. Однако, чтобы она корректно отображалась и учитывалась в статистике, необходимо, чтобы коммиты были сделаны с почты @miem.hse.ru. Если коммиты были сделаны с другой почты, то необходимо добавить ее адрес в личном кабинете в Git.miem.hse.ru (подробнее в блоке «Коммит»)

Слеш-команды

Как ими пользоваться:

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

Можно использовать слеш-команды даже при создании нового тикета или реквеста:

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

Несколько идей, как можно использовать слеш-команды:

В письме в ответ на оповещение из тикета или мерж-реквеста (текст письма становится комментарием).
В шаблоне тикета или мерж-реквеста.
Через notes API.

Мы сами с нетерпением ждём ваших рассказов о том, какие ещё способы использования вы изобретёте.

Подводя итоги

GitLab Container Registry — последнее на данный момент дополнение к встроенному набору инструментов для цикла разработки ПО GitLab. Это дополнение доступно начиная с версии GitLab 8.8. С использованием этой функциональности проводить тестирование и развертывание образов Docker стало гораздо проще. GitLab Container Registry идет в комплекте с GitLab CE и GitLab EE без какой-либо доплаты и устанавливается поверх той же инфраструктуры, что настроена у вас для GitLab.

Container Registry доступен на GitLab.com, он абсолютно бесплатен, и вы можете начать пользоваться им прямо сейчас!

Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru. Над переводом работал sgnl_05.

Подводя итоги

В этой статье приведены далеко не все возможности GitLab CI, однако пока что остановимся на этом. Надеемся вам понравился этот небольшой рассказ. Приведенные в нем примеры были намеренно тривиальными — это было сделано для того, чтобы наглядно показать принципы работы CI не отвлекаясь на незнакомые технологии. Давайте подытожим изученное:

Для того, чтобы передать выполнение определенной работы в GitLab CI, нужно определить одну или более в .
Задачам должны быть присвоены названия, советуем делать их осмысленными, чтобы потом самим не запутаться.
В каждой задаче содержится набор правил и инструкций для GitLab CI, определяющийся .
Задачи могут выполняться последовательно, параллельно, либо вы можете задать свой собственный порядок выполнения, создав конвейер.
Существует возможность передавать файлы между заданиями и сохранять их как артефакты сборки для последующего скачивания через интерфейс.

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

Описания ключевых слов и ссылки на документацию

Ключевое слово/термин	Описание
	Конфигурационный файл, в котором содержатся все определения сборки проекта
	Определяет исполняемый shell-скрипт
	Определяет команды, которые выполняются перед всеми заданиями
	Определяет используемый Docker-образ
	Определяет стадию конвейера ( по умолчанию)
	Определяет список артефактов сборки
	Используется для удаления загруженных артефактов по истечению определенного промежутка времени
	Конвейер — набор сборок, которые выполняются стадиями

Также обратите внимание на другие примеры работы с GitLab CI:

Migrating from Jenkins to GitLab CI
Decreasing build time from 8 minutes 33 seconds to just 10 seconds

(Автор перевода — sgnl_05)

Подводя итоги

Развертывание происходит при помощи регулярного выполнения выполнения команды (или набора команд), так что оно может запускаться в рамках GiLab CI
В большинстве случаев этим командам нужно передавать различные секретные ключи. Храните эти ключи в разделе Settings > Variables
С помощью GitLab CI вы можете выбирать ветки для развертывания
GitLab сохраняет историю развертываний, что позволяет делать откат на любую предыдущую версию
Существует возможность включения развертывания вручную (а не автоматически) для наиболее важных частей инфраструктуры проекта