Среда развертывания

При развертывании программного обеспечения среда развертывается или уровень — это компьютерная система или набор систем, в которых компьютерная программа или программный компонент и выполняется . В простых случаях, таких как разработка и немедленное выполнение программы на одной машине, может существовать одна среда, но при промышленном использовании среда разработки (где изначально вносятся изменения) и производственная среда (то, что используют конечные пользователи) разделены. , часто с несколькими этапами между ними. Этот структурированный процесс управления выпусками позволяет поэтапное развертывание (развертывание), тестирование и откат в случае возникновения проблем.

Среды могут существенно различаться по размеру: среда разработки обычно представляет собой отдельную рабочую станцию разработчика, тогда как производственная среда может представлять собой сеть из множества географически распределенных машин в центрах обработки данных или виртуальных машин в облачных вычислениях . Код, данные и конфигурация могут развертываться параллельно, и им не требуется подключение к соответствующему уровню — например, предварительный код может подключаться к производственной базе данных.

Архитектуры

Архитектуры развертывания существенно различаются, но в целом уровни упорядочены, начиная с разработки (DEV) и заканчивая производством (PROD). Общая четырехуровневая архитектура — это разработка, тестирование, моделирование и производство (DEV, TEST, MODL, PROD), при этом программное обеспечение развертывается на каждом из них по порядку. Другие распространенные среды включают контроль качества (QC) для приемочных испытаний ; песочница или экспериментальная (EXP) для экспериментов, которые не предназначены для перехода в производство; и аварийное восстановление, чтобы обеспечить немедленный возврат в случае проблем с производством. Другая распространенная архитектура — это разработка, тестирование, приемка и производство (DTAP).

Этот язык особенно подходит для серверных программ, где серверы работают в удаленном центре обработки данных; для кода, который выполняется на устройстве конечного пользователя, например приложений (приложений) или клиентов, вместо этого можно ссылаться на среду пользователя (USER) или локальную среду (LOCAL).

Точные определения и границы между средами различаются: тестирование может считаться частью разработки, приемка может считаться частью тестирования, частью этапа или быть отдельной и т. д. Основные уровни выполняются по порядку, при этом развертываются новые выпуски ( прокатываются ). out или push ) каждому по очереди. ^[1]^[2] Экспериментальные уровни и уровни восстановления, если они присутствуют, находятся за пределами этого потока — экспериментальные выпуски являются окончательными, а восстановление обычно представляет собой старую или дублирующую рабочую версию, развертываемую после рабочей версии. В случае возникновения проблем можно вернуться к старой версии, проще всего, установив старую версию, как если бы это была новая версия. Последний шаг — развертывание в рабочей среде («отправка в рабочую среду») — наиболее деликатный, поскольку любые проблемы приводят к немедленным последствиям для пользователя. По этой причине с этим часто обращаются по-другому, по крайней мере, за ним следят более тщательно, а в некоторых случаях развертывание происходит поэтапно или требуется только нажатие переключателя, что обеспечивает быстрый откат. Лучше избегать таких названий, как «Гарантия качества» (QA); QA не означает тестирование программного обеспечения. Тестирование важно, но оно отличается от контроля качества.

Иногда развертывание выполняется вне этого обычного процесса, в первую очередь для внесения срочных или относительно незначительных изменений без необходимости полной версии. Это может быть один патч , большой пакет обновлений или небольшое исправление .

Среды могут быть самых разных размеров: разработка обычно представляет собой рабочую станцию отдельного разработчика (хотя разработчиков могут быть тысячи), тогда как производство может включать множество географически распределенных машин; Тестирование и контроль качества могут быть небольшими или большими, в зависимости от выделенных на них ресурсов, а постановка может варьироваться от одной машины (похожей на канарейку) до точной копии продукции.

Окружающая среда

В таблице ниже описан детально разделенный список уровней. ^{[ нужна ссылка ]}.

Среда/название уровня	Описание
Местный	Рабочий стол/рабочая станция разработчика
Развитие / Магистральный	Сервер разработки, действующий как песочница , где разработчик может выполнять модульное тестирование.
Интеграция	Цель сборки CI или для тестирования побочных эффектов разработчиками
Тестирование/Тестирование/КК/Внутренняя приемка	Среда, в которой выполняется тестирование интерфейса. Группа контроля качества гарантирует, что новый код не окажет никакого влияния на существующую функциональность, и тестирует основные функции системы после развертывания нового кода в тестовой среде.
Постановка / Стадия / Модель / Подготовка к производству / Приемка внешним заказчиком / Демо	Зеркало производственной среды
Производство / Концерт	Обслуживает конечных пользователей/клиентов

Разработка

Среда разработки (dev) — это среда, в которой разрабатываются изменения программного обеспечения, проще всего это отдельная рабочая станция разработчика. Это отличается от конечной целевой среды по-разному: целью может быть не настольный компьютер (это может быть смартфон, встроенная система, автономная машина в центре обработки данных и т. д.), и даже если она в остальном аналогична, среда разработчика будет включать в себя инструменты разработки, такие как компилятор, интегрированную среду разработки, различные или дополнительные версии библиотек и вспомогательного программного обеспечения и т. д., которых нет в среде пользователя.

В контексте контроля версий , особенно при наличии нескольких разработчиков, проводятся более тонкие различия: разработчик имеет рабочую копию исходного кода на своей машине, а изменения отправляются в репозиторий, фиксируясь либо в магистрали, либо ветке, в зависимости от методология разработки. Среду на отдельной рабочей станции, в которой изменения прорабатываются и опробуются, можно назвать локальной средой или «песочницей» . Создание копии исходного кода репозитория в чистой среде — это отдельный шаг, часть интеграции (интеграция разрозненных изменений), и эту среду можно назвать средой интеграции или средой разработки ; в непрерывной интеграции это делается часто, так же часто, как и при каждой ревизии. Концепция уровня исходного кода «внесение изменения в репозиторий» с последующим созданием ствола или ветки соответствует переходу к выпуску от локального (индивидуальная среда разработчика) к интеграции (чистая сборка); плохой выпуск на этом этапе означает, что изменение нарушило сборку, а откат выпуска соответствует либо откату всех изменений с этого момента, либо отмене только критического изменения, если это возможно.

Тестирование

Цель тестовой среды — позволить тестировщикам-людям тестировать новый и измененный код с помощью автоматических проверок или неавтоматизированных методов. После того как разработчик принимает новый код и конфигурации посредством модульного тестирования в среде разработки, элементы перемещаются в одну или несколько тестовых сред. ^[3] В случае неудачного теста тестовая среда может удалить ошибочный код с тестовых платформ, связаться с ответственным разработчиком и предоставить подробные журналы тестирования и результатов. Если все тесты пройдены, тестовая среда или платформа непрерывной интеграции , контролирующая тесты, может автоматически перенести код в следующую среду развертывания.

Различные типы тестирования предполагают разные типы тестовых сред, некоторые или все из которых могут быть виртуализированы. ^[4] чтобы обеспечить возможность быстрого параллельного тестирования. Например, автоматизированные тесты пользовательского интерфейса. ^[5] может возникать в нескольких виртуальных операционных системах и дисплеях (реальных или виртуальных). Для тестов производительности может потребоваться нормализованная физическая базовая конфигурация оборудования, чтобы результаты тестов производительности можно было сравнивать с течением времени. Тестирование доступности или долговечности может зависеть от симуляторов сбоев в виртуальном оборудовании и виртуальных сетях.

Тесты могут быть последовательными (один за другим) или параллельными (некоторые или все сразу) в зависимости от сложности тестовой среды. Важной целью гибких и других высокопроизводительных методов разработки программного обеспечения является сокращение времени от проектирования или спецификации программного обеспечения до его поставки в производство. ^[6] Высокоавтоматизированные и распараллеленные тестовые среды вносят важный вклад в быструю разработку программного обеспечения.

Постановка

Этапная, промежуточная или предпроизводственная среда — это среда для тестирования, которая точно напоминает производственную среду. ^[7] Он стремится как можно точнее отразить реальную производственную среду и может подключаться к другим производственным службам и данным, таким как базы данных. Например, серверы будут запускаться на удаленных компьютерах, а не локально (как на рабочей станции разработчика во время разработки или на одной тестовой машине во время теста), что позволяет проверить влияние сети на систему.

Основное использование промежуточной среды — тестирование всех сценариев и процедур установки, настройки и миграции перед их применением в производственной среде. Это гарантирует, что все крупные и мелкие обновления производственной среды будут выполнены надежно, без ошибок и за минимальное время.

Еще одним важным применением промежуточного тестирования является тестирование производительности , особенно нагрузочное тестирование , поскольку оно часто чувствительно к среде.

Промежуточный этап также используется некоторыми организациями для предварительного просмотра новых функций для выбора клиентов или для проверки интеграции с действующими версиями внешних зависимостей.

Производство

Производственная среда также известна как живая , особенно для серверов, поскольку это среда, с которой пользователи напрямую взаимодействуют.

Развертывание в рабочей среде — наиболее ответственный этап; это можно сделать путем непосредственного развертывания нового кода (перезаписав старый код, чтобы одновременно присутствовала только одна копия) или путем развертывания изменения конфигурации. Это может принимать различные формы: развертывание параллельной установки новой версии кода и переключение между ними при изменении конфигурации; развертывание новой версии кода со старым поведением и флагом функции и переключение на новое поведение с изменением конфигурации, которое выполняет смену флага; или путем развертывания отдельных серверов (один со старым кодом, другой с новым) и перенаправления трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Это, в свою очередь, может быть сделано все сразу или постепенно, поэтапно.

Развертывание нового выпуска обычно требует перезапуска, если только горячая замена невозможна, и, следовательно, требует либо прерывания в обслуживании (обычно для пользовательского программного обеспечения, когда приложения перезапускаются), либо резервирования — либо медленный перезапуск экземпляров за балансировщиком нагрузки, либо запуск новые серверы заранее, а затем просто перенаправляют трафик на новые серверы.

При развертывании нового выпуска в рабочей среде, вместо немедленного развертывания для всех экземпляров или пользователей, его можно сначала развернуть для одного экземпляра или части пользователей, а затем либо развернуть для всех, либо постепенно развернуть поэтапно, чтобы уловить любые последние -минутные проблемы. Это похоже на постановку, за исключением того, что она фактически выполняется в производстве и называется канареечным выпуском по аналогии с добычей угля. Это добавляет сложности из-за одновременного запуска нескольких выпусков и поэтому обычно быстро завершается, чтобы избежать проблем совместимости.

Интеграция фреймворков

Разработка, промежуточная обработка и производство — это известные и документированные переменные среды в ASP.NET Core . В зависимости от определенной переменной выполняется разный код и отображается содержимое, а также применяются разные настройки безопасности и отладки. ^[8]

См. также

Ссылки

^ «Традиционная практика разработки/интеграции/постановки/производства программного обеспечения» . Шут прорывных библиотечных технологий . 4 декабря 2006 г.
^ «Песочницы разработки: лучшая практика Agile » . www.agiledata.org .
^ Эллисон, Ричард (20 июня 2016 г.). «Лучшие практики в области сред тестирования программного обеспечения» . Журнал тестирования программного обеспечения . Мартиниг и партнеры . Проверено 2 декабря 2016 г. Как только разработчик выполнит сценарии модульного тестирования, код будет перемещен в отдел контроля качества, чтобы начать тестирование. Часто у вас будет несколько сред для тестирования. Например, у вас будет одна настройка для тестирования системы, другая для тестирования производительности и еще одна для пользовательского приемочного тестирования (UAT). Это вызвано уникальными потребностями каждого типа тестирования.
^ Дуби, Дениз (17 января 2008 г.). «Как контролировать виртуальные тестовые среды» . Сетевой мир, Inc. ИДГ . Проверено 2 декабря 2016 г. Технология виртуальных серверов позволяет корпоративным компаниям легко создавать и разбирать тестовые среды, в которых они могут гарантировать, что приложения будут работать на должном уровне на производственных серверах и клиентских машинах.
^ «Используйте автоматизацию пользовательского интерфейса для тестирования вашего кода» . Microsoft.com . Майкрософт . Проверено 2 декабря 2016 г. Автоматизированные тесты, которые управляют вашим приложением через его пользовательский интерфейс (UI), известны как кодированные тесты пользовательского интерфейса (CUIT). Эти тесты включают функциональное тестирование элементов управления пользовательского интерфейса. Они позволяют вам убедиться, что все приложение, включая его пользовательский интерфейс, работает правильно. Кодированные тесты пользовательского интерфейса особенно полезны там, где в пользовательском интерфейсе есть проверка или другая логика, например на веб-странице.
^ Хойссер, Мэтью (07 июля 2015 г.). «Вы чрезмерно тестируете свое программное обеспечение?» . CIO.com . ИДГ. Архивировано из оригинала 3 июня 2017 г. Проверено 3 декабря 2016 г. Тестирование релиз-кандидатов занимает слишком много времени. Для многих agile-команд это самая большая проблема. Устаревшие приложения начинаются с тестового окна, более продолжительного, чем спринт.
^ Шарма, Анураг (2018). Управление тестовой средой . ИТСМ Пресс. п. 11. ISBN 9781912651269 .
^ «Используйте несколько сред в ASP.NET Core» . docs.microsoft.com . Проверено 5 апреля 2019 г.

[1] «Традиционная практика разработки/интеграции/постановки/производства программного обеспечения» . Шут прорывных библиотечных технологий . 4 декабря 2006 г.

[agile-2] «Песочницы разработки: лучшая практика Agile » . www.agiledata.org .

[3] Эллисон, Ричард (20 июня 2016 г.). «Лучшие практики в области сред тестирования программного обеспечения» . Журнал тестирования программного обеспечения . Мартиниг и партнеры . Проверено 2 декабря 2016 г. Как только разработчик выполнит сценарии модульного тестирования, код будет перемещен в отдел контроля качества, чтобы начать тестирование. Часто у вас будет несколько сред для тестирования. Например, у вас будет одна настройка для тестирования системы, другая для тестирования производительности и еще одна для пользовательского приемочного тестирования (UAT). Это вызвано уникальными потребностями каждого типа тестирования.

[4] Дуби, Дениз (17 января 2008 г.). «Как контролировать виртуальные тестовые среды» . Сетевой мир, Inc. ИДГ . Проверено 2 декабря 2016 г. Технология виртуальных серверов позволяет корпоративным компаниям легко создавать и разбирать тестовые среды, в которых они могут гарантировать, что приложения будут работать на должном уровне на производственных серверах и клиентских машинах.

[5] «Используйте автоматизацию пользовательского интерфейса для тестирования вашего кода» . Microsoft.com . Майкрософт . Проверено 2 декабря 2016 г. Автоматизированные тесты, которые управляют вашим приложением через его пользовательский интерфейс (UI), известны как кодированные тесты пользовательского интерфейса (CUIT). Эти тесты включают функциональное тестирование элементов управления пользовательского интерфейса. Они позволяют вам убедиться, что все приложение, включая его пользовательский интерфейс, работает правильно. Кодированные тесты пользовательского интерфейса особенно полезны там, где в пользовательском интерфейсе есть проверка или другая логика, например на веб-странице.

[6] Хойссер, Мэтью (07 июля 2015 г.). «Вы чрезмерно тестируете свое программное обеспечение?» . CIO.com . ИДГ. Архивировано из оригинала 3 июня 2017 г. Проверено 3 декабря 2016 г. Тестирование релиз-кандидатов занимает слишком много времени. Для многих agile-команд это самая большая проблема. Устаревшие приложения начинаются с тестового окна, более продолжительного, чем спринт.

[Test_Environment_Management-7] Шарма, Анураг (2018). Управление тестовой средой . ИТСМ Пресс. п. 11. ISBN 9781912651269 .

[8] «Используйте несколько сред в ASP.NET Core» . docs.microsoft.com . Проверено 5 апреля 2019 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]