Сводка

  • 3 мин

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

Вы можете выбрать один из нескольких шаблонов развертывания. Выбранный шаблон развертывания зависит от ваших причин развертывания и ресурсов. Есть ли у вас канареарные тестировщики? Будете ли вы использовать скрытый запуск и выберете тестировщиков, которые не знают, что они тестировщики? Если у вас есть доверенный набор тестировщиков, который постепенно увеличивается с небольшого набора на более крупный набор, можно выбрать прогрессивное развертывание. Или, если вы хотите знать, работает ли одна версия лучше, чем другая версия, можно выбрать тестирование A/B.

Команда Tailspin выбрала реализацию шаблона сине-зеленого развертывания с помощью слотов развертывания в Службе приложений Azure. слоты развертывания — это динамические приложения с собственными именами узлов. Команда может поменять местами два слота развертывания. Они могут мгновенно внедрять изменения в производственную среду путем обмена. Хотя команда не готова освободить свой веб-сайт для общественности, они доказали, что они могут получить новые функции для своих пользователей, не вызывая простоя.

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

Как оценивают результаты команды?

В модуле "Оценка существующего процесса разработки программного обеспечения" Мара выполнила упражнение по картированию потоков ценности. Это упражнение помогло команде проанализировать текущий процесс цикла выпуска.

Необходимо помнить, что коэффициент активностиили эффективность — это время процесса, разделенное на общее время выполнения заказа.

$${Коэффициент\ активности\ =\ }{\dfrac{Время\ обработки}{Общее\ время\ выполнения}}$$

Веб-команда Tailspin изначально использовала эту метрику, чтобы определить, что их эффективность составляла 23 процента.

Команда сначала сократила некоторые неэффективности при реализации непрерывной интеграции (CI). Благодаря применению непрерывной доставки (CD), они сократили неэффективности еще больше.

В предыдущих схемах обучения команда сократила:

  • Время настройки системы управления версиями для новых функций. Требуемое время сократилось с трех дней до ноль дней.

    Команда достигла этого улучшения путем перехода из централизованного управления версиями в Git, формы распределенного управления версиями. С помощью распределенного управления версиями им не нужно ждать разблокировки файлов.

  • Время, необходимое для передачи кода Амите, тестировщику. Требуемое время изменилось с двух дней до нуля дней.

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

  • Время, необходимое Амите для тестирования новых функций. Потребное время изменилось с трех дней до одного дня.

    Команда достигла этого улучшения путем модульного тестирования кода. Они выполняют модульные тесты каждый раз, когда изменения проходят через конвейер сборки, чтобы меньше ошибок и регрессий доходило до Амиты. Сокращенная рабочая нагрузка означает, что Амита может быстрее выполнить каждый тест вручную.

Конвейер выпуска, который вы и команда создали в этом учебном пути, сократил:

  • Время, необходимое для получения сборки на стадии тестирования . Необходимое время уменьшилось с трех дней до одного дня.

    Команда достигла этого, используя запланированный триггер для развертывания на Тест каждый день в 3:00 утра.

  • Время, затраченное на получение протестированной сборки в промежуточной. Требуемое время изменилось с двух дней до нуля дней.

    Команда добилась этого улучшения, добавив тесты пользовательского интерфейса Selenium как форму функционального тестирования на этап тестирования . Эти автоматизированные тесты гораздо быстрее, чем версии вручную.

  • Время, необходимое для получения утвержденной сборки из промежуточного этапа в рабочую среду. Необходимое время ушло от одного дня до менее одного дня.

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

Эти изменения сокращают общее время выполнения с 22 дней до 10 дней. При подстановке этих чисел в уравнение:

$${Коэффициент\ активности\ =\ }{\dfrac{5\ дней}{10\ дней}}{ = 0,50}$$

Умножьте результат на 100 процентов, и мы получаем 50 процентов сокращения.

Хотя есть всегда место для улучшения, это изменение является победой для команды. Не только клиенты быстрее получают пользу, но и команда Tailspin теперь тратит меньше времени на ожидание и больше времени занимается тем, что им больше всего нравится: внедряя функции, которые, как они знают, понравятся их клиентам.

Подробнее

Используйте эти дополнительные ресурсы, чтобы узнать больше о службе приложений, слотах развертывания и откате изменений: