 | Эта статья требует дополнительных ссылок для проверки . ( июнь 2019 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон ) |
В развертывании программного обеспечения , среды или уровня является компьютерная система , в которой компьютерная программа или программный компонент развертывается и выполняется. В простых случаях, таких как разработка и немедленное выполнение программы на одном компьютере, может быть одна среда, но при промышленном использовании среда разработки (в которой изначально вносятся изменения) и производственная среда (что используют конечные пользователи) разделены. , часто с несколькими промежуточными этапами. Этот структурированный процесс управления выпусками позволяет осуществлять поэтапное развертывание (развертывание), тестирование и откат в случае возникновения проблем.
Среды могут значительно различаться по размеру: среда разработки обычно представляет собой отдельную рабочую станцию разработчика, в то время как производственная среда может быть сетью из множества географически распределенных машин в центрах обработки данных или виртуальных машин в облачных вычислениях . Код, данные и конфигурация могут быть развернуты параллельно, и нет необходимости подключаться к соответствующему уровню - например, предварительный код может подключаться к производственной базе данных.
Архитектура [ править ]
Архитектуры развертывания значительно различаются, но в целом уровни заполняются, начиная с разработки (DEV) и заканчивая производством (PROD). Общая четырехуровневая архитектура - это разработка, тестирование, модель, производство (DEV, TEST, MODL, PROD), при этом программное обеспечение развертывается на каждом из них по порядку. Другие распространенные среды включают контроль качества (QC) для приемочного тестирования ; песочница или экспериментальная (EXP), для экспериментов, которые не предназначены для запуска в производство; и аварийное восстановление, чтобы обеспечить немедленный откат в случае проблем с производством. Другая распространенная архитектура - это разработка, тестирование, приемка и производство (DTAP).
Этот язык особенно подходит для серверных программ, где серверы работают в удаленном центре обработки данных; для кода, который выполняется на устройстве конечного пользователя, такого как приложения (приложения) или клиенты, можно вместо этого обратиться к пользовательской среде (USER) или локальной среде (LOCAL).
Точные определения и границы между средами различаются - тест может рассматриваться как часть разработки, приемка может считаться частью теста, частью стадии или быть отдельным и т. Д. Основные уровни проходят по порядку, с развертыванием новых выпусков ( свернутыми). из или толкнул ) , чтобы каждый в свою очередь. [1] [2] Экспериментальные уровни и уровни восстановления, если они есть, находятся за пределами этого потока - экспериментальные выпуски являются конечными, в то время как восстановление обычно представляет собой старую или дублированную производственную версию, развернутую после производства. В случае проблем можно откатитьсяк старому выпуску, проще всего протолкнув старый выпуск, как если бы он был новым. Последний шаг, развертывание в продакшн («продвижение в продакшн») является наиболее чувствительным, поскольку любые проблемы приводят к немедленному воздействию на пользователя. По этой причине с этим часто обращаются по-другому, по крайней мере, за более тщательным мониторингом, а в некоторых случаях с поэтапным развертыванием или с требованием только переключения переключателя, позволяющего быстро откатиться. Лучше избегать такого названия, как обеспечение качества (QA); QA не означает тестирование программного обеспечения. Тестирование важно, но оно отличается от QA.
Иногда развертывание выполняется вне этого обычного процесса, в основном для внесения срочных или относительно незначительных изменений, не требуя полного выпуска. Он может состоять из одного исправления , большого пакета обновления или небольшого исправления .
Среды могут быть самых разных размеров: разработка, как правило, представляет собой отдельную рабочую станцию разработчика (хотя разработчиков могут быть тысячи), в то время как производство может включать множество географически распределенных машин; test и QC могут быть маленькими или большими, в зависимости от выделенных для них ресурсов, а этапы могут варьироваться от одной машины (аналогично канарейке) до точной копии продукции.
Среды [ править ]
В таблице ниже описан подробный список уровней [ необходима ссылка ] .
| Название среды / уровня | Описание |
|---|---|
| Местный | Рабочий стол / рабочая станция разработчика |
| Развитие / Багажник | Сервер разработки, действующий как песочница, где разработчик может выполнять модульное тестирование |
| Интеграция | Цель сборки CI или для тестирования побочных эффектов разработчиком |
| Тестирование / Тестирование / Контроль качества / Внутренняя приемка | Среда, в которой выполняется тестирование интерфейса. Группа контроля качества гарантирует, что новый код не повлияет на существующие функциональные возможности, и тестирует основные функциональные возможности системы после развертывания нового кода в тестовой среде. |
| Постановка / сцена / модель / подготовка к производству / приемка со стороны внешнего клиента / демонстрация | Зеркало производственной среды |
| Производство / Live | Обслуживает конечных пользователей / клиентов |
Развитие [ править ]
Среда разработки (dev) - это среда, в которой разрабатываются изменения программного обеспечения, проще говоря, отдельная рабочая станция разработчика. Это отличается от конечной целевой среды по-разному - целевой машиной может быть не настольный компьютер (это может быть смартфон, встроенная система, безголовая машина в центре обработки данных и т. Д.), И даже если в остальном она похожа, среда разработчика будет включают инструменты разработки, такие как компилятор, интегрированная среда разработки, различные или дополнительные версии библиотек и вспомогательного программного обеспечения и т. д., которые отсутствуют в среде пользователя.
В контексте контроля версий , особенно с несколькими разработчиками, проводятся более тонкие различия: разработчик имеет рабочую копию исходного кода на своей машине, а изменения отправляются в репозиторий, фиксируясь либо в магистрали, либо в ветке, в зависимости от методология разработки. Среда на отдельной рабочей станции, в которой изменения обрабатываются и апробируются, может называться локальной средой или песочницей . Создание копии исходного кода репозитория в чистой среде - это отдельный шаг, часть интеграции (интеграция разрозненных изменений), и эту среду можно назвать средой интеграции или средой разработки.; при непрерывной интеграции это делается часто, как и при каждой ревизии. Концепция уровня исходного кода «фиксация изменения в репозитории» с последующим построением магистрали или ветви соответствует переходу к выпуску из локального (среда отдельного разработчика) к интеграции (чистая сборка); плохой выпуск на этом этапе означает, что изменение нарушило сборку, а откат выпуска соответствует либо откату всех изменений с этого момента, либо отмене только критического изменения, если это возможно.
Тестирование [ править ]
Цель тестовой среды - дать возможность людям-тестерам испытать новый и измененный код с помощью автоматических проверок или неавтоматических методов. После того, как разработчик принимает новый код и конфигурации посредством модульного тестирования в среде разработки, элементы перемещаются в одну или несколько тестовых сред. [3] В случае сбоя теста тестовая среда может удалить неисправный код с тестовых платформ, связаться с ответственным разработчиком и предоставить подробные журналы тестов и результатов. Если все тесты пройдены, тестовая среда или среда непрерывной интеграции, контролирующая тесты, могут автоматически продвигать код в следующую среду развертывания.
Различные типы тестирования предполагают разные типы тестовых сред, некоторые или все из которых могут быть виртуализированы [4], что позволяет проводить быстрое параллельное тестирование. Например, автоматические тесты пользовательского интерфейса [5] могут выполняться в нескольких виртуальных операционных системах и дисплеях (реальных или виртуальных). Для тестов производительности может потребоваться нормализованная базовая физическая конфигурация оборудования, чтобы результаты тестов производительности можно было сравнивать с течением времени. Тестирование доступности или долговечности может зависеть от симуляторов отказов в виртуальном оборудовании и виртуальных сетях.
Тесты могут быть последовательными (одно за другим) или параллельными (некоторые или все сразу) в зависимости от сложности тестовой среды. Важной целью гибкой и другой высокопроизводительной разработки программного обеспечения является сокращение времени от разработки программного обеспечения или спецификации до поставки в производство. [6] Высокоавтоматизированные и распараллеленные тестовые среды вносят важный вклад в быструю разработку программного обеспечения.
Постановка [ править ]
Этапная, промежуточная или предпроизводственная среда - это среда для тестирования, которая в точности напоминает производственную среду. [7] Он стремится максимально точно отразить реальную производственную среду и может подключаться к другим производственным службам и данным, таким как базы данных. Например, серверы будут работать на удаленных машинах, а не локально (как на рабочей станции разработчика во время разработки или на одной тестовой машине во время тестирования), что проверяет влияние сети на систему.
Основное использование промежуточной среды - это проверка всех сценариев и процедур установки / настройки / миграции перед их применением в производственной среде. Это гарантирует, что все основные и второстепенные обновления производственной среды будут выполнены надежно, без ошибок и в минимальные сроки.
Еще одно важное использование промежуточного тестирования - это тестирование производительности , особенно нагрузочное тестирование , поскольку оно часто зависит от среды.
Поэтапное выполнение также используется некоторыми организациями для предварительного просмотра новых функций для выбора клиентов или для проверки интеграции с действующими версиями внешних зависимостей.
Производство [ править ]
Производственная среда также известна как « живая» , особенно для серверов, поскольку это среда, с которой пользователи напрямую взаимодействуют.
Развертывание в производственной среде - самый ответственный шаг; это может быть сделано путем непосредственного развертывания нового кода (перезаписи старого кода, чтобы одновременно была только одна копия) или путем развертывания изменения конфигурации. Это может принимать различные формы: развертывание параллельной установки новой версии кода и переключение между ними при изменении конфигурации; развертывание новой версии кода со старым поведением и флагом функции и переключение на новое поведение с изменением конфигурации, которое выполняет переключение флага; или путем развертывания отдельных серверов (один запускает старый код, другой - нового) и перенаправления трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Это, в свою очередь, можно делать все сразу или постепенно, поэтапно.
Развертывание нового выпуска обычно требует перезапуска, если горячая замена не возможна, и, следовательно, требует либо прерывания обслуживания (обычно для пользовательского программного обеспечения, когда приложения перезапускаются), либо избыточности - либо медленный перезапуск экземпляров после балансировщика нагрузки, либо запуск новые серверы заранее, а затем просто перенаправляют трафик на новые серверы.
При развертывании нового выпуска в производственной среде вместо немедленного развертывания для всех экземпляров или пользователей его можно сначала развернуть для одного экземпляра или части пользователей, а затем либо развернуть для всех, либо постепенно развертывать поэтапно, чтобы уловить все последние. -минутные проблемы. Это похоже на постановку, за исключением того, что фактически выполняется в производстве, и называется канареечным выпуском по аналогии с добычей угля. Это добавляет сложности из-за одновременного запуска нескольких выпусков и, таким образом, обычно быстро завершается, чтобы избежать проблем совместимости.
Интеграция с фреймворками [ править ]
Разработка, подготовка и производство - известные и задокументированные переменные среды в ASP.NET Core . В зависимости от определенной переменной выполняется другой код и отображается содержимое, а также применяются разные параметры безопасности и отладки. [8]
См. Также [ править ]
- Управление жизненным циклом приложений
- Разработка, тестирование, приемка и производство
- Интегрированная среда развития
- Разработка программного обеспечения
Ссылки [ править ]
- ^ «Традиционная разработка / интеграция / постановка / производственная практика для разработки программного обеспечения» . Шут подрывной библиотечной технологии . 4 декабря 2006 г.
- ^ «Развитие Песочница: Agile„Лучшая практика “ » . www.agiledata.org .
- ^ Эллисон, Ричард (2016-06-20). "Лучшие практики среды тестирования программного обеспечения" . Журнал тестирования программного обеспечения . Martinig & Associates . Проверено 2 декабря 2016 .
После того, как разработчик выполнит примеры модульного тестирования, код будет перемещен в QA, чтобы начать тестирование.
Часто у вас будет несколько сред для тестирования.
Например, у вас будет одна установка для тестирования системы, другая - для тестирования производительности, а третья - для пользовательского приемочного тестирования (UAT).
Это вызвано уникальными потребностями каждого типа тестирования.
- ^ Дуби, Дениз (2008-01-17). «Как контролировать виртуальные тестовые среды» . Network World, Inc . IDG . Проверено 2 декабря 2016 .
Технология виртуальных серверов позволяет корпоративным компаниям легко настраивать и отключать тестовые среды, в которых они могут гарантировать, что приложения будут работать в нормальном состоянии на производственных серверах и клиентских машинах.
- ^ «Используйте автоматизацию пользовательского интерфейса для тестирования вашего кода» . Microsoft.com . Microsoft . Проверено 2 декабря 2016 .
Автоматические тесты, которые управляют вашим приложением через его пользовательский интерфейс (UI), известны как закодированные UI-тесты (CUIT). Эти тесты включают функциональное тестирование элементов управления пользовательского интерфейса. Они позволяют вам убедиться, что все приложение, включая его пользовательский интерфейс, работает правильно. Закодированные тесты пользовательского интерфейса особенно полезны там, где в пользовательском интерфейсе есть проверка или другая логика, например, на веб-странице.
- ^ Heusser, Мэтью (2015-07-07). "Вы чрезмерно тестируете свое программное обеспечение?" . CIO.com . IDG . Проверено 3 декабря 2016 .
Тестирование релиз-кандидата занимает слишком много времени.
Для многих гибких команд это самая большая проблема.
У устаревших приложений тестовое окно запускается дольше, чем спринт.
- ^ Шарма, Анураг (2018). Управление тестовой средой . ITSM Press. п. 11. ISBN 9781912651269.
- ^ «Используйте несколько сред в ASP.NET Core» . docs.microsoft.com . Проверено 5 апреля 2019 .
