Skip to content

Almat.su (Almat.pro)

Блог Алмата Жандаулетова

  • Главная
  • Контакты
Gitlab Ci/CD Review apps

Настройка Gitlab Review Apps и деплой на Heroku

Автор Zhandauletov Almat · 4 декабря, 2019 ·
Просмотры: 1 752

В  прошлой статье Gitlab CI/CD на примере PHP проекта я описал основы настройки Gitlab CI/CD. Теперь пришла очередь написать про настройку Gitlab Review Apps. В официальной документации есть примеры по настройке для Nginx и Openshift. Неплохо было бы дополнить его для работы с Heroku, учитывая что деплой в предыдущей статье производится как раз туда.

Что такое Review Apps

Review Apps — запуск конвейера развертывания для каждой ветки, с целью создать готовое тестовое приложение в конце. Вот схема Review Apps

 

Схема Review Apps
Схема Review Apps

 

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

Зачем нужны Review Apps?

Рассмотрим вот такой рабочий процесс.

Разработчик создает ветку для новой фичи. Вносит в нее какие нибудь изменения, пушит на сервер и создает пулл реквест. Добавляет ревьюера и просит посмотреть код. Если ревьюер хочет проверить изменения, что он должен сделать? Если это тим лид или разработчик то, скорее всего, у него есть локальное окружения. Он может стянуть изменения из ПР к себе, перезапустить локальное окружения, и воочию увидеть внесенные изменения. Это может сработать, если команда небольшая и состоит только из разработчиков.

А если изменения нужно отдать на тестирование? Просить проверить на ноутбуке разработчика?

Для этого и нужны Review Apps. На шаге «Фиксация изменения» создается полностью независимая, прошедшая все шаги конвейера развертывания, версия приложения. Например, есть сайт по продаже печенек по адресу my-awesome-cookies.almat.su Если разработчик делает задачу «добавить форму обратной связи», то его review apps будет доступен всем по адресу feedback-form.almat.su. Главная идея, что эту ссылку можно отправить тем, кому это необходимо: тестировщику, дизайнеру, менеджеру проекта, тим лиду. Людям не нужно разворачивать локальное окружение, это уже сделал сервер CI/CD. И у Gitlab CI/CD есть такой замечательный механизм 🙂

Требования

Если ознакомились со статьей Gitlab CI/CD на примере PHP проекта то дополнительно ничего не потребуется: аккаунт на Gitlab и Heroku и все.

Настройка

Настроенный конфиг файл .gitlab-ci.yaml выглядит так:

конфигурационный файл gitlab-ci.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
image: php:7.2
 
variables:
  REVIEW_APP_NAME: "${CI_COMMIT_REF_SLUG}-${CI_PROJECT_NAME}"
 
stages:
  - build
  - test
  - review
  - deploy
 
composer:
  stage: build
  script:
    - apt-get update -yq
    - apt-get install git -yq
    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    - php -r "if (hash_file('sha384', 'composer-setup.php') === 'a5c698ffe4b8e849a443b120cd5ba38043260d5c4023dbf93e1558871f1f07f58274fc6f4c93bcfd858c6bd0775cd8d1') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
    - php composer-setup.php
    - php -r "unlink('composer-setup.php');"
    - php composer.phar install
  artifacts:
    paths:
      - vendor/
      - bin/
  after_script:
    - echo "After script build-${CI_COMMIT_REF_SLUG}"
 
test:
  before_script:
    - echo "Before script"
  script:
    - ls -la
    - bin/phpunit tests --testdox
  stage: test
  dependencies:
   - composer
 
start_review:
  stage: review
  script:
    - apt-get update -yq
    - apt-get install git -yq
    - apt-get install -y ruby-dev curl
    - gem install dpl
    - echo "Authorization Bearer ${REVIEW_APP_NAME}"
    - >-
        curl
        -n
        -X POST https://api.heroku.com/apps
        -d '
        {
        "name":  "'"${REVIEW_APP_NAME}"'",
        "region": "eu",
        "stack": "heroku-18"
        }
        '
        -H "Content-Type: application/json"
        -H "Accept: application/vnd.heroku+json; version=3"
        -H "Authorization: Bearer ${HEROKU_PRODUCTION_API_KEY}"
    - dpl --provider=heroku --app=$REVIEW_APP_NAME --api-key=$HEROKU_PRODUCTION_API_KEY
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    url: https://${REVIEW_APP_NAME}.herokuapp.com
  only:
    - branches
  except:
    - master
 
stop_review:
  stage: review
  script:
    - echo "Deleting review app ${REVIEW_APP_NAME}"
    - >-
        curl
        -n
        -X DELETE https://api.heroku.com/apps/$REVIEW_APP_NAME
        -H "Content-Type: application/json"
        -H "Accept: application/vnd.heroku+json; version=3"
        -H "Authorization: Bearer ${HEROKU_PRODUCTION_API_KEY}"
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    action: stop
  when: manual
  variables:
    #    не подтягивать изменения, нужно если ветка удалена
    GIT_STRATEGY: none
 
 
deploy:
  stage: deploy
  script:
    - apt-get update -yq
    - apt-get install git -yq
    - apt-get install -yqq ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=review-app-example-master --api-key=$HEROKU_PRODUCTION_API_KEY
  dependencies: []
  environment:
    name: production
    url: https://review-app-example-master.herokuapp.com/
  only:
    - master

Главное отличие от предыдущей версии — в конфиге добавляется новый stage — review, который будет состоять из двух job: start_review and stop_review

start_review — при каждом изменении в ветке отличной от master будет создаваться новый review app.

script — используется API Heroku для создания нового приложения. Имя у приложения будет состоять из «короткое имя ветки + название проекта».

environment — окружение для пайплайна. Здесь окружение создается динамически «review/${CI_COMMIT_REF_NAME}». CI_COMMIT_REF_NAME — полное название ветки. Про окружение много написано в официальной документации https://docs.gitlab.com/ee/ci/environments.html . Если вкратце, окружения помогают мониторить состояние деплоя, собирать статистику, применять разные переменные для разных окружении.

Динамическое окружение — это основа основ для review apps.

review/ — групиировка окружения по какому либо ключевому слово, здесь это review.

only branches, except master — фильтрация по веткам, запускать на всех ветках, кроме master

stop_review — остановка и удаление приложения. После того как изменения влиты в мастер, то необходимость в review app отпадает. Чтобы не расходовать ресурсы лучше почистить за собой.

GIT_STRATEGY: none — важное условие. Окружение можно удалить как вручную, так и автоматически. При удалений ветки, остановка окружения происходит автоматически и чтобы не получить в конвейере ошибку «ветка не найдена», нужно отключить проверку изменений в гите.

Запуск

Production url такой https://review-app-example-master.herokuapp.com/ . Здесь находится основной сайт, на котором нас приветствует пингвин TUX

1
2
3
4
5
6
7
8
9
10
< Finally, I launched server >
   \              
    \            
        .--.      
       |o_o |    
       |:_/ |    
      //   \ \    
     (|     | )  
    /'\_   _/`\  
    \___)=(___/  

Поступила важная задача от менеджера:

«Пингвин, конечно, то же хорощо. Но сейчас, наша фирма берет курс на Docker. Так что заменить пингвина на кита. Дизайн во вложении.»

Ну что ж, приступаем к задаче. Для начала нужно создать ветку:

1
git checkout -b "alma-change-logo"

Меняем лого на Кита ссылка на коммит, пушим изменения на сервер CI/CD

Запуск pipeline для review apps
Запуск pipeline для review apps

Если произошла ошибка «message»:»Name is too long (maximum is 30 characters)» при попытке деплоя, то нужно обрезать переменную REVIEW_APP_NAME

1
- export REVIEW_APP_NAME=$(echo $REVIEW_APP_NAME | cut -c1-30)

Здесь переменная REVIEW_APP_NAME перезаписывается, обрезается строка длиннее 30 символов.

После успешного деплоя приложение будет доступно по адресу

https://alma-change-logo-review-app-ex.herokuapp.com/

Главная страница только что созданной Review app
Главная страница только что созданной Review app

Теперь этой ссылкой можно поделиться и с тестировщиком, и с менеджером, и дизайнеру отправить, пусть проверить, правильный ли шрифт использован на странице 🙂

Мерж реквест можно посмотреть по адресу https://gitlab.com/Carsak/review-app-example/merge_requests/3

Заключение

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

Исходный код находится по адресу https://gitlab.com/Carsak/review-app-example

UPD:

Можно оптимизировать процесс создания Review app — запустить деплой только при создании Merge request. Обычно разработчику не нужно общее тестовое приложение, до тех пор пока не будут внесены основные правки. Ведь тестировать он может и в локальной песочнице.

Чтобы Review Apps создавался только при открытии Merge Request нужно изменить правило для шага start_review

с

1
2
only:
  - branches

на

1
2
only:
  - merge_requests

Теперь Review App создается только при создании Merge Request
Теперь Review App создается только при создании Merge Request

Ссылка на Merge Request https://gitlab.com/Carsak/review-app-example/merge_requests/4

Разное, Сам себе админ · CI/CD, Gitlab

Поделиться в сети!

Что об этом думаете? Напишите в комментарии. Можно написать как гость

Copyright © 2016 - 2023 Almat.su (Almat.pro).