В прошлой статье Gitlab CI/CD на примере PHP проекта я описал основы настройки Gitlab CI/CD. Теперь пришла очередь написать про настройку Gitlab Review Apps. В официальной документации есть примеры по настройке для Nginx и Openshift. Неплохо было бы дополнить его для работы с Heroku, учитывая что деплой в предыдущей статье производится как раз туда.
Что такое 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 выглядит так:
|
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 104 105 |
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 11 12 |
< Finally, I launched server > \ \ .--. |o_o | |:_/ | // \ \ (| | ) /'\_ _/`\ \___)=(___/ |
Поступила важная задача от менеджера:
«Пингвин, конечно, то же хорощо. Но сейчас, наша фирма берет курс на Docker. Так что заменить пингвина на кита. Дизайн во вложении.»
Ну что ж, приступаем к задаче. Для начала нужно создать ветку:
|
1 2 3 |
git checkout -b "alma-change-logo" |
Меняем лого на Кита ссылка на коммит, пушим изменения на сервер CI/CD
Если произошла ошибка «message»:»Name is too long (maximum is 30 characters)» при попытке деплоя, то нужно обрезать переменную REVIEW_APP_NAME
|
1 2 3 |
- export REVIEW_APP_NAME=$(echo $REVIEW_APP_NAME | cut -c1-30) |
Здесь переменная REVIEW_APP_NAME перезаписывается, обрезается строка длиннее 30 символов.
После успешного деплоя приложение будет доступно по адресу
https://alma-change-logo-review-app-ex.herokuapp.com/
Теперь этой ссылкой можно поделиться и с тестировщиком, и с менеджером, и дизайнеру отправить, пусть проверить, правильный ли шрифт использован на странице 🙂
Мерж реквест можно посмотреть по адресу 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 3 4 |
only: - branches |
на
|
1 2 3 4 |
only: - merge_requests |
Ссылка на Merge Request https://gitlab.com/Carsak/review-app-example/merge_requests/4