Comments 1
Откуда ж вы, в Microsoft, копируете эту несусветную глупость про то, что Staging окружение надо использовать для тестирования ??? У вас там что где-то есть список официально распространяемых неработающих и идиотских практик?
НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.
И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.
Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.
За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.
А Microsoft должно быть стыдно, что пишете такие практики.
И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.
И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.
Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.
За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.
А Microsoft должно быть стыдно, что пишете такие практики.
И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
Sign up to leave a comment.
Подробное описание возможностей разработки с Microsoft Azure Cloud Services