Jenkins Scripting Pipeline — генерация стадий выполнения
Всем привет! В интернете довольно много статей, связанных с Declarative Jenkins pipeline, и совсем немного о Jenkins Scripting Pipeline, хотелось бы восполнить этот пробел.
В 2008 году Jenkins был ответвлен от проекта Hudson, принадлежащего компании Oracle, и стал самостоятельным продуктом с открытым кодом. В начале, как и его предок, Jenkins поддерживал только последовательное выполнение шелл скриптов (Windows cmd/linux bash). Многие проекты до сих пор с успехом пользуются классическим вариантом интерфейса для обеспечения процесса непрерывной интеграции и развертывания. Первым значительным улучшением стал переход на использование так называемого Jenkins Pipeline. В качестве языка для написания Jenkins Pipeline скрипта был выбран Groovy в связи с тем, что весь остальной код Jenkins написан на Java, а Groovy и Java тесно взаимосвязаны. К сожалению, переход к использованию Jenkins Pipeline сильно усложнил процесс непрерывной интеграции и развертывания, так как требовал дополнительных навыков в написании Groovy скриптов, а также характеризовался сложным процессом отладки этого скрипта. В результате был разработан Jenkins plugin Blue Ocean и редактор Jenkins Pipeline. Но это была немного другая версия Jenkins Pipeline, которая получила название Jenkins Declarative Pipeline. Это был тоже своего рода прорыв, так как позволял людям без особых навыков программирования Groovy описывать довольно сложные процессы интеграции и развертывания.
В нашем проекте мы используем Jenkins для запуска интеграционных (E2E) тестов, которые проверяют функционал системы в целом.
К использованию Jenkins Scripting Pipeline мы пришли не сразу. В начале мы использовали классический Jenkins CI, но довольно быстро перешли на Jenkins Declarative Pipeline, так как выяснилось, что мы не можем запускать тесты одним куском, а должны исполнять их несколькими группами с немного различающимися параметрами запуска. Использование Jenkins Pipeline так же позволило нам запускать параллельно различные группы тестов, что также ускорило общее время выполнения. По мере разрастания функционала и тестов время выполнения полного пакета тестов стало увеличиваться и достигло на пике 40-50 минут. Кроме того, стало понятно, что имеющиеся UI-mock тесты часто не позволяют отловить ошибку, что приводит к потере времени на анализ ошибки в релизной версии. В результате было решено, что помимо UI-mock тестов мы должны выполнять интеграционные тесты прежде, чем осуществить процесс слияния поднятого PR в релизную ветку. Было решено перевести проект на Multibranch Pipeline. За счет распараллеливания тестов удалось сократить время выполнения до 30-35 минут. Мы выделили специальную фазу с небольшим количеством тестов, которые выполнялись за 10 минут. Эта фаза стала использоваться для выполнения тестов на ветке кода перед процессом слияния с релизной веткой.
В результате перед нашей командой были поставлены две задачи, связанные с уменьшением общего времени прогона тестов и времени прогона тестов перед процессом слияния. Для этого мы решили действовать в двух направлениях:
Для решения второй задачи пришлось перейти на использование Jenkins Scripting Pipeline по следующим причинам:
Для решения второй причины мне показалось удобным осуществлять генерацию выполнения тестов в зависимости от конфигурации, прописанной в Jenkins Pipeline файле.
Информацией о том, что вышло в итоге и хочется поделиться, так как в процессе написания Jenkins-pipeline скрипта выяснилось, что в интернете достаточно информации про Declarative Jenkins Pipeline и довольно мало по Jenkins Scripting Pipeline.
Структура тестов
Прежде чем перейти к описанию получившегося Jenkins-pipeline скрипта, необходимо рассказать о структуре и запуске тестов, чтобы дать представление о том, почему стало возможным сделать генерацию выполнения групп тестов.
Все тесты разделены на группы исходя из функционала, который они тестируют, в свою очередь, группа может быть разделена на подгруппы.
Запуск тестов осуществляется командой:
Дополнительные параметры исполнения регулируются установкой переменных окружения. Одним из параметров окружения является PATH_TO_TESTS, в которую вносится путь до тестов относительно папки server-tests. То есть, например, если PATH_TO_TESTS=’stage1’, то выполняются все тесты из папки ‘stage1’, включая все тесты из поддиректорий: ‘sub-stage-11’ и ‘sub-stage-12’. А если PATH_TO_TESTS=’stage1/sub-stage-11’, то тесты только из этой папки.
Именно благодаря такой структуре тестов удалось создать Jenkins-pipeline файл, который в процессе исполнения создает фазы исполнения исходя из конфигурации этих этапов.
Конфигурация этапов выполнения
В качестве групп тестов использовали названия собранных по функционалу директорий, например, ‘stage1’. Для начала было решено выделить 3 больших пакета: Smoke Pack, Main Pack и Special Pack, в которые распределены имеющиеся группы тестов.
В результате выполнения должно было получиться следующее:
Выяснилось, что группа тестов в свою очередь может состоять из некоторых подгрупп, которые могут выполняться либо параллельно, либо последовательно. Для конфигурирования выполнения я стал использовать три map-коллекции:
Основная перегруппировка происходит в первой коллекции. Именно в ней я переставляю группы тестов по пакетам или переношу в новые группы.
Генерация этапов выполнения
Из-за особенностей Jenkins Scripting Pipeline пришлось выделить 2 обязательных этапа:
Наконец, пишем основной скрипт генерации этапов выполнения.
Существует возможность запуска необходимых тестов вручную (пакетами, отдельными группами тестов), поэтому в переменной окружения STAGES_TO_BE_EXECUTED находится список запускаемых пакетов/групп тестов. По умолчанию он установлен в “Smoke Pack”, таким образом, если запуск происходит в результате изменения ветки кода (commit), то выполняются тесты, входящие в пакет “Smoke Pack”.
Алгоритм генерации довольно простой:
Для каждого пакета из jobPacks:
Выглядит это следующим образом:
Алгоритм функции создания списка групп выполнения:
Алгоритм функции генерации фазы выполнения (stage) в Jenkins:
Шаги выполнения тестов одинаковые, благодаря чему получилось создать данный генератор:
В stageEnv устанавливаются дополнительные переменные окружения, с которыми должна выполнятся та или иная группа тестов. В основном это установка роли пользователя, от которого эти тесты выполняются, а также относительный путь к тестам из этой группы на основании имени фазы выполнения. Для этого в generateStage и в generateExecuteStagesList создавались имена с “/” типа “Stage5/sub stage 51”.
Итоги и выводы
Удалось сократить размер Jenkinsfile в 2 раза за счет удаления повторяющегося кода, который был написан в Declarative Jenkins pipeline.
Стало удобнее перемещать группы тестов между пакетами выполнения. Появилась возможность легко разделить группу тестов на несколько подгрупп с последующим параллельным выполнением.
Грамотно подобранная конфигурация позволила сократить время выполнения полного пакета тестов примерно в 2 раза (с 25-30 минут до 13-16 минут).
Smoke пакет при этом выполняется от 2 до 5 минут (около половины тестов):
Настройка 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.
Надеюсь, вам понравилась статья. Не стесняйтесь задавать любые вопросы, которые могут возникнуть в комментариях. Спасибо за чтение.
Окружения развёртывания программного обеспечения
Только что опубликовал в русской википедии перевод статьи Deployment environment.
Публикую этот перевод здесь также. Замечания и комментарии приветствуются.
В развёртывании программного обеспечения, окружение или ярус является компьютерной системой в которой компьютерная программа или компонент программного обеспечения развёртывается и выполняется. В простом случае, такое развёртывание и немедленное выполнение программы на той же машине, может выполнятся в единственном окружении, однако при промышленной разработке используется разделение на development окружение (‘окружение разрабочика’) (где делаются исходные изменения) и production окружение (которое используют конечные пользователи); часто с промежуточными этапами (‘stages’) посередине. Этот структурированный процесс управления релизами может иметь фазы deployment (rollout, ‘развёртывание’, ‘выкатка’), testing (‘тестирование’), и rollback (‘откат’) в случае проблем.
Окружения могут существенно отличаться в размерах: deployment окружение это обычно рабочая станция отдельного разработчика, в то время как production окружение может быть сетью множества географически разнесённых машин в случае с дата-центров, или виртуальными машинами в случае с облачными решениями. Код, данные и конфигурация могут быть развёрнуты паралельно, и нет необходимости связи с соответствующим ярусом — например, pre-production код может подсоединяться к production БД.
Архитектуры
Архитектуры развёртывания существенно разнятся, но в целом, ярусы начинаются с develpment (DEV) и заканчиваются production (PROD). Распространённой 4-х ярусной архитектурой является каскад ярусов deployment, testing, model, production (DEV, TEST, MODL, PROD) c деплоем софта на каждом ярусе по очереди. Другое распространённое окружение это Quality Control (QC), для приёмочного тестирования; песочница или экспериментальное окружение (EXP), для экспериментов не предназначенных для передачи в продакшен; и Disaster Recovery (‘аварийное восстановление’), для предоставления возможности немедленного отката в случае проблемы с продакшеном. Другой распространённой архитектурой является deployment, testing, acceptance and production (DTAP).
Такая разбивка в частности подходит для серверных программ, когда сервера работают в удаленных дата-центрах; для кода который работает на конечных устройствах пользователя, например приложений (apps) или клиентов, последний ярус обозначают как окружение пользователя (USER) или локальное окружение (LOCAL).
Точные определения и границы между окружениями варьируется — test может рассматриваться как часть dev, приёмка может рассматриваться как часть test, часть stage, или быть отдельной и так далее. Основные ярусы обрабатываются в определённом порядке, с новыми релизами при развёртывании (rolled out или pushed) на каждом. Ярусы experimental и recovery, если представлены, являются внешними к этому процессу — experimental релизы являются конечными, в то время как recovery являются обычно старыми или дублирующими версиями production, развёрнутыми после production. В случае проблем, в последнем случае можно сделать roll back к старому релизу, и большинство просто выкатывают старый релиз таким же способом как новый. Последний шаг, деплой в production («pushing to prod») самый чувствительный, т.к. здесь любые проблемы напрямую влияют на пользователя. По этой причине это часто управляется по разному, но как минимум мониторится более тщательно, и в некоторых случаях имеется фаза отката или простого переключения. Лучше всего избегать названия вроде Quality Assurance (QA); QA не означает тестирование софта. Тестирование важно, но это отличается от QA.
Иногда развёртывание выполняется вне обычного процесса, главным образом для предоставления срочных или небольших изменений, без необходимости полного релиза. Это может быть один патч, большой service pack или небольшой hotfix.
Окружения могут быть очень разных размеров: разработка обычно идёт на индивидуальных машинах разработчиков (хотя это могут быть тысячи разработчиков), в то время как продакшеном могут быть тысячи географически распределённых машин; тестирование и QC может быть маленьгим и большим, зависеть от предоставленных ресурсов, а staging может варьироваться от единичной машины (подобно canary) до точных дубликатов продакшена.
Окружения
Local
Development/Thunk
Сервер разработки выступающий как песочница где разработчик может выполнить unit-тестирование
Integration
Основа для построения CI, или для тестирования сайд-эффектов разработчиком
Testing/Test/QC/Internal Acceptance
Окружение в котором выполняется тестирование интерфейса. Команда контроля качества проверяет что новый код не будет иметь влияния на существующую функциональность системы после деплоя нового кода в тестовое окружение.
Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo
Production/Live
Серверы конечных пользователей/клиентов
Окружение разработчика
Окружение разработчика (dev) является окружением в котором софт разрабатывается, это часто просто компьютер разработчика. Это отличается от конечной целевой среды некоторыми вещами — цель может не быть стационарным компьютером (это может быть смартфон, встроенная система, самоуправляемый транспорт датацентра и т.д.), и даже если это стационарный компьютер, окружение разработчика будет включать инструменты разработчика например компилятор, IDE, различные или дополнительные версии библиотек и вспомогательного софта, и т.д., что не представлено в пользовательском окружении.
В контексте управления ревизиями, особенно при участии множества разработчиков, проводятся более тонкие различия: разработчик имеет рабочую копию исходного текста на своей машине, и изменения вносятся в репозиторий, будучи закомиченными либо в «стволе», либо в ветке, в зависимости от методологии разработки. Окружение на отдельной рабочей станции, на которой изменения отработаны и опробованы, может называться локальным окружением или песочницей. Сборка копии исходного кода репозитория в чистом окружении является отдельным этапом интеграции (интеграция разрозненных изменений), и это окружение может называться интеграционным окружением или окружением разработчика; при непрерывной интеграции это делается часто, так же часто, как и для каждой ревизии. Понятие уровня исходного кода звучащее как «фиксация (коммит) изменения в репозитории» с последующей сборкой «ствола» или ветки — соответствует переходу от локального (индивидуального окружения разработчика) к интеграции (чистой сборке); плохой релиз на этом этапе означает, что изменение сломало сборку, а откат релиза соответствует либо откату всех сделанных изменений, либо отмене только ломающего изменения, если это возможно.
Тестовое окружение
Цель тестового окружения состоит в том, чтобы позволить людям, проводящим тестирование, пропускать новый и измененный код либо через автоматизированные проверки, либо через неавтоматизированные методы. После того, как разработчик пропускает новый код и конфигурации через модульное тестирование в среде разработки, код переносится в одну или несколько тестовых сред. После неудачи теста тестовая среда может удалить ошибочный код из тестовых платформ, связаться с ответственным разработчиком и предоставить детальные журналы тестирования и результаты. Если все тесты пройдут, тестовая среда или фреймворк непрерывной интеграции, контролирующий тесты, может автоматически перенести код в следующую среду развертывания.
Различные типы тестирования предполагают различные типы тестовых сред, некоторые или все из которых могут быть виртуализированы для обеспечения быстрого параллельного тестирования. Например, автоматизированные тесты пользовательского интерфейса могут выполняться на нескольких виртуальных операционных системах и дисплеях (реальных или виртуальных). Для проведения тестов производительности может потребоваться нормализованная базовая конфигурация аппаратного обеспечения, чтобы результаты тестов производительности можно было сравнивать с течением времени. Тестирование на доступность или устойчивость может основываться на симуляторах отказов в виртуальных аппаратных средствах и виртуальных сетях.
Тесты могут быть последовательными (один за другим) или параллельными (для некоторых или всех сразу), в зависимости от сложности тестовой среды. Важной целью agile и других высокопроизводительных практик разработки программного обеспечения является сокращение времени от разработки или предоставления программного обеспечения до его поставки в продакшен. Высокоавтоматизированные и распараллеленные тестовые среды вносят важный вклад в быструю разработку программного обеспечения.
Staging
Stage или stage-окружение — это среда для тестирования, которая в точности похожа на продакшен-окружение. Она стремится как можно точнее отразить реальное продакшен-окружение и может подключаться к другим продакшен-сервисам и данным, таким как базы данных. Например, серверы будут работать на удаленных машинах, а не локально (как на рабочей станции разработчика во время разработки, или на одной тестовой машине во время тестирования), чтобы проверить влияние сети на систему.
Основное назначение stage-окружения заключается в тестировании всех сценариев установки/конфигурации/перемещения скриптов и процедур, прежде чем они будут применены в продакшен-окружении. Это гарантирует, что все существенные и незначительные обновления продакшен-окружения будут завершены качественно, без ошибок и в минимальные сроки.
Другим важным использованием stage-окружения является тестирование производительности, в частности нагрузочное тестирование, так как это часто чувствительно для окружения.
Stage-окружение также используется некоторыми организациями для предварительного просмотра новых функций и их отбора заказчиками или для утверждения интеграции с работающими версиями внешних зависимостей.
Продакшен-окружение
Продакшен-окружение также известно как live (в частности в применении к серверам) так как это окружение, с которым непосредственно взаимодействуют пользователи.
Развертывание в производственной среде является наиболее чувствительным шагом; это может осуществляться путем непосредственного развертывания нового кода (перезаписывания старого кода, так что только одна копия представлена в один момент времени), или путем развертывания изменения конфигурации. Это может принимать различные формы: параллельное развертывание новой версии кода и переключение на неё с изменением конфигурации; развертывание новой версии кода рядом со старым с соответствующим «флагом нового функционала», и последующее переключение на новую версию с изменением конфигурации, которая выполнит переключение этого «флага»; или развертывание отдельных серверов (один выполняет старый код, другой — новый) с перенаправлением трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Всё это, в свою очередь, может быть применено одновременно или выборочно, и на разных этапах.
Развертывание новой версии обычно требует перезапуска, если только нет возможности горячего переключения, и поэтому требует либо прерывания обслуживания (обычно это пользовательское ПО, когда приложения должны быть перезагружены), либо дублирования — постепенного перезапуска экземпляров «за спиной» у балансировщика нагрузки, либо заблаговременного запуска новых серверов с последующим простым перенаправлением трафика на новые сервера.
При выкатке нового релиза в продакшен, вместо немедленного развертывания для всех экземпляров или пользователей, его можно сначала развернуть на одном экземпляре или для части пользователей, а затем уже либо развернуть для всех экземпляров, либо поэтапно по фазам, чтобы оперативно отлавливать возникающие проблемы. Это похоже на staging, за исключением того, что делается в продакшене, и по аналогии с добычей угля называется canary release. Это добавляет сложности если несколько релизов запускаются одновременно, и, поэтому их обычно стараются делать быстро, чтобы избежать проблем совместимости.