#devops, #gitlab, #cicd

🦊 GitLab CI/CD: облегчаем работу с кодом для пайплайнов

☝️ GitLab это отличное решение при выборе системы управления репозиториями. Кроме этого, GitLab также позиционирует себя, как инструмент DevOps, имеющий в своём арсенале CI/CD, Container Registry и много других полезных инструментов. Остановимся на GitLab CI/CD. А именно на полезных штуках, которые могут облегчить вашу жизнь.

🏕 1) Окружения (environments)
Часто случается так, что у вас может быть несколько окружении. Для каждого, соответственно, используется своя ветка (develop, stage, main, etc).

🤓 С помощью GitLab окружении можно указать переменные с одинаковыми ключами, но при этом с разными значениями. Окружение для переменной назначается при её созданий, затем в Job-е необходимо указать, какое окружение вы будете использовать:

stages:
  - build

Build For Development:
  stage: setup
  environment: development   # !
  image: ubuntu:22.04
  only:
    - develop
  script:
    - echo "Building project for development...."
    - echo $KUBE_TOKEN   # !

Build For Production:
  stage: setup
  environment: production  # !
  image: ubuntu:22.04
  only:
    - main
  script:
    - echo "Building project for production...."
    - echo $KUBE_TOKEN  # !

🙋‍♂️ Для Build Develop используется KUBE_TOKEN для подключения к девовскому кластеру, для Build Prod - продовскому. Но не всё так идеально...


👥 2) Переменные для группы (Group Variables)

Одна и та же переменная нужна для нескольких репозиториев. Что делать? Определить переменную на уровне группы!
Тут также есть окружения, но если у вас Free версия GitLab, то доступа к ним на уровне групп у вас не будет 🙁.

🤠 Но никто не мешает вам использовать префиксы! PROD_, STAGE_, DEVELOP_. При этом вы можете совмещать переменные на уровне репозиториев с переменными на уровне групп!


3) include и скрытые джобы

💭 Вы любитель разносить повторяющийся код по классам и обожаете DRY, но при этом вам приходится регулярно смотреть на ужасы, которые творятся в .gitlab-ci.yml файлах?

😵‍💫 Всё замечательно, пока у вас два-три репозитория. Но когда у вас их больше, при этом содержимое .gitlab-ci.yml повторяется, то приходят проблемы: в случае необходимости, нужно редактировать все файлы, чтение таких ямлов становится невыносимой задачей, код растягивается на тысячи строк. И тут мы можем воспользоваться include!

🔨 Он позволяет импортировать джобы для CI/CD в ваш текущий файл. Таким образом, вы можете переиспользовать одни и те же куски кода!

Сразу к примеру! В репозиторий 'my-templates' есть файл base-build.yml со следующим содержимым:

.build:
  image: ubuntu:22.04
  
  variables:
    KUBE_URL: ""
    KUBE_TOKEN: ""
  script:
    - echo "Set up connection to cluster $KUBE_URL with token $KUBE_TOKEN" 

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

Теперь мы можем использовать эту скрытую джобу в других файлах или даже репозиториях!

🧑🏻‍💻 К примеру, есть репозиторий my-app-repo-1. "Заинклюдим" джобы из ранее созданного файла, при этом укажем путь до репозитория (группу/репо):

include:
  - project: '<group_name>/my-templates'
    ref: main
    file: '/base-build.yml'

🙋 Теперь создадим таски для текущего проекта. Переопределим переменные и при помощи extends укажем в качестве шаблона .build джобу:

Build For Development:
  extends: .build
  stage: build
  only:
    - develop
  variables:
    KUBE_URL: DEVELOP_KUBE_URL
    KUBE_TOKEN: DEVELOP_KUBE_TOKEN
    
Build For Production:
  extends: .build
  stage: build
  only:
    - main
  variables:
    KUBE_URL: PROD_KUBE_URL
    KUBE_TOKEN: PROD_KUBE_TOKEN

Обратите внимание на переменные: мы можем их переопределять. Похоже на аргументы функций, не так ли?)

📌 Вы можете переопределить любое поле. Если вам нужно добавить какой-то дополнительный скрипт, то вы можете воспользоваться полями before_script и after_script, что также очень удобно!