что такое развертывание приложения
Развертывание современных классических приложений
При разработке классических приложений необходимо учитывать, как ваше приложение будет упаковываться и развертываться на компьютерах пользователей. Проблема, связанная с упаковкой, развертыванием и установкой, заключается в том, что ими обычно занимаются исключительно ИТ-специалисты, которых волнуют совсем не те вещи, что и разработчиков.
Сегодня мы знакомы с концепцией DevOps, где разработчики и ИТ-специалисты тесно взаимодействуют друг с другом для переноса приложений в рабочие среды. Однако если вы занимаетесь разработкой классических приложений уже более 10 лет, то могли быть свидетелем следующей ситуации. Команда разработчиков усиленно трудится для соблюдения крайних сроков проекта. Руководители нервничают, так как для функционирования бизнеса им требуется система, работающая на множестве компьютеров пользователей. В день «Д» менеджер по проектам проверяет, правильно ли работает код каждого из разработчиков, чтобы можно было осуществлять доставку. Затем в работу включается команда упаковки, которая создает для приложения программу установки, распространяет ее на каждый компьютер пользователя, после чего группа тестовых пользователей запускает приложение. Ну, они пытаются, так как перед отображением пользовательского интерфейса приложение выдает исключение с сообщением «Сбой метода
«. В воздухе появляется напряженность, и небольшое исследование приводит к молодому и уставшему разработчику, который внес сторонний элемент управления, который определенно «работал на компьютере разработки».
Установка классических приложений всегда была настоящим кошмаром по двум основным причинам:
На самом деле нам приходилось мириться с тем фактом, что установка приложения могла вызвать только сожаление, так как:
Кроме того, вы не можете просто восстановить систему в исходное состояние путем удаления приложения. Мы постоянно сталкивались с подобной ситуацией, которую прозвали «DLL-путаницей», «захламлением» или «Winrot».
В этой главе мы поговорим о MSIX. MSIX — это новая технология от корпорации Майкрософт, которая стремится взять лучшее из предыдущих технологий, чтобы обеспечить надежную основу для технологии упаковки будущего.
Как технология упаковки связана с модернизацией? Оказалось, что упаковка является основополагающей для корпоративных ИТ-служб, и в нее вкладываются значительные средства. Модернизация не ограничивается использованием новейших технологий. Она также нацелена на сокращение времени выхода на рынок с момента определения бизнес-требования и до момента, когда ваша организация доставляет соответствующий компонент клиенту.
Жизненный цикл современного приложения
Сейчас разработчики пишут и собирают код для приложения, после чего передают созданные ресурсы ИТ-специалистам. После этого ИТ-специалисты перестраивают приложение и переупаковывают его, как правило, в формате MSI или более новом App-V. Затем приложение развертывают с помощью различных каналов и средств. Одна из основных проблем такого подхода обычно называется «коллапсом упаковки». Проблема заключается в том, что этот цикл повторяется каждый раз при обновлении приложения или операционной системы.
Данный процесс проиллюстрирован на следующем рисунке:
Организациям требуется способ разбить этот цикл упаковки на три независимых цикла:
На предыдущей схеме показано, что вам доступны следующие возможности:
Это радикальное изменение приводит нас к новому и современному жизненному циклу ИТ, как показано на следующем рисунке:
Разработчики создают приложение и формируют пакет MSIX, который ИТ-специалисты могут использовать и настраивать без переупаковки. Вместе с технологией MSIX корпорация Майкрософт создала средства, позволяющие ИТ-специалистам настраивать пакеты без переупаковки.
MSIX: следующее поколение развертывания
До MSIX существовало несколько технологий упаковки, таких как мастера установки, MSI, ClickOnce, App-V и сценарии. Каждая из этих технологий имеет свои сильные стороны, и корпорация Майкрософт решила взять из них все лучшее для создания MSIX. Технология MSIX основана на этих существующих технологиях, вбирая в себя преимущества каждой из них:
Благодаря MSIX вы получаете одну технологию установщика со всеми этими функциями.
Преимущества gRPC
Установка приложений без сожалений
MSIX обеспечивает предсказуемое, надежное и безопасное развертывание. Декларативный метод, содержащийся в манифесте пакета, позволяет операционной системе отслеживать каждый из ресурсов, необходимых приложению. Он также обеспечивает действительно чистое удаление без побочных эффектов.
Оптимизация дискового пространства
Технология MSIX оптимизирована для уменьшения места, занимаемого приложением на диске компьютера пользователя. Она создает хранилище единственных копий ваших файлов. То есть если у вас есть два разных пакета с одной и той же библиотекой DLL, она не устанавливается дважды. Платформа может решить эту проблему, так как она знает обо всех файлах, установленных конкретным приложением, благодаря своей декларативной природе. Она также позволяет использовать разные версии библиотеки DLL, работающие параллельно.
С помощью пакетов ресурсов можно легко создавать многоязычные приложения, и операционная система позаботится об установке нужных из них.
Оптимизация сети
MSIX обнаруживает различия в файлах на уровне байтового блока, позволяя использовать функцию разностных обновлений. Это означает, что при обновлениях приложения скачиваются только обновленные байтовые блоки.
Благодаря потоковой установке пользователь может быстро начать работу над приложением, пока другие части приложения скачиваются в фоновом режиме. Эта функция влияет на вовлечение пользователей в работу.
С помощью дополнительных пакетов вы можете реализовать компонентное представление развертывания приложения, поэтому их можно скачивать по мере необходимости.
Простота упаковки и развертывания
Манифест приложения объявляет управление версиями, нацеливание устройств и обеспечивает идентификацию стандартным образом для каждого приложения. Он также позволяет подписывать активы, создавая надежную основу для системы безопасности.
Управляемая операционная система
Операционная система обрабатывает все процессы по установке, обновлению и удалению приложения. Приложения устанавливаются для отдельных пользователей, но скачиваются только один раз, что сводит к минимуму используемое дисковое пространство. Корпорация Майкрософт работает над предоставлением технологии MSIX также и в Windows 7.
Обеспечение целостности приложения в Windows
Цифровые подписи позволяют гарантированно предотвратить установку приложения из ненадежных источников. Кроме того, система MSIX предотвращает незаконное изменение, поскольку:
Поддержка всего каталога приложений
Одним из самых интересных аспектов технологии MSIX является то, что она работает для всего каталога приложений, Windows Forms, WPF, MFC/ATL, Delphi, даже если вы хотите выполнить развертывание xCopy, используете ClickOnce или переходите в Store, вы можете использовать один и тот же пакет MSIX.
Инструменты
Проект упаковки приложений Windows
Для создания пакета для классического приложения в Visual Studio можно использовать Проект упаковки приложений Windows. Затем можно опубликовать этот пакет в Microsoft Store или загрузить его в неопубликованном виде на один или несколько компьютеров.
Средство упаковки MSIX
Средство упаковки MSIX позволяет повторно упаковывать существующие пакеты приложений Win32 в формате MSIX. Оно включает интерактивный пользовательский интерфейс и командную строку для преобразования, позволяя преобразовывать приложения без использования исходного кода.
Платформа поддержки пакетов
Платформа поддержки пакетов представляет собой набор с открытым кодом, который помогает применять исправления к существующему приложению Win32, когда у вас нет доступа к исходному коду для работы в контейнере MSIX. Платформа поддержки пакетов помогает настроить приложения в соответствии с требованиями современных сред выполнения.
Установщик приложений
Установщик приложений позволяет устанавливать приложения Windows 10, дважды щелкнув пакет приложения. Это означает, что пользователям не нужно использовать PowerShell или другие средства разработчика для развертывания приложений Windows 10. Кроме того, Установщик приложений может устанавливать приложения из Интернета, дополнительных пакетов и связанных наборов.
Создание пакета MSIX из существующего классического приложения Win32
Давайте рассмотрим процесс создания пакета MSIX из существующего классического приложения Win32. В этом примере мы будем использовать приложение Windows Forms.
Чтобы начать, добавьте в решение новый проект, выберите «Проект упаковки приложений Windows» и присвойте ему имя.
Вы увидите структуру проекта упаковки и заметите специальную папку Applications. В ней можно указать приложения, которые требуется включить в пакет. Их может быть несколько.
Щелкните правой кнопкой мыши папку Applications и выберите проект Windows Forms, который хотите упаковать из решения Visual Studio.
На этом этапе вы можете скомпилировать и создать пакет, но давайте рассмотрим несколько аспектов. Чтобы улучшить взаимодействие с пользователем, Visual Studio может автоматически создавать все визуальные ресурсы, необходимые современным приложениям для работы со значками, а также ресурсы плиток для панели плиток и меню «Пуск». Откройте файл Package.appxmanifest для доступа к конструктору манифеста. После этого вы можете создать все визуальные ресурсы из заданного образа, присутствующего в проекте, просто нажав кнопку Создать.
Если открыть код для файла Package.appxmanifest, можно увидеть несколько интересных вещей.
Непосредственно под узлом
Задайте проект упаковки в качестве запускаемого проекта для решения и выберите Выполнить. Будут выполнены следующие операции:
Благодаря этому вы получаете чистую процедуру установки и удаления, которую MSIX полностью интегрирует в Windows 10.
Последним этапом является развертывание пакета MSIX на другом компьютере.
Щелкните проект упаковки правой кнопкой мыши, выберите меню Store и затем параметр Создание пакетов приложения.
После этого вы можете выбрать, будете ли вы создавать пакет для отправки в Store или создавать пакеты для загрузки неопубликованных приложений. В большинстве сценариев модернизации вы выберете Я хочу создать пакеты для загрузки неопубликованных приложений.
В этом случае можно выбрать различные архитектуры, на которые нужно ориентироваться, так как в один пакет MSIX можно включить любое число архитектур.
Последним шагом является объявление того, где вы хотите развернуть окончательные ресурсы установки.
Вы можете использовать веб-сервер из общего UNC-пути на файловых серверах предприятия. Обратите особое внимание на параметры, позволяющие указать способ обновления приложения. Обновления мы рассмотрим в следующем разделе.
Автоматические обновления в MSIX
В Microsoft Store есть отличный механизм обновления, использующий Центр обновления Windows. В большинстве корпоративных сценариев магазин Store для распространения классических приложений не используется. Поэтому вам нужен аналогичный способ настройки обновлений для приложения и отправки их пользователям.
Используя сочетание функций Windows 10 и пакетов MSIX, вы можете предоставить пользователям удобную процедуру обновления. Фактически пользователь может совершенно не разбираться в технических аспектах, но при этом пользоваться преимуществами беспрепятственного обновления приложения.
Вы можете настроить обновление для взаимодействия с пользователем двумя разными способами:
Обновления, запрошенные пользователем: операционная система отображает автоматически сформированный удобный пользовательский интерфейс для уведомления пользователя о том, что приложение готово к установке. Этот пользовательский интерфейс создается на основе свойств, указанных вами в файлах установки.
Автоматические обновления в фоновом режиме: в этом случае пользователям не нужно знать об обновлениях.
Вы также можете настроить время выполнения обновлений — при запуске приложения или на регулярной основе. Благодаря функциям загрузки неопубликованных приложений эти обновления можно получать даже во время работы приложения.
При использовании этого типа развертывания создается специальный файл APPINSTALLER. Этот простой файл состоит из следующих разделов:
Совместно с этим файлом корпорация Майкрософт разработала специальный протокол URL-адресов для запуска процесса установки по ссылке:
Этот протокол работает во всех браузерах и запускает процесс установки в Windows 10 удобным для пользователя образом. Так как операционная система управляет процессом установки, она учитывает расположение, из которого было установлено это приложение, и отслеживает все файлы, затронутые этим процессом.
MSIX создает пользовательский интерфейс для автоматической установки, отображая некоторые свойства пакета. Это обеспечивает единый процесс установки для каждого приложения.
После создания пакета MSIX и его перемещения на сервер развертывания вам нужно просто изменить файл APPINSTALLER, чтобы отразить эти изменения, главным образом версию и путь нового файла MSIX. Когда пользователь запустит приложение в следующий раз, система обнаружит изменение и скачает файлы для новой версии в фоновом режиме. После этого установка при запуске приложения будет осуществляться незаметно для пользователя.
Быстрое развертывание любого приложения вместе с Waypoint
Упрощение развертывания
Waypoint был создан нами по одной простой причине: разработчики хотят просто развертывать приложения. У HashiCorp есть возможность работать со всеми типами организаций и отдельных лиц нашего сообщества, что ставит нас перед проблемами, с которыми сталкиваются разработчики при развертывании приложений и в разрезе доступности для пользователей. Мы общаемся с десятками отдельных пользователей каждый день через GitHub Issues, дискуссионные форумы, электронную почту и т.д. Каждую неделю мы встречаемся более чем с 500 компаниями, чтобы обсудить их текущие разработки и операционные проблемы.
Благодаря взаимодействию мы увидели, что разработчики, особенно в организациях среднего и крупного размера, завалены сложностью: контейнеры, планировщики, файлы YAML, бессерверность и не только это. Сложность сделала приложения лучше во многих аспектах, но стоимость, которую видно по кривой обучения, требуется, чтобы просто развернуть первое приложение.
Другая проблема, которую мы увидели, зависит от приложения, ведь инструменты часто самые разные: Docker и kubectl для Kubernetes, HashiCorp Packer и Terraform для виртуальных машин, свои инструменты у каждой бессерверной платформы и т.д. Эта фрагментация снова создает проблему обучения отдельного человека. Для команд это уже проблемы последовательности и сложности.
С помощью Waypoint мы стремимся решить эти две проблемы. Waypoint предоставляет одну простую команду для развертывания любого приложения: «waypoint up». Рабочий процесс одинаков для любой платформы: Kubernetes, Nomad, EC2, Google Cloud Run и еще более десятка других будет поддерживаться к моменту запуска. Waypoint расширяется с помощью плагинов для любой логики сборки, развертывания и релиза. Разработчики просто хотят развертывать приложения. Waypoint просто делает это.
Функциональность
Waypoint предлагает ряд функций, предоставляющих рабочий процесс развертывания приложений, а также проверки и отладки развертывания. Эти функции делают Waypoint мощным инструментом для развертывания любых приложений на любой платформе.
Пример рабочего процесса
Покажем на примере различные особенности Waypoint. Пропущены некоторые шаги настройки, поэтому, если вы хотите попробовать полный пример самостоятельно, пожалуйста, ознакомьтесь с нашими руководствами по началу работы. В этом примере мы развернем приложение в Kubernetes. Создадим рядом с приложением файл waypoint.hcl. Этот файл описывает все этапы жизненного цикла приложения.
Сборка, развертывание, релиз
Файл конфигурации Waypoint описывает три основных этапа жизненного цикла приложения: сборку, развертывание и релиз.
Поднимаем Waypoint
Команда waypoint up выполняет сборку, развертывание и релиз приложения. В конце выводится один или несколько адресов, по которым доступно приложение. Неважно, какое это приложение и для какой платформы, вы всегда можете ввести в терминал waypoint up для развертывания.
Можно выполнять этапы жизненного цикла отдельно друг от друга. Это полезно при взаимодействии с Github Actions и инструментами CI/CD, подобными CricleCI и Jenkins. Узнать больше об автоматизации рабочего процесса приложения с помощью Waypoint можно здесь.
Адреса приложения и развертывания
Развернутые с помощью Waypoint приложения получают общедоступный URL вида waypoint.run с действительным сертификатом TLS, автоматически сгенерированным Let’s Encrypt. Используйте этот адрес, чтобы быстро посмотреть развернутые приложения и поделиться ими. Мы предоставляем этот URL через бесплатный общедоступный сервис компании HashiCorp. Функция необязательна и может быть отключена. В примере выше наш URL recently-pleasant-duck—v1.waypoint.run. Обратите внимание, что этот адрес уже не работает, приложение выполнялось только для этого поста в блоге. Вы можете посмотреть определенную версию развертывания по ссылке вида recently-pleasant-duck—vN.waypoint.run, где N — номер версии развертывания. Эта функция очень полезна, чтобы поделиться предрелизной версией вашего приложения с вашей командой.
Логирование в Waypoint
Waypoint дает доступ к моментальному снимку логов приложения в режиме реального времени. Эти логи полезны, когда нужно отладить поведение развивающегося приложения. Однако они не заменяют комплексные решения для логирования. Логи агрегируются и доступны для просмотра через интерфейс командной строки и веб-интерфейс. Эта функция логов работает вне зависимости от платформы. Используете ли вы Kubernetes, EC2, Google Cloud Run или другую платформу, вы можете согласовано просматривать логи. С помощью пользовательского интерфейса можно просматривать логи нескольких развернутых на разных платформах приложений.
Waypoint exec
Вы можете выполнять команды в контексте развернутого приложения с помощью команды waypoint exec. Эта функция позволяет открывать оболочку, запускать скрипты и делать все, что вы хотите делать с вашими развертываниями. Как и логирование, waypoint exec работает на всех поддерживаемых Waypoint платформах.
Другие возможности
Этот список — только краткий обзор некоторых функций Waypoint. Waypoint может применяться для управления конфигурацией приложения через переменные окружения, интегрируется с вашей CI или Github. Рабочие пространства при меняются, чтобы создавать отдельные среды для отдельных веток. Кроме того, вы можете написать плагин и это еще не всё.Waypoint — это бренд нового проекта. Мы рассчитываем, что продолжим добавлять новую функциональность в ближайшие месяцы.
Waypoint и существующие приложения
Если у вас уже есть приложение и рабочий процесс развертывания, вы можете почувствовать сомнение в том, сможете ли использовать…. Мы не ждем, что команды разработки немедленно перестроят и с нуля перестроят свой рабочий процесс для Waypoint. Но у нас есть плагин docker pull и возможность локального выполнения, позволяющая адаптировать Waypoint для приложения с уже настроенным рабочим процессом. Кроме того, у нас есть документация, которая описывает интеграцию Waypoint в другие CI: CircleCI или Jenkins. Эта функция позволяет просмотреть историю развертывания в интерфейсе Waypoint, выполнять команду exec, логирование, конфигурацию приложения и не только это. Приложив немного усилий, вы получаете преимущества Waypoint, пока обдумываете, хотите ли перейти на более управляемый плагин. Когда у вас много приложений, этот подход позволяет сочетать рабочие процессы и сравнивать их.
Полная расширяемость плагинами
Логика жизненного цикла полностью расширяемая. Waypoint работает на той же системе плагинов, что и Terraform. мы полагаем, что написать плагин для Waypoint так же просто (если не проще), чем для Terraform. В Waypoint встроено более десятка плагинов с самого начала. Мы надеемся и ожидаем, что со временем, с помощью сообщества открытого ПО, это число резко возрастет. У Terraform при запуске было около 6 провайдеров. Сегодня у Terraform 300 провайдеров. Мы верим, что такое возможно и для развертывания приложений. Если вам интересно написать плагин, пожалуйста, прочитайте наше руководство для авторов плагинов и посмотрите исходный код встроенных плагинов Waypoint 0.1 на Github.
Специально для хабровчан мы сделали промокод HABR, дающий дополнительную скидку 10% к скидке указанной на баннере.
Что такое развертывание приложения
В данной статье речь пойдет об истории успеха воображаемого новостного портала, счастливым владельцем которого являетесь вы. К счастью, вы уже храните код проекта на 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 в скриптах развертывания — это способствует их единообразию.