За несколько лет я испытал несколько разных сценариев:
Dev -> Test: обычно есть дата замораживания кода, которая останавливает работу над новыми функциями и получает в тестовой среде код, помеченный / помеченный / заархивированный, который создается. Затем он копируется на машины и тесты проходят нормально. Это также обычно наименее детализированный из всех толчков.
Test-> Prod: для этого требуется незначительное изменение, которое должно привести к прекращению производства, что может означать, что страница «уловила рыбалку» увеличивается или IIS не запускает никаких сайтов и код копируется заново. В этом случае есть особые случаи, когда балансировщик нагрузки может действовать как переключатель, так что продвижение происходит, и ни один из клиентов не испытывает никаких простоев, так как те, что на старом сервере, переместятся после окончания сеанса.
Чтобы развить эту идею коммутатора, необходимо настроить 2 потенциально активных сервера, при этом только один сервер принимает запросы, чтобы балансировщик нагрузки отправлял весь трафик на одну машину, которую можно переключить, когда другой сервер имеет обновленный код. чтобы жить.
Может также существовать промежуточная среда, которая находится между тестированием и производством, где процесс схож с точки зрения установленной даты, когда происходит повышение.
Там, где я раньше работал, бывали дни слияния, когда разработчик проводил большую часть дня в коде слияния Perforce, чтобы его можно было перенести из одной среды в другую.
Теперь есть пара случаев, когда это не используется:
«Исправления» или «Горячие исправления» возникали там, где я работал, и в этом случае отдельные файлы копировались в промежуточную и производственную среды самостоятельно, поскольку изменение кода должно было попасть в Production ASAP, поскольку что-то сломалось в производстве или что-то новое, что нужно было сделать, что занимает 2 минуты. В этом случае изменение кода должно быть проверено и одобрено перед выходом.
Это разные подходы, которые я видел, когда обычно есть графики и графики, которые, возможно, нужно изменить, или привнести дополнительные ресурсы, чтобы назначить трудную дату, например, если конференция в какой-то конкретный уик-энд готова к тому или иному для этого.
Конечно, в нескольких местах было «О, это было сломано? Дай мне посмотреть ...», а через несколько минут: «Нет, видите, это не сломано для меня», где кто-то изменился. вещи без разрешения или что-то еще, когда у компании все еще есть то, что они называют «ковбойским программированием».
Еще один момент - масштаб выпуска:
1) Tiny - это тот случай, когда одна веб-страница поднимается, чтобы пользователь X мог сделать Y.
2) Маленький - Горстка файлов, которые на самом деле не сложны, но не совсем тривиальны.
3) Средний - для перехода из одной среды в другую требуется изменить кучу файлов и обычно есть сценарии для перемещения.
4) Большой - Там, где запланированы промо-акции, и у разных разработчиков спрашивают, кто принимает какие смены, когда будет сделан живой толчок. У меня это было в случае миграции данных в дополнение к выпуску некоторых новых сайтов электронной коммерции.
5) Мамонт - Где все новое, включая то, как это будет использоваться. Я не думаю, что когда-либо видел такой размер, но я думаю, что у Microsoft или Google будут выпуски такого размера.
Где-то в этом спектре большинство выпусков падает, и поэтому объем планирования и подготовки может сильно отличаться, и давайте не будем забывать, что соблюдение нормативных требований может быть собственной болью в выполнении некоторых вещей.