У меня есть несколько вопросов к гуру Azure. Я работаю в компании по разработке программного обеспечения, и меня попросили разработать нашу инфраструктуру Azure. У меня была идея создать три подписки Pay-As-You-Go для следующих отделов:
1) Производство (живая среда). 2) Гарантия качества. 3) Тестирование.
Мои вопросы:
1) При создании таких ресурсов, как сайты; виртуальные машины и другие, можно ли их переносить между различными подписками? Вот сценарий: допустим, мы запускаем новое приложение, но сначала нам нужно его протестировать. Поэтому мы сначала помещаем его в Testing. После проведения тщательного тестирования мы переводим его в систему контроля качества. После этого мы перемещаем его в производство (живую среду), когда все проверки качества были исчерпаны. 2) Я также разрабатываю матрицу безопасности, где пользователь в одном отделе не может ничего изменить в другом отделе.
Что скажете вы, дамы и господа? Насколько это возможно?
Мы используем Visual Studio Online (VSO) для автоматической сборки и развертывания в различных средах Azure. Это будет работать независимо от того, разделяете ли вы свои среды по разным подпискам или используете разные группы ресурсов в одной подписке.
Наша установка такова, что каждая проверка кода запускает сборку, запускает модульные тесты и, в случае успеха, развертывает триггеры в тестовой среде.
Затем наш отдел QA обычно ставит сборку в очередь через VSO, выбирая конкретный набор изменений / дату. Если сборка и модульные тесты проходят успешно, запускается развертывание в QA. Эта сборка также технически предназначена для prod, но не развертывается для prod.
Они выполняют всю свою работу по обеспечению качества, и если все в порядке, они подтверждают свою сторону логики привратника, встроенной в VSO. Затем мы настроили его, так что 2 других человека должны подписать, что сборка будет запущена в производство (что может быть немедленным или запланированным).
Если вы находитесь в помещении, вы можете вместо этого использовать их TFS, что по сути одно и то же.
TL; DR; Вы можете сделать это с помощью VSO и интегрировать его с Azure Active Directory для проверки подлинности и управления.
Майкл - используемый вами процесс миграции будет во многом зависеть от базовой инфраструктуры / службы, которую вы используете.
В качестве отправной точки я предлагаю посмотреть, как вы можете использовать службы сборки для автоматического развертывания создаваемого вами программного обеспечения. В Документация MSDN это хорошая отправная точка.
Обычно поиск способов создания сценариев или автоматизации развертывания / повторного развертывания любых решений, которые вы создаете, будет потраченным временем в вашем сценарии.