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

Deployment environment

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

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

Архитектура

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

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

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

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

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

Среды

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

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

Разработка

«Среда разработки» перенаправляется сюда. Для использования в других целях см. Интегрированная среда развития.
Смотрите также: Песочница (разработка программного обеспечения)

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

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

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

Смотрите также: Управление тестовой средой

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

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

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

Постановка

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

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

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

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

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

Смотрите также: Поддержка производства

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

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ "Традиционная разработка / интеграция / постановка / производственная практика для разработки программного обеспечения". Шут подрывных библиотечных технологий. 4 декабря 2006 г.
  2. ^ "Песочницы для разработки: лучшие практики Agile"'". www.agiledata.org.
  3. ^ Эллисон, Ричард (2016-06-20). «Лучшие практики среды тестирования программного обеспечения». Журнал тестирования программного обеспечения. Martinig & Associates. Получено 2016-12-02. После того, как разработчик выполнит примеры модульного тестирования, код будет перемещен в QA, чтобы начать тестирование. Часто у вас будет несколько сред для тестирования. Например, у вас будет одна установка для тестирования системы, другая - для тестирования производительности, а третья - для пользовательского приемочного тестирования (UAT). Это вызвано уникальными потребностями каждого типа тестирования.
  4. ^ Дуби, Дениз (17 января 2008 г.). «Как контролировать виртуальные тестовые среды». Network World, Inc. IDG. Получено 2016-12-02. Технология виртуальных серверов позволяет корпоративным компаниям легко настраивать и отключать тестовые среды, в которых они могут гарантировать, что приложения будут работать нормально на производственных серверах и клиентских машинах.
  5. ^ «Используйте автоматизацию пользовательского интерфейса для тестирования вашего кода». Microsoft.com. Microsoft. Получено 2016-12-02. Автоматизированные тесты, которые управляют вашим приложением через его пользовательский интерфейс (UI), известны как закодированные UI-тесты (CUIT). Эти тесты включают функциональное тестирование элементов управления пользовательского интерфейса. Они позволяют вам убедиться, что все приложение, включая его пользовательский интерфейс, работает правильно. Закодированные тесты пользовательского интерфейса особенно полезны там, где в пользовательском интерфейсе есть проверка или другая логика, например, на веб-странице.
  6. ^ Хойссер, Мэтью (07.07.2015). "Вы чрезмерно тестируете свое программное обеспечение?". CIO.com. IDG. Получено 2016-12-03. Тестирование релиз-кандидата занимает слишком много времени. Для многих гибких команд это самая большая проблема. У устаревших приложений тестовое окно запускается дольше, чем спринт. Cite имеет пустой неизвестный параметр: |1= (помощь)
  7. ^ Шарма, Анураг (2018). Управление тестовой средой. ITSM Press. п. 11. ISBN 9781912651269.
  8. ^ «Использование нескольких сред в ASP.NET Core». docs.microsoft.com. Получено 2019-04-05.