Gitlab Runner для организации Dev-Test-Prod

Gitlab Runner для организации Dev-Test-Prod

Схема Develop-Test-Production (разработка-тестирование-эксплуатация) предполагает, что разработка и тестирование новых процессов ведутся не в рабочем окружении(где работают обычные пользователи), а в отдельных окружениях. В рабочее окружение переносятся только проверенные, протестированные решения.
Develop-Test-Production увеличивает стабильность системы и удобство разработки.
Для установки и настройки Gitlab Runner посмотрите статью “Gitlab Runner для распаковки e365”. Мы будем продолжать эту статью, чтоб решить текущую задачу.
Для организации схемы Dev-Test-Prod доработаем проект Main-pipeline. Добавим еще два этапа - testing и production.
Добавим изменения в файл .gitlab-ci.yml

Код:

stages:
    - unpack
    - testing
    - production
include: 
    - "/templates/.unpack_runner.yml"
    - "/templates/.test_runner.yml"
    - "/templates/.prod_runner.yml"
image:
    alpine

Содержимое .test_runner.yml

Код:

testing:
    image:
        deconstruct365/e365_importer:latest
    stage:
        testing
    allow_failure: true
    rules:
        - if: $CI_COMMIT_MESSAGE =~ /Merge.+branch\s(.*)\sinto(.*)/ &&
              $CI_COMMIT_BRANCH =~ /.*test.*/
    script:
        - apk update && apk add git
        - env > ./gitlab_vars.env
        - pip3 install python-dotenv
        - git config --global user.name $CI_ROBOT_NAME
        - git config --global user.email $CI_ROBOT_EMAIL
        - git remote set-url origin $GITLAB_PROJECT_PATH
        - cp /importer/elma365pm . && cp /importer/importer.py .
        - python3 ./importer.py

Содержимое .prod_runner.yml

Код:

production:
    image:
        deconstruct365/e365_importer:latest
    stage:
        production
    allow_failure: true
    rules:
        - if: $CI_COMMIT_MESSAGE =~ /Merge.+branch\s(.*)\sinto(.*)/ &&
              $CI_COMMIT_BRANCH =~ /.*prod.*/
    script:
        - apk update && apk add git
        - env > ./gitlab_vars.env
        - pip3 install python-dotenv
        - git config --global user.name $CI_ROBOT_NAME
        - git config --global user.email $CI_ROBOT_EMAIL
        - git remote set-url origin $GITLAB_PROJECT_PATH
        - cp /importer/elma365pm . && cp /importer/importer.py .
        - python3 ./importer.py

Необходимо определить переменные окружения, которые будут использоваться в процессе запуска работ раннера. Для этого на странице с проектом, в левом меню выбираем Settings > CI/CD
TEST_URL - IP или hostname вашего тестового стенда.
TEST_TOKEN - токен тестового стенда
PROD_URL - IP или hostname вашего продакшен сервера.
PROD_TOKEN - токен продакшен сервера.

Проверка работы
Для проверки продолжим работать с проектом, который создали в предыдущей статье.
Создадим в проекте Test еще две ветки - test и prod
Для того, чтоб отправить изменения на тестовое окружение нужно создать merge-request(MR) в тестовую ветку test. Для создания MR есть два варианта:

1. После коммита выбрать Create merge request из уведомления сверху вашего проекта:
   

1. В левом меню проекта выбрать Merge requests, и в новом окне нажать New merge request:
   

В этом случае будет предложено выбрать ветки для слияния:

Если вы пошли по первому пути, то чтобы попасть в меню выбора веток, нажмите на Change branches в верхней части окна:


После выбора веток в нижней части нажимаем на Create merge request:


Теперь, после подтверждения слияния веток ревьюером, запустится следующий этап раннера, что можно будет увидеть прямо на странице с merge-request’ом:





На странице с пайплайном можно увидеть, что выполняется джоб с другим названием, например production:



В случае, если слияние происходит с test веткой:



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