Какова рекомендуемая стратегия разработки-тестирования-развертывания для Azure?

Question

Мы новичок в Azure и собираемся развернуть наше первое приложение в ближайшие несколько дней. Мне было просто интересно, нужно ли нам иметь более четкий процесс тестирования и развертывания и как сделать его более экономичным.

Это процесс, который я рассматривал -

1.Разработка на местной ткани Dev

2. Поддерживать общий сервер сборки, на котором также размещен контроль версий (мы используем TFS для обоих)

3. Использование сервера сборки для локального тестирования, которое сообщает об ошибках в разработку

4. Иметь отдельную учетную запись Azure для тестирования среды. Построенные после тестирования сборки будут развернуты для этой учетной записи и использованы для тестирования среды

5. Как только все проблемы будут устранены и тесты пройдены, разверните ту же сборку в рабочей учетной записи (непосредственно с сервера сборки, я не мог придумать, как перейти от тестирования Azure к производству Azure)

О некоторых моментах, о которых мне придется позаботиться -

1. Данные должны будут воспроизводиться с серверов производства на тестирование, чтобы тестирование было эффективным

2. Действия по сборке должны быть автоматизированы для уменьшения ошибок вручную (особенно при изменении параметров, связанных с учетной записью, таких как ключи)

Ребята, это нормально? Или в этом есть лазейки? Я хотел разделить тестовую учетную запись и учетную запись продукта так, чтобы учетные данные безопасности нашего продукта могли храниться только у ключевого оперативного персонала. Это что-то вроде того, что рекомендуется в одном из блогов Microsoft, но я хотел, чтобы его разобрали с помощью команды экспертов. Заранее спасибо.

Answer 1

Это зависит от методологии. Если вы выполняете итерации, разделите учетные записи тестирования и производства, продвигая релиз только после того, как он пройдет тестирование.

Важно: возможно, вы захотите начать разработку для Azure Fabric как можно скорее (или, по крайней мере, использовать учетную запись хранения Azure в облаке), поскольку Dev и реальные структуры на этом этапе слишком различаются. Есть несколько причуд, которые могут сделать вашу жизнь сложнее, если вы полностью полагаетесь на ткань и хранилище разработчика .

Если вы занимаетесь быстрой разработкой (т. Е. Развертываете стабильные функции, как только они становятся стабильными и проходят модульные тесты), то нет явной необходимости в одной учетной записи тестирования (хотя некоторым разработчикам или прототипам могут потребоваться отдельные учетные записи для основание дела). Обратите внимание, что в этом случае вам может потребоваться автоматизировать процесс развертывания (15 минут для развертывания - это долго) с помощью сценариев powershell или какого-либо менеджера развертывания, который просто загружает двоичные файлы в новый домен приложений.

Answer 2

Вам не нужна отдельная учетная запись Azure. Вместо этого вы развертываете только что созданный проект Azure в промежуточном развертывании своей учетной записи Azure, протестируйте его и поменяйте местами промежуточные и производственные развертывания Azure.

Одна вещь, которую вы никогда не захотите сделать, - это развернуть проект непосредственно в своем производственном развертывании Azure. Я видел, что процесс занял более 10 минут, и в течение этого времени ваше приложение будет отключено. Промежуточное развертывание к производственному обмену развертыванием значительно быстрее и должно завершать работу приложения только на 10-20 секунд.