Веб-сайт нашей компании скоро будет размещен в службе приложений в Azure. Веб-сайт взаимодействует с уровнем API, который также размещен в Azure, и ссылается на наши внутренние системы и базы данных. Архитектура на этом уровне не может быть изменена в настоящее время, и у нее довольно много предыстории и т. Д.
Мы планируем всегда внедрять развертывания с использованием слотов развертывания в службе приложений в Azure. Уровень API будет иметь неизменные изменения для каждого развертывания, и развертывание API будет первой частью любого выпуска, за которым следует веб-сайт.
У нас есть четкое разделение между нашими средами, и выпуск будет протестирован в средах Dev, Test и Pre-Prod до начала производственного развертывания. В целом весь процесс довольно прост, пока не доходит до тестирования после внедрения (PI), которое в настоящее время является обязательным в нашей компании.
Нам нужно иметь возможность протестировать производственное развертывание до того, как клиенты будут использовать сайт. В настоящее время мы предлагаем переключать сайт в режим обслуживания, если он не доступен из списка выбранных IP-адресов. Теперь нам нужно выполнить PI-тестирование новой версии сайта, пока клиент продолжает использовать старую версию сайта. Я не был уверен, как лучше всего этого добиться.
У меня была одна идея - создать поддомен, который напрямую ссылается на слот развертывания _staging веб-сайтов, минуя настройки слота развертывания. В свою очередь, некоторая логика здесь может идти прямо в слот развертывания API _staging. Это даст возможность опубликовать реализацию изменения непосредственно перед тем, как нажать кнопку «Обмен», чтобы поменять местами слоты развертывания.
Я знаю, что общий процесс не идеален, но на данный момент это не может быть изменено. У кого-нибудь есть мысли или другие предложения по вышеизложенному, пожалуйста?
