Запуск и визуализация пайплайнов при настройке GitLab CI/CD для нескольких проектов.


Непрерывная интеграция (CI) — это практика автоматизации сборки и тестирования кода до его слияния с основной веткой. Она позволяет разработчикам вливать код довольно часто и рано, снижая при этом риск внесения новых ошибок в главный репозиторий исходного кода.


Хотя CI проверяет, что новый код не сломается при интеграции с другим кодом в том же репо, прохождение всех тестов на этом репо — это только первый шаг. После запуска CI в коде важно развернуть и запустить тесты в реальной среде. Переход от CI к непрерывной доставке и деплою (CD) является следующим шагом к “взрослому” DevOps. Развертывание и последующее повторное тестирование позволяют тестировать код одного проекта вместе с другими компонентами и сервисами, которые, возможно, управляются другими проектами.


Зачем мне нужно убедиться, что мой код работает с другими компонентами?


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


Пайплайн кросс-проекта


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


GitLab CI/CD конфигурационный файл


В GitLab CI/CD пайплайны, а также задания (jobs) и этапы их компонентов определяются в файле .gitlab-ci.ymlдля каждого проекта. Файл является частью репозитория проекта. Он полностью версионный, и разработчики могут редактировать его с помощью любой IDE по своему выбору. Им не нужно просить системного администратора или команду DevOps вносить изменения в конфигурацию пайплайна, поскольку могут делать это сами. Файл .gitlab-ci.yml определяет структуру и порядок пайплайнов, и решает, что надо выполнять с помощью GitLab Runner (агент, который запускает задания), и какие решения следует принимать при возникновении определенных условий, например, когда процесс завершается успешно или выходит из строя.


Добавление job для запуска кросс-проектного пайплайна


Начиная с GitLab 11.8, GitLab предоставляет новый синтаксис конфигурации CI/CD для запуска кросс-проектных пайплайнов, его можно найти в правилах конфигурации пайплайна. Следующий код иллюстрирует настройку bridge job для запуска нисходящего пайплайна:


// job1 это job в восходящем проекте
deploy:
    stage: Deploy
    script: this is my script

// job2 это bridge job в восходящем проекте, который запускает кросс-проектный пайплайн 
Android:
    stage: Trigger-cross-projects
      trigger: mobile/android

В приведенном выше примере, как только deploy job (задача развертывания) на этапе деплоя выполнится успешно, запустится задание для Android bridge. Его первоначальный статус будет в ожидании. GitLab создаст нисходящий пайплайн в проекте mobile/android, и, как только он будет создан, Android job выполнится успешно. В этом случае mobile/android является полным путем к этому проекту.


Пользователь, создавший вышестоящий пайплайн, должен иметь права доступа к нижестоящему проекту (в данном случае mobile / android). Если нижестоящий проект не может быть найден или у пользователя нет прав доступа для создания там пайплайна, Android job получит статус failed.


Обзор графиков от восходящего до нижестоящего пайплайна


GitLab CI/CD позволяет визуализировать конфигурацию пайплайна. На приведенном ниже рисунке этапы сборки, тестирования и деплоя являются частями восходящего (upstream) проекта. Как только deploy job выполнено успешно, четыре кросс-проекта будут запущены параллельно, и вы сможете перейти к ним, щелкнув на одну из нисходящих (downstream) job.


image


На приведенном ниже рисунке виден нисходящий пайплайн «Сервис — Финансы». Теперь можно прокрутить влево к восходящему пайплайну, прокрутить вправо назад к нисходящему или выбрать другой нисходящий пайплайн.


image


Определение ветки нижестоящего пайплайна


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


trigger:
     project: mobile/android
     branch: stable-11-2

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


Передача переменных в нисходящий пайплайн


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


Android:
     variable:
           ENVIRONMENT: ‘This is the variable value for the downstream pipeline’
     stage: Trigger-cross-projects
     trigger: mobile/android

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


Итого о кросс-проектном пайплайне


Файл .gitlab-ci.ymlопределяет порядок этапов CI/CD, какие задания выполнять и при каких условиях запускать или пропускать выполнение задания. Добавление 'bridge job' с ключевым словом trigger в этот файл можно использовать для запуска кросс-проектных пайплайнов. Мы можем передавать параметры заданиям в нисходящих пайплайнах и даже определять ветку, которую будет использовать нисходящий пайплайн.


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


image


Также читайте другие статьи в нашем блоге:


Комментарии (3)


  1. Gwynn
    12.09.2019 10:31
    +1

    К сожалению, этот функционал доступен только для лицензий уровня premium и
    silver ($19 per user/per month (billed annually)).
    Думаю стоило это уточнить в статье.


    1. gecube
      12.09.2019 13:00

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


  1. nos
    13.09.2019 01:58

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

    gitlab.com/finestructure/pipeline-trigger

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