production сервер что это
production server
Смотреть что такое «production server» в других словарях:
Server-side scripting — is a web server technology in which a user s request is fulfilled by running a script directly on the web server to generate dynamic HTML pages. It is usually used to provide interactive web sites, that interface to databases or other data stores … Wikipedia
Server (computing) — For other uses, see Server (disambiguation). Servers in a data center. Several servers are mounted on a rack and connected to a display … Wikipedia
Microsoft SQL Server — Developer(s) Microsoft Stable release SQL Server 2008 R2 (10.50.2500.0 Service Pack 1) / July 11, 2011; 4 months ago … Wikipedia
Windows Small Business Server — Developer(s) Microsoft Stable release 2011 / December 13, 2010 Type Application server License Microsoft EULA … Wikipedia
IBM WebSphere Application Server — (WAS), a software application server, is the flagship product within IBM s WebSphere brand. WAS is built using open standards such as Java EE, XML, and Web Services. It works with a number of Web servers including Apache HTTP Server, Netscape… … Wikipedia
VMware Server — VMware VMware, Inc. Siège de VMware, Inc. à Palo A … Wikipédia en Français
Mac OS X Server — Screenshot of Snow Leopard Server Company / developer … Wikipedia
Microsoft Exchange Server — Developer(s) Microsoft Corporation Initial release June 11, 1996 (1996 06 11) Stable release Microsoft Exchange Server 2010 SP1[1] / A … Wikipedia
Microsoft SQL Server — SQL Server Développeur Microsoft Dernière version 2008 ( … Wikipédia en Français
Microsoft Site Server — Microsoft Site Server, first released in 1996, was Microsoft s solution to the growing difficulty of managing complex websites which included multiple technologies, such as user management and authentication/authorization, content management,… … Wikipedia
Microsoft Exchange Server — est un Groupware (logiciel de groupe de travail) pour serveur de messagerie électronique créé par Microsoft, pour concurrencer Lotus Domino d IBM. Microsoft Exchange est très utilisé dans les entreprises. Selon Nicolas Petit (Directeur de la… … Wikipédia en Français
Да мой старый laptop в несколько раз мощнее, чем ваш production server
Именно такие претензии я услышал от наших девелоперов. Самое интересное, что это оказалось правдой, дав начало длительному расследованию. Речь пойдет про SQL servers, которые крутятся у нас на VMware.
Собственно, добиться того, чтобы production server безнадежно отстал от лаптопа легко. Выполните (не на tempdb и не на базе с включенной Delayed Durability) код:
На моем десктопе он выполняется 5 секунд, а на production server — 28 секунд. Потому что SQL должен ожидать физического окончания записи в transaction log, а мы тут делаем очень короткие транзакции. Грубо говоря, мы загнали большой мощный грузовик в городской траффик, и наблюдаем, как его лихо обгоняют доставщики пиццы на скутерах — тут не важен throughput, важна лишь latency. А ни один network storage, сколько бы нулей ни было в его цене, не сможет выиграть по latency у локального SSD.
(в комментах выяснилось что я соврал — у меня в обоих местах затесался delayed durability. Без delayed durability получается:
Desktop — 39 секунд, 15K tr/sec, 0.065ms /io roundtrip
PROD — 360 секунд, 1600 tr/sec, 0.6ms
Я должен был обратить внимание, что уж слишком быстро)
Однако в данном случае мы имеем дело с тривиальными нулями зэта функции Римана с тривиальным примером. В том примере, который мне принесли девелоперы, было другое. Я убедился, что они правы, и стал вычищать из примера всю их специфику, связанную с бизнес логикой. В какой-то момент я понял, что могу полностью выбросить их код, и написать свой — который демонстрирует ту же проблему — на production он выполняется в 3-4 раза медленнее:
Если у вас все хорошо, то проверка простоты числа будет выполняться 6-7-8 секунд. Так и было на ряде серверов. Но вот на некоторых проверка занимала 25-40 секунд. Что интересно, не было серверов, где выполнение занимало бы, скажем, 14 секунд — код работал либо очень быстро, либо совсем медленно, то есть проблема была, скажем так, черно белой.
Что я сделал? Полез в метрики VMware. Там было все хорошо — реcурсов было в избытке, Ready time = 0, всего хватает, во время теста и на быстрых, и на медленных серверах CPU=100 на одном vCPU. Я взял тест по расчету числа Pi — тест показывал одинаковые результаты на любых серверах. Все сильнее пахло черной магией.
Выбравшись на DEV ферму, я стал играться серверами. Выяснилось, что vMotion с хоста на хост может «вылечить» сервер, но может и наоборот, «быстрый» сервер превратить в «медленный». Кажется вот оно — какие то хосты имеют проблему… но… нет. Какая-то виртуалка тормозила на хосте, допустим, A но работала быстро на хосте B. А другая виртуалка наоборот, работала быстро на A и тормозила на B! На хосте часто крутились и «быстрые» и «медленные» машинки!
С этого момента в воздухе отчетливо запахло серой. Ведь проблема не могла быть приписана ни виртуалке (windows patches, например) — ведь она превращалась в «быструю» при vMotion. Но проблема также не могла быть приписана хосту — ведь на нем могли быть как «быстрые», так и «медленные» машинки. Также это не было связано с нагрузкой — мне удалось получить «медленную» машинку на хосте, где кроме нее вообще не было ничего.
От отчаяния я запустил Process Explorer от Sysinternals и посмотрел стек SQL. На медленных машинках мне сразу бросилась в глаза строка:
Рубин на рельсах: продакшен и деплой для чайников
Год назад я довел свое первое рельсовое приложение до приемлемого вида. Вопрос использования готового кода в продакшене ранее меня не заинтересовал. С чего вдруг? Несложный язык, лаконичный фреймворк — уж деплой-то явно не сложнее, чем преодоление ментального тормоза после PHP.
Команда разработчиков Rails рекомендует использовать Phusion Passenger, он что-то вроде mod_php — установил, разместил файлы и полетел. На момент изучения вопроса на форумах хватало баталий о производительности решений; Passenger в них фаворитом не значился.
Совета относительно альтернативы я спросил у техдиректора сайта с миллионом уников в сутки — тот отправил меня гуглить на тему Nginx и Unicorn. Инструкция по настройке продакшена, найденная на Хабре, датировалась 2009 годом. Помимо прочего, ее просто переполняли изъяны уроков «Как нарисовать сову».
Отдельные составляющие процесса кое-где разжеваны по-английский, но монолитный tutorial на глаза так и не попался. В традициях рельсового сообщества лежит принцип, предписывающий делиться результатами и опытом решения проблем.
Опытным рельсоводам текст вряд ли покажется интересным, но если таковые найдут время на замечания — буду признателен и внесу необходимые правки.
— О чем пойдет речь?
— Эта инструкция поможет новичкам подобрать и настроить хостинг, а также подготовить имеющийся проект для первоначального деплоя и систематической выкатки обновлений.
— А подробнее?
— Мы будем использовать Ubuntu 14.04, RVM, Nginx, Unicorn и Capistrano. Текст состоит из двух глав: подготовки проекта и настройки сервера. Все локальные манипуляции описываются в Mac OS X. Для выполнения процедур не будет лишней современная IDE вроде RubyMine, если нет — сойдет и TextMate. Все описываемые действия зафиксированы в специальном репозитории.
Глава первая Хостинг
Выбор хостинга
Сладкая парочка Nginx и Unicorn имеет весьма внушительный аппетит на оперативную память, а сами рельсы требуют установки ряда дополнительного ПО. Эти ограничения явно говорят о необходимости VPS. Есть вариант использовать специализированный хостинг вроде Heroku, но для новичков будет полезным процесс настройки проделать руками.
В рамках этого текста я буду использовать свежесозданный дроплет Digital Ocean на базе Ubuntu 14.04. (Промо-кодов на месяц—два бесплатного пользования в интернете хватает, кому нужна рефералка с десятью долларами на счете — дам ссылку.)
Обновление системных пакетов
Заходим в систему под рутом и обновляем пакеты:
Установка Git и NodeJS
Создание пользователя
Отмена запроса пароля для sudo
Для некоторых процедур деплоя потребуются привилегии суперпользователя. Чтобы команды исполнялись с помощью Capistrano и не вызывали ошибок, необходимо отключить запрос пароля. Отредактируйте файл sudoers : sudo nano /etc/sudoers.
Официальная документация Capistrano поясняет, что нативные фазы деплоя не требуют sudo; однако, если речь заходит об автоматизации всех процессов, без passwordless sudo не обойтись.
Генерация SSH-ключей
Потребуются две пары ключей. С помощью одной из них вы (и Capistrano) будете проходить авторизацию на сервере с локального компьютера. Второй парой вы предоставите серверу доступ в репозиторий (так называемый ключ развертывания). Кодовые фразы в обоих случаях оставьте пустыми.
Первая пара (необходимо генерировать локально):
Если вы знакомы с процедурой генерации и использования ключей, то путь к файлу и стойкость выбирайте по своему вкусу; иначе — оставьте по умолчанию.
Теперь необходимо скопировать содержимое публичного ключа (по умолчанию
/.ssh/id_rsa.pub на локальном компьютере) и добавить его в файл
/.ssh/authorized_keys на сервере. После этой нехитрой манипуляции с помощью SSH вы сможете подключиться к серверу без пароля. Если нет — проверьте права на сервере: 700 для
Вторая пара (на сервере):
Аналогичным образом содержимое из серверного
/.ssh/id_rsa.pub нужно добавить в список ключей развертывания (в Гитхабе их можно найти в настройках каждого репозитория).
Установка свежего Nginx
Версия Nginx, доступная в Ubuntu, зачастую более старая, нежели в официальном репозитории разработчика. Я стараюсь использовать свежую версию, но если вы других взглядов — установите Nginx самостоятельно и пропустите эту часть.
Мы добавим официальные репозитории Ubuntu в системный список sudo nano /etc/apt/sources.list. В конец файла добавим строки:
Помните, что использованные параметры актуальны только для Ubuntu 14.04. Информацию по установке на другие версии ОС ищите на сайте разработчика. Для установки Nginx из указанных репозиториев потребуется также загрузить и добавить в систему ключ:
Теперь можно обновить список доступных пакетов и установить Nginx:
Установка RVM
В случае с чистым сервером понадобится установить также некоторые зависимости:
Осталось установить непосредственно Ruby необходимой вашему приложению версии. К примеру, новую стабильную версию 2.1.3:
Установка компонентов приложения
Глава вторая Подготовка приложения
Использование Git
Что такое Capistrano
Официальное определение Capistrano звучит так: «A remote server automation and deployment tool». С точки зрения пользователя, Capistrano — штука, которая позволит выполнить произвольный набор команд на удаленном сервере через SSH. Существует и другие инструменты для деплоя (например, Mina), но пока Capistrano также некий стандарт, тем более, что позволяет выполнять параллельный деплой приложения сразу на ряд серверов, в том числе разделенных по ролям.
Принцип работы Capistrano
Когда вы (со своего локального компьютера) отдаете команду Capistrano выполнить деплой, устанавливается SSH-соединение с сервером и начинается выполнение нехитрого алгоритма. Для начала Capistrano сверяется с удаленным репозиторием и получает недостающие коммиты. После создается новый релиз (в директории releases ). Туда перекладывается актуальная версия кода и там же выполняется ряд тестов.
Организация файлов конфигураций
Каждый релиз для Capistrano — самостоятельная сущность. При очередном деплое происходит ее полная замена, поэтому ряд файлов необходимо хранить за пределами структуры приложения (как правило, загружаемый пользователями и генерируемый приложением контент, а также ряд конфигов).
Конфигурация Nginx
Мы используем наш VPS для единственного приложения, поэтому хост будет использоваться по умолчанию. (Не нужно же объяснять, что в иной ситуации придется явно указать server_name и позаботиться об уникальности имен апстримов?)
Конфигурация Unicorn
Подключение и настройка Capistrano
Необходимые гемы
В Gemfile нужно внести Capistrano и серию гемов, реализующих его связь с RVM, Bundler и Rails.
Обновление Capfile
Настройка продакшен-сервера
Откройте файл config/deploy/production.rb и внимательно посмотрите на его содержимое. Оно поможет вам разобраться в формате и возможностях настройки. В целом, если вы используете авторизацию с помощью SSH-ключа, никакой экзотики писать не придется; всего одна строчка:
Сценарий деплоя
Обязательные параметры
Прежде всего, требуется указать версию Capistrano, для которой предназначен данный сценарий:
Capistrano требует ряд обязательных параметров:
Установим также параметр log_level (дефолтное значение :debug делает Capistrano излишне разговорчивым):
Релизонезависимые данные
Учтите, что добавление в :linked_files указанных файлов ( config/secrets.yml и config/database.yml ) обязательно. В противном случае деплой завершится ошибкой по причине отсутствия подключения к базе данных.
Процедуры
Capistrano позволяет создавать наборы процедур, которые для удобства можно объединять в пространства имен. Неймспейс :deploy уже существует, его можно лишь дополнить; все включенные в него процедуры для сервера production можно вызвать командой cap production deploy
Сет-ап
Управление Nginx
Я отмечал выше, что Capistrano по сути — способ выполнить произвольные команды на удаленном сервере. Мы загрузили конфигурационные файлы, в том числе для Nginx. Теперь напишем несколько процедур для управления: создание симлинка на конфиг и релоад/рестарт сервиса (для них потребуются права sudo ).
Заметили приятную мелочь? — Можно задать последовательность исполнения различных процедур как в рамках одного неймспейса, так и между ними.
Управление Unicorn
Наверняка уже есть гем, расширяющий Capistrano в плоскости управления Unicorn, но мне было весьма интересно узнать, как он на самом деле устроен и работает. Поэтому сейчас, аналогично предыдущим примерам, напишем две процедуры (старт и завершение) для Unicorn.
Процедуры до и после деплоя
После деплоя нам нужно удалить самые старые релизы (по умолчанию Capistrano хранит пять последних), очистить кеши и перезапустить Unicorn. Главный рабочий блок :deploy будет выглядеть примерно так:
Вынесение процедур в отдельные файлы
Выполнение деплоя
Начиная с этого момента, все, что вам потребуется сделать для выкатки новой версии своего приложения, — закомитить изменения, сделать git push и использовать команду cap production deploy.
Что-то не получается? — Оставляйте комментарии, давайте дополним статью.
Как реализовать деплой с 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 минут. Но это после того, как на метод проб и ошибок потрачены часы. Помните про эти четыре важных особенности настройки:
Окружения развёртывания программного обеспечения
Только что опубликовал в русской википедии перевод статьи 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. Это добавляет сложности если несколько релизов запускаются одновременно, и, поэтому их обычно стараются делать быстро, чтобы избежать проблем совместимости.