Development --> Staging --> Production
Довольно типичный рабочий процесс. Это отлично.
«Хорошо, вы хотите, чтобы среда« Бета »показывала некоторым пользователям / клиентам вещи, которые еще не совсем готовы к Prime-Time».
Development --> Staging --> Beta
\-> Prod
«Что вы имеете в виду« Pre-Production »? Для этого и нужна постановка».
Я видел несколько (НЕСКОЛЬКИХ!) Случаев, когда можно было бы потребовать большего, например, в отраслях с интенсивным аудитом, где необходимо проводить тщательное тестирование, но даже они, кажется, выходят из-под контроля. (Однажды я работал в месте с 11 отдельными средами!)
Кто-нибудь еще видит это разрастание окружающей среды? Как мы можем управлять разработчиками (и менеджментом), которые считают их «важными»?
Даже мои просьбы об увеличении стоимости и сложности, кажется, игнорируются, и мне кажется, что некоторые из причин - лень. За пределами 4-5 сред мое паучье чутье начинает покалывать ...
Есть много веских причин для выхода за рамки этого типичного рабочего процесса. У нас нет среды QA, как предлагает @CamelBlues, в конце концов, код должен быть QA, прежде чем он будет помечен как завершенный и готов к переходу к промежуточному этапу. Мы используем QA во время разработки и поэтому не нуждаемся в среде QA.
В любом случае, серьезные изменения в коде, такие как замена пользовательского интерфейса или вещи, вызывающие необходимость в дополнительной ветви разработки, часто также требуют другого места для тестирования и этапа, чем основная среда разработки.
Например, если я заменяю свой пользовательский интерфейс и портирую свое приложение в новую систему MVC, я могу создать новую ветку для выполнения этого в репозитории системы управления версиями. Однако я не могу запустить свой устаревший код и новый код MVC вместе, поэтому нам понадобится новая среда для размещения этой ветки до ее завершения. Особенно, если вам все равно придется исправлять ошибки.
Просто помните ... это ТОЧНО, для чего нужны виртуальные машины. Возможно, вам даже удастся получить пробные лицензии 60-90 от Microsoft (если это ваша платформа) для целей разработки и тестирования. На самом деле не имеет значения, сколько сред запрошено (в разумных пределах и по сравнению с размером вашей команды), потому что у вас должна быть платформа для простого и быстрого раскрутки машин, именно так работают большинство крупных магазинов разработчиков и фактически позволяют разработчикам и тестерам проверять -out виртуальных машин для использования.
Обновить: Только что проверил нашу среду, и у нас также есть предварительная версия. Команда по выпуску и развертыванию использует его для проверки инструкций и исправлений, чтобы пройти пробный прогон до фактического касания производственных ящиков. Дает им буфер.
Я бы не стал называть это «разрастанием», поскольку похоже, что вам не хватает среды контроля качества.
Разработка -> Контроль качества -> Постановка -> Производство
это еще один рабочий процесс, который вы могли бы использовать.
Разработка и контроль качества могут быть внутренней средой разработки и управления, в то время как постановка и производство могут быть ориентированы на клиента.
[редактировать]
Возможно, вы захотите иметь максимум 4 среды и строгий контроль доступа к тому, кто может развертывать в какой среде (для предотвращения сердечных приступов). Если руководство начинает запрашивать бета-версию, предварительную бета-версию и т. Д., Отправьте их в отдел контроля качества или промежуточного тестирования и сообщите им, что это «бета» среда.
Я думаю, что ограничение доступа поможет контролировать разрастание. Если вы используете CI-сервер, вы можете ограничить развертывание производственной средой, поместив поле пароля в конфигурацию задания сборки и проверив ваш скрипт сборки на соответствие паролю, жестко закодированному в скрипте. то есть:
if [ $PASSWORD == 'foo' ]
build_app();
else
exit 1;
Да, это полный взлом и мнимая безопасность, но он имеет психологический эффект, удерживая людей от беспорядочного развертывания в производственную среду и вместо этого оставаясь в средах, в которых развертывание проще всего.