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

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденные материалы могут быть оспорены и удалены. Найти источники:  «Deployment environment» – новости  · газеты  · книги  · ученый  · JSTOR ( июнь 2019 г. ) ( Узнайте, как и когда удалять это сообщение )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сине-зеленое развертывание
• Управление жизненным циклом приложений
• Разработка, тестирование, приемка и производство
• Интегрированная среда разработки
• Разработка программного обеспечения