что такое деплой git
Что такое деплой?
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
Как реализовать деплой с GitHub на продакшн сервер, использовав Webhook
У меня давно вошло в привычку создавать репозитории на GitHub. Это куда эффективнее, чем держать все на Google Drive или, того хуже, на жестком диске. Но здесь сразу появляется вопрос: как выполнить деплой на рабочий сервер?
Большинство поисковых запросов выводили меня на Jenkins и другие средства непрерывного развертывания. Но мне хотелось найти иное решение. Так я вышел на бесплатный сервис Webhook.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Техническая основа Webhook — свежий дроплет Digital Ocean с Ubuntu 16.04 в качестве рабочего сервера. Для снижения количества шагов, необходимых для реализации задуманного, все действия выполняются root-пользователем.
Начнем с GitHub
Если у вас есть репозиторий и вы хотите его использовать, можно пропустить этот шаг — просто воспользуйтесь SSH URI, и все. Если нет, то создайте его и тоже воспользуйтесь SSH URI.
Устанавливаем Go и Webhook (дроплет Digital Ocean).
Прежде чем начать, стоит выполнить быстрый апдейт и апгрейд со свежим установщиком Ubuntu 16.04.
Теперь для установки WebHook нужно установить язык программирования Go. На время написания этой статьи была актуальна версия 1.11.4, так что если у вас иная версия, нужно внести правки.
Пора загрузить последнюю версию Webhook.
В ходе загрузки нет прогресс-бара, так что нужно просто подождать. После завершения процесса выполните
Webhook установлен, но нужно создать структуру директорий и файлов, чтобы все работало как надо.
Файл hooks.json отвечает за конфигурацию и роутинг, а deploy.sh служит инструментом для выполнения команд, необходимых для обновлений с GitHub.
Первым делом стоит настроить hooks.json, открыв его в текстовом редакторе. Файл содержит конфигурацию для эндпоинтов, которые будут созданы после запуска Webhook, и представляет собой массив объектов, каждый из которых — уникальный эндпоинт.
Id — уникальное имя, которое будет использоваться для URL эндпоинта;
execute-command — скрипт, который будет выполняться при активации эндпоинта;
command-working-directory — директория, которая используется во время запуска execute-command;
trigger-rule — опция, которая будет использоваться в целях информационной безопасности, это секретная фраза для эндпоинтов.
Напомню, что все действия я выполняю от root, поэтому начальный адрес /root. Если логиниться под обычным пользователем, нужно прописать /home/username, где username, что логично, — имя этого пользователя. Не нужно использовать
/, путь должен быть абсолютным, в противном случае вы получите ошибку.
Вы могли заметить, что мы настроили рабочую папку, которая пока еще не существует. Перед тем как создать ее, нужно закончить с deploy.sh.
Скрипт всегда должен начинаться с “shebang”. Перед открытием файла стоит выполнить which bash. Ну а дальше выполняются следующие команды в скрипте:
Теперь и Go, и Webhook установлены, так что нужно настроить конфигурацию в hooks.json и написать скрипт, отвечающий за деплой. Он будет изменять каталог назначения, работая с главной веткой репозитория GitHub.
Наконец, пора привести Webhook в активный режим, заменив 000.000.000.000 рабочим IP-адресом Doplet.
В процессе выполнения можно заметить вывод URL с
Настройка Git (Digital Ocean Droplet)
Настройка сервера еще не закончена. Для ее завершения нужно открыть новое окно терминала и снова аутентифицироваться на сервере, в то время как в первом окне идет выполнение Webhook. В самом начале мы задавали URI репозитория, теперь его нужно использовать.
Для этого требуется перейти в рабочую директорию, заданную в hooks.json, и прописать следующее:
При этом нужно заменить URI на свой собственный вместо того, что указал я.
Финальным шагом будет генерация ключей SSH для того, чтобы с их помощью подключаться к GitHub. В окне терминала набираем ssh-keygen и подтверждаем, нажимая Enter, пока генерируются ключи. Затем нужно вывести публичные ключи, набрав cat
/.ssh/id_rsa.pub. Получится нечто вроде этого:
Ну а теперь все, что осталось, — настроить репозиторий GitHub и протестировать деплой.
Настройка ключа деплоя и Webhook (GitHub)
В браузере переходим в настройки для репозитория. Сначала нужно добавить Deployment Key.
Во время добавления ключа нужно задать его название и вставить в вывод ключа выше. GitHub дает возможность работать лишь с публичными ключами, так что в случае необходимости нужно задать несколько ключей. Как только все закончено, наступает очередь раздела Webhook.
Трем полям в этом разделе нужно уделить особенное внимание. Это payload URL, content type и secret. Payload URL — эндпоинт, который прослушивается Webhook, content type — формат данных, secret — кастомная строка из файла hooks.json. В нашем случае это “The Returners”.
После создания Webhook должна появиться соответствующая отметка в настройках, которая показывает, что сервер доступен. Если проверить терминал с работающим Webhook, можно видеть, что репозиторий уже в работе.
Для проверки рабочего процесса копируем репозиторий на локальную машину, если это еще не сделано, и вносим изменения в главную ветку. После этого они должны отобразиться и на сервере. Готово.
Разработчик, который уже выполнял все это несколько раз, тратит на настройку около 10 минут. Но это после того, как на метод проб и ошибок потрачены часы. Помните про эти четыре важных особенности настройки:
Деплой сайта с GitHub на хостинг через SSH
Привет! В этой статье я расскажу, как можно деплоить (или загрузить) сайт на ваш хостинг при пуше на GitHub. Все это будем делать через SSH
Что потребуется
Итак, чтобы разобраться со всей этой темой, вам понадобится:
Принцип
Вкратце скажу принцип работы всего этого действа: когда мы будем пушить данные в репозиторий, сработает GitHub Action, которому сказано подключиться к вашему хостингу по SSH и залить туда данные с помощью rsync.
Создание SSH-ключа
Открываем Git Bash, вводим следующую команду:
При использовании команды указывать парольную фразу не нужно.
Скриншот из консоли при вводе команды создания ключа
В этой папке вы найдете ключи id_rsa и id_rsa.pub, приватный и публичный ключи соответственно.
Добавление ключей
Итак, когда вы создали ключи, их нужно добавить на хостинг и в репозиторий. Как именно устроено это на разных хостингах, я знать не могу, но покажу на примере cPanel, как это выглядит.
Скриншот из cPanel, доступ по SSH
Добавляем id_rsa.pub в публичные ключи репозитория, если потребуется, авторизуем его (просто нажатием кнопки), и сохраняем.
Теперь идем в репозиторий GitHub, переходим в Settings, оттуда переходим в Secrets. Внутри нужно будет назвать секрет и ввести приватный ключ (сохраните его заранее в буфер обмена). Называйте ключ просто – key, вставляйте ключ и сохраняйте.
Готово, оба ключа введены и должны работать.
Пишем файл для деплоя
Чтобы сделать собственно сам деплой, то есть дать понять гиту, что при изменении кода надо залить его на удаленный сервер, нам нужно написать скрипт на языке Yaml. Ниже я приложу код, вникать в него вовсе необязательно, но ниже я укажу действительно важные моменты.
Ну а здесь происходит буквально деплой данных. Сперва, командой cd app мы переходим в папку app (опять же, абсолютно опциональная вещь, если у вас просто нет папки app и никуда не надо переходить – можно убрать эту команду). Ну и далее для нас важна только строка, указывающая, куда все это деплоить:
Это полный путь к моему серверу, причем в конце еще и указан адрес конкретного сайта, в данном случае blog.maxgraph.ru. Если вдруг вы не знаете этот путь – можете уточнить у поддержки вашего хостинга. И будьте внимательны, чтобы случайно не задеплоить данные не туда, куда надо, ведь подобный деплой полностью затирает то, что было ранее.
Что дальше
Итак, файлик deploy.yml нужно поместить в ваш проект в специальную папку .github, чтобы гитхаб о ней узнал, и затем просто запушить проект.
После пуша вы сразу можете перейти во вкладку actions вашего репозитория и вживую посмотреть, как все команды из yml файла выполняются прямо там.
Скриншот вкладки GitHub Actions с рабочим запуском deploy.yml
Заключение
Надеюсь, данная статья была вам полезна. Если же вам интересна видео-версия – в начале статьи есть видео, переходите и смотрите! До скорого!
Деплой (deploy) обычного сайта через Gitlab на примере Bitrix
Хочу поделиться интересным решением, которое подсмотрел у одного заказчика. Я расскажу, как настроить автоматический деплой обычного php сайта на примере bitrix, с помощью gitlab и его webhooks. После коммита разработчика в рабочий репозиторий, код будет автоматически выкатываться на тестовый или рабочий сервер. Решение придумал не я. Делюсь им, потому что показалось полезным, плюс, чтобы самому не забыть и в будущем использовать.
Введение
Конкретно в моем примере я расскажу, как автоматизировать процесс деплоя сайта на bitrix. После коммита разработчика в git репозиторий, будет запускаться webhook через штатный функционал gitlab. Этот вебхук будет дергать url на сервере. Авторизация через token в заголовке запроса. Запрос по этому url будет инициировать запуск bash скрипта, который делает git pull на сервере.
В общем и целом ничего особенного тут нет. Мне понравилось целостность и законченность решения. Не нужно самому колхозить эти скрипты. Решение, конечно, костыльное, но с bitrix чаще всего все решения такие 🙂 Тут плюс в том, что все настраивается очень просто и быстро. Сможет настроить обычный программист для себя, даже если он работает с проектом один.
Как я уже сказал, автор данного решения мне не известен. Ему кто-то увидит свое решение тут и расстроится, что его просто скопировали и не указали авторство, то сообщите мне, я укажу вас.
Особенность деплоя сайта на bitrix
Настройка деплоя bitrix сайта имеет свои нюансы. Дело в том, что битрикс не простой сайт. Через его панель управления можно не только изменять параметры, которые записываются в базу, но и создавать php файлы. Можно добавить или отредактировать шаблон, скопировать какие-то файлы через встроенный файловый менеджер. В связи с этим, нужно внимательно следить за тем, что было сделано через админку. Если просто деплоить исходники из репозитория, можно потерять эти изменения.
А в остальном это обычный php сайт, так что предложенное мной решение деплоя может быть применено для любого другого сайта.
Загрузка bitrix в git репозиторий
Для начала создадим пустой репозиторий и загрузим туда свой сайт. Я не буду подробно останавливаться на работе с git и настройке gitlab. В данном примере подойдет и бесплатный аккаунт на публичном сервисе. Идем на наш веб сервер, куда будем выгружать сайт из репозитория. У меня на нем настроен bitrixenv. Я все буду делать под пользователем bitrix. Заходим в консоль под ним.
Генерируем ключи, чтобы по ним ходить в репозиторий.
Копируем публичный ключ и добавляем его в gitlab.
Возвращаемся на сервер. Немного настроим git.
Идем в каталог с сайтом и инициируем репозиторий.
Создаем файл .gitignore примерно следующего содержания.
Можете его сами изменить под свои требования. Добавляем удаленный репозиторий и делаем первый коммит в него со всеми исходниками сайта.
Наш сайт на битриксе запушился в репозиторий.
Настройка деплоя
Создаем в папке с bitrix директорию gitpull или как вам угодно. Название не принципиально. В нее кладем файл index.php примерно такого содержания.
Данный webhook будет дергать указанный url, а он запускать скрипт /home/bitrix/git/www/git.pull.sh. Создадим директорию и сам скрипт.
Не забудьте изменить адрес директории с исходниками. Скрипт будет писать логи в /home/bitrix/tmp/autopull, так что создаем и его.
В целом, не вижу смысла подробно комментировать скрипты. Они небольшие и в целом понятно, что происходит. PHP файл проверяет токен и если он верный, запускает sh скрипт. Этот скрипт делает git pull, записывает вывод в лог файл. Проверьте внимательно, чтобы все пути у вас были актуальны и команды git соответствовали реальным адресам и названиям репозитория.
После того, как все создали, можно пойти в gitlab, в настройку хука и выполнить тест.
В выпадающем списке выберите Push Events. Если все нормально, в ответ должны получить:
Теперь идите на сервер и посмотрите директорию /home/bitrix/tmp/autopull. Там должна появиться папка с адресом вашего сайта и в ней лог файл с выводом команды в скрипте.
Проверка деплоя (deploy) bitrix
Теперь проверим, как собственно, все будет работать. Для этого можете либо склонировать к себе репозиторий с исходниками, внести изменения, закомиттить их и запушить в репозиторий. Либо можно просто через веб интерфейс gitlab добавить новый файл и сделать commit.
Я просто добавлю файл test.deploy в корень репозитория.
Идем на сервер и ищем этот файл в корне сайта.
Он прилетел сюда автоматически после коммита, который инициировал webhook в gitlab. И дальше все по цепочке выполнилось. В логе появилась соответствующая запись о событии.
Проверьте на всякий случай ответ на запрпос php файла без нужного токена в заголовках. Url с gitpull/index.php должен возвращать ошибку.
Когда будете себе настраивать, поменяйте на всякий случай путь gitpull на свой. Если у вас свой сервер gitlab, можно ограничить к нему доступ по ip сервера, откуда хук будет прилетать.
Заключение
Надеюсь, получилась полезная история на тему деплоя bitrix. С ним очень много нюансов и тонкостей. Программисты, которые первый раз его видят, не понимают, как с ним в принципе работать. Как организовать dev и stage окружение? У битрикса же лицензия на копию сайта. Она иногда слетает, если сайт скопировать и не выполнить некоторые действия с копией.
Так же проблемы возникают при разворачивании сайта для разработки на поддомене. Это не всегда возможно, так как есть шаблоны, в которых зашиты редиректы на основной домен. В итоге поддомен постоянно перекидывает на основной сайт. Ну и много остальных нюансов, описывать которые надо отдельно, не в рамках этой статьи.
У меня есть на примете черновики различных деплоев с помощью gitlab и teamcity, но оформлять их в полноценные статьи не хватает времени. Тема узкая, не очень читаемая. Писать долго, а выхлоп небольшой. Возможно в будущем напишу что-то еще по этой теме.
GitLab CI: Учимся деплоить
В данной статье речь пойдет об истории успеха воображаемого новостного портала, счастливым владельцем которого являетесь вы. К счастью, вы уже храните код проекта на GitLab.com и знаете, что для тестирования можно использовать GitLab CI.
Теперь вам интересно, можно ли пойти дальше и использовать CI еще и для развертывания проекта, и если да, то какие возможности при этом открываются.
Чтобы не привязываться к какой-либо конкретной технологии, предположим, что ваше приложение является простым набором HTML-файлов, никакого выполнения кода на сервере, никакой компиляции JS assets. Деплоить будем на Amazon S3.
У автора нет цели дать рецепты для конкретной технологии в этой статье. Наоборот, примеры кода максимально примитивны, чтобы слишком на них не зацикливаться. Смысл в том чтобы вы посмотрели на фичи и принципы работы GitLab CI в действии, а потом применили их для вашей технологии.
Начнем с начала: в вашем вымышленном приложении пока еще нет поддержки CI.
Начало
Развертывание: в данном примере результатом развертывания должно быть появление набора HTML-файлов в вашем бакетe (bucket) S3, который уже настроен для хостинга статических вебсайтов).
Добиться этого можно множеством различных способов. Мы будем использовать библиотеку
awscli от Amazon.
Полностью команда развертывания выглядит следующим образом:
Пуш кода в репозиторий и развертывание — это два разных процесса
Попробуем автоматизировать этот процесс с использованием GitLab CI.
Первое автоматическое развертывание
При пуше на GitLab код автоматически развертывается с помощью CI
Также, не стоит забывать о переменных окружения, полученных из AWS Console:
Должно сработать, однако держать секретные ключи в открытом виде (даже в приватном репозитории) — не самая лучшая идея. Посмотрим, что с этим можно сделать.
Сохранение секретов
В GitLab есть специальный раздел для секретных переменных: Settings > Variables
Все данные, помещенные в этот раздел станут переменными окружения. Доступ к этому разделу есть только у администратора проекта.
Раздел variables можно удалить из настроек CI, но лучше давайте воспользуемся им для другой цели.
Создание и использование публичных переменных
С увеличением размера файла конфигурации становится удобнее хранить некоторые параметры в его начале в качестве переменных. Такой подход особенно актуален в случае, когда эти параметры используются в нескольких местах. Хоть в нашем случае до такого пока что не дошло, в демонстрационных целях создадим переменную для названия бакета S3:
Тем временем посещаемость вашего сайта повысилась, и вы наняли разработчика, чтобы он вам помогал. Теперь у вас есть команда. Посмотрим как работа в команде влияет на рабочий процесс.
Работа в команде
Теперь в одном и том же репозитории работают два человека, и использовать ветку master для разработки более не целесообразно. Поэтому вы принимаете решение использовать различные ветки для разработки новых фич и написания статей и мержить их в master по мере готовности.
Проблема в том, что при текущей настройке CI не поддерживает работу с ветками — при пуше в любую ветку на GitLab происходит развертывание текущего состояния master на S3.
Мы хотим избежать развертывания каждой ветки на сайте
С другой стороны, было бы неплохо иметь возможность предпросмотра изменений, внесенных из веток для выделенной функциональности (feature-веток).
Создание отдельного пространства для тестирования
Патрик (разработчик, которого вы недавно наняли) напоминает вам, что существует такая функциональность, как
GitLab Pages. Как раз то, что нужно — место для предпросмотра новых изменений.
Для размещения вебсайта на GitLab Pages ваша конфигурация CI должна удовлетворять трем простым требованиям:
После добавления кода из примера для сайтов на чистом HTML файл настройки CI выглядит следующим образом:
Всего в нем содержатся две задачи: одна ( deploy ) проводит развертывание сайта на S3 для ваших читателей, а другая ( pages ) на GitLab Pages. Назовем их соответственно «Production environment» и «Staging environment».
Развертывание всех веток, кроме master, будет проводиться на GitLab Pages
Среды развертывания
GitLab поддерживает работу со средами развертывания. Все, что вам нужно сделать, это назначить соответствующую среду для каждой задачи развертывания:
GitLab отслеживает все ваши процессы развертывания, так что вы всегда можете увидеть, что в текущий момент развертывается на ваших серверах:
Также, GitLab хранит полную историю всех развертываний для каждой среды:
Итак, мы оптимизировали и настроили все, что только могли, и готовы к новым вызовам, которые не заставят себя долго ждать.
Работа в команде, часть 2
Опять. Это опять произошло. Стоило вам только запушить свою feature-ветку для превью, как спустя минуту Патрик сделал то же самое и тем самым перезаписал содержимое staging. #$@! Третий раз за сегодня!
Идея! Используем Slack для оповещений о развертываниях, чтобы никто не пушил новые изменения, пока старые не закончили развертываться.
Оповещения Slack
Настроить оповещения Slack несложно. Надо лишь взять из Slack URL входящего вебхука…
… и передать его в Settings > Services > Slack вместе с вашим логином Slack:
Поскольку вы хотите получать уведомления только о развертываниях, в показанных выше настройках можно убрать галочки на всех пунктах, кроме “Build”. Вот и все, теперь вы будете получать оповещения о каждом развертывании:
Работа в большой команде
Со временем ваш сайт стал очень популярным, а ваша команда выросла с двух до восьми человек. Разработка происходит параллельно, и людям все чаще приходится ждать в очереди для превью на Staging. Подход “Проводите развертывание каждой ветки на Staging” больше не работает.
Пришло время вновь модифицировать рабочий процесс. Вы и ваша команда пришли к соглашению, что для выкатывания изменений на staging-сервер нужно сначала сделать мерж этих изменений в ветку “staging”.
Разработчики проводят мерж своих feature-веток перед превью на Staging
Само собой, при таком подходе на мерж тратятся дополнительное время и силы, но все в команде согласны, что это лучше, чем ждать в очереди.
Непредвиденные обстоятельства
Невозможно все контролировать, и неприятности имеют свойство случаться. К примеру, кто-то неправильно смержил ветки и запушил результат прямо в production как раз когда ваш сайт находился в топе HackerNews. В результате тысячи человек увидели кривую версию сайта вместо вашей шикарной главной страницы.
К счастью, нашелся человек, который знал про кнопку Rollback, так что уже через минуту после обнаружения проблемы сайт принял прежний вид.
Rollback перезапускает более раннюю задачу, порожденную в прошлом каким-то другим коммитом
Для того, чтобы запустить развертывание вручную, перейдите на вкладку Pipelines > Builds и нажмите на вот эту кнопку:
И вот ваша компания превратилась в корпорацию. Над сайтом работают сотни человек, и некоторые из предыдущих рабочих практик уже не очень подходят к новым обстоятельствам.
Ревью приложений
Следующим логическим шагом является добавление возможности развертывания временного инстанса приложения каждой feature-ветки для ревью.
В нашем случае для этого надо настроить еще один бакет S3, с той лишь разницей, что в этом случае содержимое сайта копируется в “папку” с названием ветки. Поэтому URL выглядит следующим образом:
А так будет выглядеть код, замещающий задачу pages :
Обратите внимание на то, что переменная S3_BUCKET_NAME определена внутри задачи — таким образом можно переписывать определения более высокого уровня.
Визуальная интерпретация такой конфигурации: 
Технические детали реализации такого подхода сильно разнятся в зависимости от используемых в вашем стеке технологий и от того, как устроен ваш процесс развертывания, что выходит за рамки этой статьи.
Реальные проекты, как правило, значительно сложнее, чем наш пример с сайтом на статическом HTML. К примеру, поскольку инстансы временные, это сильно усложняет их автоматическую загрузку со всеми требуемыми сервисами и софтом “на лету”. Однако это выполнимо, особенно, если вы используете Docker или хотя бы Chef или Ansible.
Про развертывание при помощи Docker будет рассказано в другой статье. Честно говоря, я чувствую себя немного виноватым за то, что упростил процесс развартывания до простого копирования HTML-файлов, совершенно упуская более хардкорные сценарии. Если вам это интересно, рекомендую почитать статью «Building an Elixir Release into a Docker image using GitLab CI».
А пока что давайте обсудим еще одну, последнюю проблему.
Развертывание на различные платформы
В реальности мы не ограничены S3 и GitLab Pages; приложения разворачиваются на различные сервисы.
Более того, в какой-то момент вы можете решить переехать на другую платформу, а для этого вам нужно будет переписать все скрипты развертывания. В такой ситуации использование gem’а dpl сильно упрощает жизнь.
В приведенных в этой статье примерах мы использовали awscli в качестве инструмента для доставки кода на сервис Amazon S3. На самом деле, неважно, какой инструмент вы используете и куда вы доставляете код — принцип остается тот же: запускается команда с определенными параметрами и в нее каким-то образом передается секретный ключ для идентификации.
Инструмент для развертывания dbl придерживается этого принципа и предоставляет унифицированный интерфейс для определенного списка плагинов (providers), предназначенных для развертывания вашего кода на разных хостинговых площадках.
Задача для развертывания в production с использованием dpl будет выглядеть вот так:
Так что если вы проводите развертывание на различные хостинговые площадки или часто меняете целевые платформы, подумайте над использованием dpl в скриптах развертывания — это способствует их единообразию.