Staging environment что это
Среды разработки
В любом производственном процессе, к которому относится и разработка программ, есть различные этапы. Грубо говоря, их можно представить так:
Производство
С этим пунктом всё более менее понятно: мы поставили себе любимый редактор, открыли в нем исходный код проекта и работаем, не покладая рук. Возможно, даже, пишем тесты и, самое главное, иногда их запускаем. Если это веб-сайт, то периодически запускаем сервер и смотрим в браузере, что получилось.
Кроме этого, код в среде разработки обычно пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то поломалось, и нужно поправить только небольшой кусок, а новые наработки вы ещё не готовы выливать.
Читайте также: DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
Сборка
После того, как вы реализовали свою задачу (фичу) и она была протестирована, код задачи вливается в основную ветку — и происходит так называемая интеграция. Это название связано с тем, что, возможно, кроме этой фичи, параллельно велась разработка другой фичи, в другой ветке, и с высокой вероятностью ту задачу выполняли даже не вы. И вот теперь в основной ветке они встретились, а работают они вместе или нет — ещё предстоит выяснить.
(Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде).
Контроль и испытания
Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи, и второй, на котором проверяется всё то, что пойдет в следующий релиз.
Ведь даже собрав всё в одну ветку (все фичи) и проверив их локально, нельзя быть до конца уверенным, что в бою, на реальных данных, всё заработает хорошо. Кроме этого, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть/проверить, всё ли хорошо. И тут на сцену врывается ещё одна производственная среда, которая называется средой интеграции (предпродакшен), или стейджинг (staging), как её все называют.
Тут появляется ещё одно новое слово: «релиз». Релиз по-другому называют «выпуск». С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.
Continuous Integration Server
Одна из разновидностей сборочной среды называется «сервер непрерывной интеграции». Это такая отдельная машина (а может быть целый парк машин), на которую выливается код для проверки в автоматическом режиме. Обычно это происходит по какому-нибудь событию, например, на Github это пулреквест. В настроенных проектах каждый пулреквест отправляется в сервис, подобный https://travis-ci.org. Этот сервис прогоняет тестовый набор на нужной ветке (с фичей) и после этого прикрепляет отчет к пулреквесту, в котором пишет о результатах проверки.
Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием «экстремальное программирование (XP)».
Доставка
Мы упустили один важный момент. Каким образом новый код попадает в предпродакшен и в продакшен-среду после того, как вы закончили разработку? Делает он это благодаря процессу, который в простонародье называют «деплой».
Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер (а если их много?) клонируют код, руками меняют базу и так далее.
Можно бесконечно обсуждать то, насколько это плохо. Начиная с того, что по сути отсутствует налаженный, повторяемый процесс, а значит всегда есть вероятность того, что ворвется человеческий фактор и случайно будет что-то забыто/потеряно/удалено. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася, а иногда он болеет, ходит в отпуск и может уволиться. Часто в таких компаниях релиз — крайне болезненная процедура, которая занимает не один час, а может даже пару дней.
При хорошо отлаженном процессе, релиз занимает десяток минут, и может делаться любым разработчиком в любой момент (почти). Хекслет иногда деплоится по 5-10 раз в день.
Основные задачи, которые стоят перед вами во время деплоя:
Настройка Staging окружения
Общепринятая практика заключается в том, чтобы работать локально в проекте и выкатывать ревизии на производственный сервер, но шаг, который люди часто пропускают, является промежуточным сервером. Промежуточный сервер представляет собой смесь между производством и разработкой; вы можете проверить свое приложение так, как если бы оно было на производстве. Давайте рассмотрим некоторые из проблем, которые вам придется рассмотреть, а также шаги, необходимые для репликации производственной платформы как службы (PAAS).
Это произошло не один раз: я выкатываю ревизию моего приложения в производство, только чтобы найти проблему после ее публикации. Эти проблемы могут быть такими же простыми, как забывать добавлять изображения в ваш репозиторий, или же может быть такой же большой, как изменение структуры базы данных локально, и забыть обновить производственную базу данных. Проблемы случаются со всеми, особенно когда вы устремились к крайним срокам. В этих ситуациях разумной идеей является создание промежуточного окружения. Идея состоит в том, чтобы иметь сервер, который тесно реплицирует производственное окружение, чтобы протестировать ваше приложение перед публикацией.
Промежуточное окружение не только позволяет отследить человеческие ошибки, но и проблемы, связанные с программным обеспечением.
Это все в деталях (в основном)
Проблемы случаются со всеми, особенно когда вы устремились к крайним срокам.
Создание промежуточной среды зависит от вашей производственной среды. Нет волшебного решения, которое работает в любой ситуации. Но в большинстве случаев следуют аналогичной схеме, и я расскажу о всех ключевых моментах.
Справедливо предположить, что большинство людей развертывают свои приложения с помощью какого-то средства управления версиями (например, GIT). Если есть вероятность того, что вы работаете над старым проектом, который все еще использует FTP, сайты, такие как ftploy.com или deployHQ.com, могут выступать в качестве буфера между GIT и вашим сервером. Джеффри Уэй собрал информативное видео, в котором подробно описывается, как это сделать.
Помимо GIT, вам нужно подумать о языках, программном обеспечении и «специальных» функциях, предлагаемых вашими производственными серверами. Я использую PAAS на основе PHP, названный Fortrabbit, потому что они предлагают обновленную поддержку PHP, Apache и GIT. Они также предоставляют возможность добавить ключевое слово в сообщение GIT commit, которое запускает Composer для установки зависимостей вашего проекта.
Это система, которую я установлю в остальной части этой статьи. Его стандартный набор функций, а также специальная функция композитора делают Fortrabbit идеальным для широкого круга хостов. Просто помните: это не волшебное решение, но шаги, которые вы делаете, следуют тому же шаблону, который вы использовали бы для настройки промежуточной среды для большинства проектов. Подготовьте процесс к вашим конкретным потребностям.
Поэтому без дальнейших церемоний, давайте уже приступим.
Создание сервера
Создание промежуточного окружения напрямую зависит от вашего производственного окружения.
Существует множество различных операционных систем, которые вы можете запускать на сервере. Fortrabbit запускает Debian Squeeze на своих серверах, и поскольку мы пытаемся их сопоставить, я решил запустить его также.
Vagrant принимает виртуальный снимок операционной системы в качестве базового «бокса», и затем вы можете создавать несколько виртуальных машин из этого образа. Итак, сначала нужно загрузить базовое поле для Debian Squeeze. Я не совсем уверен, откуда моя копия, поэтому я загрузил ее в DropBox для загрузки и использования. Чтобы установить, откройте окно терминала и введите:
Это добавляет бокс в Vagrant с именем «debian». Теперь мы можем создать экземпляр этого бокса для нашего промежуточного окружения. Сначала создадим новую папку:
Затем создайте конфигурационный файл Vagrant, введя:
Эти параметры говорят Vagrant о создании новой виртуальной машины на основе нашего базового блока Debian Squeeze. Затем он устанавливает сетевой режим в « bridged». Виртуальная машина с мостовой сетью отображается как новая физическая машина для вашего маршрутизатора, поэтому она автоматически получает свой собственный IP-адрес. Это позволяет получить доступ к устройству с любого устройства в сети (возможно, вне сети, если вы настроите маршрутизатор).
Теперь мы можем запустить нашу виртуальную машину с помощью команды: « vagrant up » (без кавычек).
Вы должны увидеть вывод Vagrant, создающий вашу виртуальную машину. Если ваш компьютер имеет несколько сетевых адаптеров, подключенных к сети, Vagrant предложит вам выбрать NIC для моста.
Давайте перейдем и настроим программное обеспечение сервера.
Программное обеспечение
Настройка Fortrabbit включает в себя:
Мы готовы начать. Убедитесь, что окно терминала открыто и вы залогинены на сервере через SSH. Во-первых, добавьте dotdeb repo в APT (менеджер пакетов), добавив новый файл в каталог sources.d :
Это открывает новый файл с именем dotdeb.list в vim (текстовый редактор). Имя не важно, потому что все файлы в этом каталоге считываются в APT. Нам нужно добавить четыре строки в этот файл. Если вы никогда не использовали VIM, просто введите « i », чтобы войти в режим вставки и скопируйте/вставьте следующие четыре строки:
Нажатие Enter сохраняет файл и возвращает вас в командную строку.
Теперь мы добавили репозитории, но нам еще нужно добавить подпись, прежде чем мы сможем их использовать. Чтобы добавить ключ GNU, введите следующее:
Это загружает ключ dotdeb и добавляет его как подписанный источник. Теперь обновите APT, чтобы вытащить новый пакет, набрав:
Это может занять около минуты, но у вас будут все пакеты dotdeb, перечисленные в APT, когда выполнится команда. Благодаря тому, как dotdeb настроен и как загружаются зависимости APT, мы можем одновременно установить Apache и PHP, набрав:
С помощью этой отдельной строки APT устанавливает и настраивает Apache2 и PHP5. Если вы используете дополнение Memcache Fortrabbit, вы можете установить его с помощью:
Но я не собираюсь касаться memcache в нашем примере в этой статье.
Теперь нам нужно установить расширения, которые использует Fortrabbit. Выполните следующую команду:
Последнее, что нам нужно установить, это Composer. Я собираюсь установить его глобально, потому что мы будем использовать его в нескольких разных местах. Команды для глобальной установки Composer:
Первая команда загружает и выполняет установку; вторая команда перемещает Composer в папку bin, чтобы мы могли использовать ее без объявления пути. Перейдем к конфигурации.
Настройка Apache
Скорее всего, вы можете работать над несколькими проектами. Если это так, наличие промежуточного сервера для каждого проекта создает много накладных расходов. Чтобы разрешить использование нескольких сайтов на одном сервере, нам нужно добавить виртуальные хосты на основе имени в Apache и разделить каталоги и репозитории для каждого проекта.
Начнем с виртуального хоста.
Внутри введите следующее (помните, чтобы нажать « i » для режима вставки):
Первая строка объявляет виртуальный хост, который прослушивает запросы на любом IP-адресе на порту 80. Затем мы устанавливаем адрес электронной почты администратора и имя сервера. Адрес электронной почты предназначен для сообщений об ошибках, а параметр имени сервера сообщает Apache, когда он читает этот виртуальный хост. Регулярные виртуальные хосты работают с IP-адресами. Например, каждый vhost прослушивает другой IP; так Apache различает их.
Поскольку у вас, вероятно, есть только один IP-адрес, мы можем использовать виртуальные хосты на основе имен, позволяя вам указать другое имя на одном IP-адресе.
В нашем примере любые запросы, направленные на demo.dev, собираются этим виртуальным хостом.
Последние две строки говорят Apache, как назвать файл лога и что писать в этот лог. Наш файл лога называется demo.log в папке логов Apache, расположенной в /var/log/apache2/ на этой виртуальной машине.
Чтобы включить этот vhost, введите следующее:
Мы не хотим, чтобы пользователь root имел собственную папку, поэтому измените ее на пользователя vagrant с помощью команды chown :
Теперь перезапустите Apache:
Немного Git магии
Убедитесь, что вы находитесь в домашнем каталоге, набрав cd
Пустой репо является стандартным репо без рабочего каталога. Если вы хотите узнать больше о GIT, посмотрите видеоролик Andrew Burgess.
Теперь нам нужна возможность пушить код в папку сайта, и есть много способов сделать это. Но мне нравится делать вещи как можно ближе к сервису, которому я подражаю. Вот картина процесса git fortrabbit, взятого с их сайта:
Вы можете видеть, что процесс push проходит через три этапа. Он отображает сообщение об обновлении при его подключении и развертывает сайт в каталоге. Заключительный шаг устанавливает все, если сообщение фиксации изменений содержит ключевые слова «[trigger: composer]». Затем, после завершения этих трех шагов, вам будет отображено «>> All Done
Прежде чем создавать хуки, я хочу поговорить о цветах.
Я выполняю большую часть своей работы в терминале, и чаще всего терминальные приложения оставляют все одинаковым цветом. Добавление различных цветов в ваше приложение гораздо повышает читаемость и упрощает его использование. Так что я займусь распространением «цветовых практик» в терминальных приложениях, я займу минутку, чтобы обсудить, как они работают.
Цвета в терминале
Терминалы поставляются с шестнадцатью цветами ANSI, которые можно настроить и использовать на терминале. Вот изображение экрана настроек iTerm2, показывающего шестнадцать цветовых слотов:
Если все сделано правильно, приведенный выше код выводит слова «hello world» красным цветом (если только этот слот не установлен на другой цвет).
Всюду по остальной части учебника я буду добавлять цвета к командам. Не стесняйтесь следовать или опускать их; они не являются строго обязательными. Но если вы хотите использовать цвета, не стесняйтесь использовать мой класс помощник. Теперь давайте вернемся к написанию хуков.
Создание хуков
Если вы еще раз взглянете на скриншот Fortrabbit, вы увидите, что перед обновлением репо отображается сообщение «Шаг 1: Обновление репозитория». Чтобы сделать все правильно, мы должны поместить это сообщение в хук pre-receive, который выполняется до обновления репо. В окне терминала введите:
Это открывает хук для редактирования. Добавьте следующий код:
Первая строка сообщает ОС, что это файл PHP и запускать его как таковой. Затем мы назначаем цвет и последовательность сброса для переменных. Последний шаг делает echo строки.
Следующий хук немного сложнее, потому что он обрабатывает остальные действия. Мы сделаем это шаг за шагом, поэтому сохраните первый хук (: wq) и откройте следующий:
Хук после приема изменений запускается после обновления репо. Мы должны сначала обновить сайт, а затем проверить триггер Composer. Вот скелет нашей программы, не говоря о новой логике:
Это две простые команды, но вы получите сообщение об ошибке, если попытаетесь запустить их из хука.
GIT устанавливает некоторые переменные среды до запуска хуков. Вы можете обойти это одним из двух решений, и я покажу вам оба.
Теперь нам нужно проверить триггер Composer. Давайте разделим это на два шага. Сначала мы проверяем триггер, а затем выполняем composer. Замените второй комментарий TODO следующим:
Первая строка извлекает сообщение фиксации с помощью команды git log и передает в специальном формате, чтобы исключить любую дополнительную информацию. Затем мы проверяем, имеет ли строка специальное триггерное слово и выводим третий шаг и OK-сообщение. Мы проверяем ключевое слово Composer, но вы можете реализовать несколько ключевых слов для других функций, таких как: migrate в Laravel или выполнить модульные тесты. Добавьте что-нибудь, чтобы улучшить рабочий процесс.
Вторая проблема заключается в том, что иногда Composer использует GIT для загрузки пакетов, и эти попытки терпят неудачу из-за переменных среды. Итак, вот хорошее место, чтобы просто удалить переменную окружения «GIT_DIR». Замените комментарий для запуска Composer следующим образом:
Связывание свободных концов
У нас теперь есть настройка обоих хуков, но мы не совсем готовы начать использовать наш сервер. Во-первых, нам нужно сделать эти крючки исполняемыми:
Затем создайте репозиторий GIT в папке сайта. Мы получим ошибку, если попытаемся запустить наши хуки, потому что папка сайта не является репозиторией GIT. Чтобы исправить этот введите:
Вы также должны добавить свой открытый ключ к авторизованным хостам этого сервера, чтобы вы могли получить доступ к серверу через GIT без пароля. Вы можете скопировать свой открытый ключ, набрав на своем компьютере (а не виртуальной машине):
Затем просто вставьте его на сервер в файл
Просто добавьте его в файл, но оставьте все, что уже внутри.
Затем нам нужно добавить IP-адрес этого сервера в наш файл hosts. Чтобы найти IP-адрес, введите:
Это показывает IP-адрес всех сетевых устройств на этой виртуальной машине. Добавьте тот, который подключается к вашей локальной сети. Если вы не можете определить, какой IP-адрес использовать, скопируйте и вставьте его в свой браузер. Если он подключается, у вас есть правильный IP-адрес.
Возьмите IP-адрес и добавьте его в файл хостов вашего компьютера (а не файл хостов VM). Файл hosts на Mac находится по адресу etc/hosts :
Затем добавьте следующую строку:
Если это будет возможно, вы сможете перейти на http://demo.dev в своем браузере. Находясь на вашем Mac, создайте папку и инициализируйте репозиторий GIT:
Если все пойдет хорошо, вы должны увидеть ответ от наших хуков GIT. Переход к http://demo.dev должен привести к появлению сообщения «Hello World» в вашем браузере.
Вывод
Таким образом, вы можете создать промежуточное окружение, которое имитирует функциональность типичного PAAS. Если у вас возникли проблемы с этим, или вам нужно настроить несколько промежуточных сред, я создал сценарий, который полностью автоматизирует процесс. Для получения дополнительной информации вы можете посетить stagr.gmanricks.com.
Надеюсь, вам понравилась статья. Не стесняйтесь задавать любые вопросы, которые могут возникнуть в комментариях. Спасибо за чтение.
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 в скриптах развертывания — это способствует их единообразию.