Сводка

  • 3 мин

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

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

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

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

Оценка результатов

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

Помните, что коэффициент активности или эффективность процесса делится на общее время выполнения:

$${Коэффициент\ активности\ =\ }{\dfrac{Продолжительность\ процесса}{Полное\ время\ выполнения}}$$

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}{ = 0,50}$$

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

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

Подробнее

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