Лабораторная работа Continuous Delivery с помощью Release Management для Visual Studio 2013

Лабораторная работа
Continuous Delivery с помощью Release
Management для Visual Studio 2013
Lab version:
12.0.21005.1
Last updated:
12/11/2013
СОДЕРЖАНИЕ
РЕЗЮМЕ ...................................................................................................................................................... 3
УПРАЖНЕНИЕ 1: ОБЗОР RELEASE MANAGEMENT ............................................................................. 4
УПРАЖНЕНИЕ 2: НАСТРОЙКА RELEASE MANAGEMENT ................................................................. 10
УПРАЖНЕНИЕ 3: ОПРЕДЕЛЕНИЕ ПЛАНА И ШАБЛОНА РЕЛИЗА.................................................... 19
УПРАЖНЕНИЕ 4: ПРИМЕР АВТОМАТИЗАЦИИ РЕЛИЗА.................................................................... 30
Резюме
Из этой лабораторной работы вы узнаете о том, как использовать Release Management for Visual
Studio 2013 и входящий в него набор средств для релиза и автоматизации процесса
развертывания приложений на десктоп, сервер и в облако. Release Management for Visual Studio
2013 может интегрироваться с Team Foundation Server 2013 для настройки и автоматизации
сложных развертываний автоматизированных сборок. Разработчики могут моделировать планы
релизов и отслеживать и визуализировать состояния релиза.
Примечание: вы можете начать сразу с реальной демонстрации в четвертом упражнении,
пропустив обзор и упражнения по настройке. Если же вам Release Management не знаком, мы
рекомендуем как минимум прочитать несколько упражнений для понимания процесса.
Prerequisites
Для выполнения лабораторной работы вам понадобится виртуальная машина с Visual Studio 2013.
Подробнее про то, где загрузить и как ее использовать, здесь
О компании Fabrikam Fiber
Эти лабораторные работы в качестве основы для сценариев, о которых вы узнаете в процессе,
оперируют несуществующей компанией Fabrikam Fiber. Fabrikam Fiber занимается кабельным
телевидением и сопутствующими сервисами в США. Компания быстро растет и уже начала
использовать Microsoft Azure для того, чтобы масштабировать свой веб-сайт для обслуживания их
запросов и отслеживания деятельности инженеров. Компания использует локальное приложение
ASP.NET MVC для управления заказами клиентов.
В этих лабораторных работах вы изучите сценарии, включенные в рабочий процесс команды
разработки и тестирования Fabrikam Fiber. Команда, состоящая из 8-10 человек, решила
использовать средства управления жизненным циклом проектов Visual Studio 2013 для того, чтобы
контролировать программный код, выполнять сборки, тестировать веб-сайты, планировать и
отслеживать происходящее с проектом
Упражнения
Эта лабораторная работа включает в себя следующие упражнения
1. Обзор Release Management
2. Настройка Release Management
3. Определение плана и шаблона релиза
4. Пример автоматизации релиза
Примерное время выполнения лабораторной работы: 60 минут
Упражнение 1: Обзор Release
Management
В этом упражнении вы изучите Release Management и принципы интеграции с Team Foundation
Server для автоматизации развертывания. На примере вы увидите, как выглядит в веб-клиенте
Release Management процесс релиза.
1. Войдите под аккаунтом Brian Keller (VSALM\Brian). Пароль: P2ssw0rd.
2. Цель Release Management – дать механизм, с помощью которого компоненты приложения
могут автоматически разворачиваться на разные серверы в разных средах. У компонентов
могут быть разные конфигурации на разных серверах, но на эти серверы все равно надо
развернуть один и тот же пакет. Еще одной целью является сохранение конфигурации в
одном месте и управление развертываниями как часть процесса релиза, в который
вовлечены многие работники организации. Release Management работает на основе
четырех компонентов.
Изображение 1
Компоненты Release Management

Сервер Release Management. Серверный компонент – это ядро решения. Состоит из базы
данных, контроллера рабочего процесса и диспетчера, синхронизирующего
взаимодействие с серверами развертывания.

Клиент Release Management. Клиенты подразделяются на два типа – на Windows
Presentation Foundation (WPF), предоставляющий полную функциональность приложения,
и веб-клиент, предназначенный для тестировщиков, ответственных за приемку решения и
менеджеров.

Release Management Deployer. Сервис, уже установленный на серверах, на которых
необходимо произвести развертывание компонентов приложения. Release Management
не нуждается в доступе к этим серверам, так как все операции производятся сервисом
Deployer.

Инструменты Deployer. В Release Management есть набор инструментов, помогающих в
реализации различных сценариев – например, удалении или установке компонент,
развертывании отчетов на Microsoft SQL Reporting Services и миграции файлов.
Примечание: в используемой виртуальной машине уже установлены все компоненты
Release Management, включая Deployer.
3. Важно также учитывать, что Release Management продолжает развиваться и
интегрироваться в существующие инструменты. Компоненты Release Management для
авторинга будут интегрированы в Visual Studio Test Professional, Visual Studio Premium и
Visual Studio Ultimate. Все необходимые для участия в процесе релиза компоненты будут
интегрированы в Team Foundation Server CAL. Серверные компоненты будут
интегрированы в Team Foundation Server 2013. Процессы Deployer (нужные для каждого
сервера развертывания) будут предоставляться под отдельной лицензией.
4. Базовый элемент функционирования Release Management – взаимодействие
пользователей с сервером с помощью клиента, в котором запросы на релиз инициируют
запрос на развертывание. Запустите веб-клиент http://vsalm:1000/ReleaseManagement. У
нас пока нет запросов.
Изображение 2
Веб-клиент Release Management
5. Нажмите на Previously Approved – мы увидим, что уже был релиз, инициированный
сборкой Fabrikam Call Center.
Изображение 3
Просмотр истории
6. Нажмите на ссылку с количеством развернутых компонентов (под именем Brian Keller).
Изображение 4
Количество развернутых компонентов
7. Этот раздел показывает компоненты, развернутые на каждом этапе релиза. В нашем
случае это конкретная сборка веб-сайта.
Изображение 5
Развернутые компоненты
8. Нажмите Escape.
9. Справа мы можем видеть то, что развертывание сейчас на стадии production. Нажмите на
stages для просмотра истории и запросов, предшествующих этой стадии.
Изображение 6
Ссылка
10. Этот раздел показывает историю и результаты того, что случилось на стадии Production
(“Prod”). Эта стадия была подтверждена вручную Brian Keller, автоматически установлена в
среду развертывания и проверена Brian еще раз.
Изображение 7
История стадии “Prod”
11. Нажмите на Previous Stage.
Изображение 8
Ссылка Previous Stage
12. Это – стадия QA, и на ней уже больше автоматизированных шагов – подтверждение,
установка и проверка приложения, и последним шагом – одобрение командой QA.
Изображение 9
История стадии “QA”
Примечание: настройка всех стадий, показываемых в этой лабораторной работе,
приводится только как демонстрация. В нормальных сценариях на стадии QA шаг
подтверждения не автоматизируется, и ответственный за эту стадию решает, когда
развернуть новую версию.
13. Нажмите на Previous Stage, чтобы перейти на историю стадии “Dev” (разработки). Здесь
тоже есть автоматизированные шаги, но для перехода на следующую стадию нужно
ручное одобрение. Последний, кто одобряет, тем самым заявляет, что текущая версия
удовлетворяет всем критериям качества и должна перейти на следующую стадию (QA).
Мы увидим, как это все настраивается, позже, пока просто запомните, что эту
последовательность разных стадий (Dev->QA->Prod) мы называем планом релиза (release
path).
Изображение 10
История стадии “Dev”
14. Нажмите Escape.
15. Планы собраны на серверах, сгруппированных в среды, на которых проводится
тестирования стадии. Как только приложение становится готовым к развертыванию в
новую среду, сервер ставит запрос на развертывание каждого компонента в очередь на
все сервера развертывания, что позволяет выполнять гибкое развертывание всех
компонентов.
16. Сервис Release Management Deployer постоянно отслеживает сервер Release Management
(по настраиваемому интервалу) и собирает запросы на установку компонентов.
17. Сервис Deployer находит и загружает пакет релиза с Release Management Server, который
определяет расположение, используя TFS API или преднастроенные пути UNC.
18. Deployer загружает дополнительные файлы (скрипты, PowerShell-скрипты, .exe) для
запуска в процессе установки. Во время установки можно выполнять дополнительные
задачи – например, создавать тестовые данные или выполнять автоматические тесты.
Упражнение 2: Настроика Release
Management
В этом упражнении вы изучите основные настройки подключения Release Management к Team
Foundation Server, включающие в себя те, что применяются к сервису Deployer, группам,
пользователям, серверам и средам.
1. Запустите Release Management.
Изображение 11
Запуск Release Management
2. По умолчанию Release Management после открытия показывает вкладку Traffic Overview,
на которой изображено движение развертываний через планы релизов и стадии. Видно,
что приложение Fabrikam Call Center уже было развернуто без ошибок.
Изображение 12
Traffic overview
3. Посмотрим на основные задачи по конфигурации, которые нужно выполнить для
установки и настройки Release Management. Перейдите на вкладку Administration и
нажмите на Manage TFS.
Изображение 13
Настройка подключения к TFS
4. Нажмите два раза на уже созданном подключении.
Изображение 14
Загрузка настроек для подключения Team Foundation Server
5. Это подключение было уже создано, но нужно упомянуть, что пользовательский аккаунт,
используемый Release Management, должен иметь разрешение “Make requests on behalf
of others” в Team Foundation Server.
Изображение 15
Настройка аккаунт для подключения к Team Foundation Server
6. Другие настройки доступны в Administration | System Settings. На вкладке System System
Settings можно настроить значения тайм-аутов, информации по версии и лицензии и
конфигурация SMTP. Эти настройки установлены в стандартные значения.
Изображение 16
Системные настройки
7. Перейдите на вкладку Deployer Settings. Здесь доступны настройки для сервисов Deployer,
например, можно указать, как часто Deployer будет опрашивать Release Management на
предмет наличия пакетов к развертыванию.
Изображение 17
Настройки Deployer
8. Посмотрим на настройку пользователей и групп. Перейдите в Administration | Manage
Users.
Изображение 18
Настройка пользователей
9. Нажмите два раза на Brian Keller.
Изображение 19
Просмотр настроек пользователя
10. Этот пользователь привязан к Windows-аккаунту VSALM\Brian, имеет права Release
Manager и является активным членом нескольких команд.
Изображение 20
Просмотр настроек пользователя
11. Перейдите в Administration | Manage Groups – здесь доступны настройки групп.
Изображение 21
Настройки групп
12. Вы можете создать группу или импортировать ее из Active Directory/Team Foundation
Server. Группы, импортируемые из AD или TFS, потом автоматически синхронизируются.
Изображение 22
Импортирование групп из AD и TFS
Примечание: процесс синхронизации инициируется вручную (кнопкой Refresh), если
значение настройки AD/TFS-Based Group Refresh Interval равно 0 минут.
13. Нажмите два раза на QA Team.
Изображение 23
Просмотр информации о группе
14. На вкладке Members показывается информация о членах группы. Можно добавить новых
(если группа не привязана к AD или Team Foundation Server).
Изображение 24
Просмотр членов группы
15. Перейдите на вкладку Security.
Изображение 25
Вкладка Security
16. На вкладке Security можно указать разрешения на Release Management для выбранной
группы. В используемой виртуальной машине права у всех максимальные.
Изображение 26
Настройки безопасности
17. Перейдите в Administration | Manage Pick Lists. Здесь доступна информация о типах
стадий, которые вы можете задавать так, как хотите.
Изображение 27
Настройка типов стадий
18. На серверах развертывания должен быть установлен сервис Release Management,
подключенный к Release Management Server по HTTP/HTTPS. Эти серверы также должны
быть явным образом добавлены в Release Management Server. Перейдите в Configure
Paths | Servers – здесь видно, что сервис Deployer для этой виртуальной машины уже
настроен.
Изображение 28
Настройка серверов
Примечание: рекомендуемый способ добавления серверов развертывания использование выпадающего меню New | Scan for New.
19. Нажмите два раза на сервере VSALM.
Изображение 29
Настройка серверов
20. Для выбранного сервера есть много настроек, но основной момент здесь это заключается
в том, что настраиваемый сервер должен быть уникальным, чтобы Release Management
Server мог его идентифицировать. Можно использовать клонированные серверы,
используя шлюз, и забирать пакет развертывания с сервера по HTTP(S).
Изображение 30
Настройка серверов
21. Перейдите в Configure Paths | Environments.
Изображение 31
Просмотр настроек сред
22. Серверы объединены в среды для того, чтобы они были отделены от определений плана
релиза. Нажмите два раза на первой среде “Int-Dev”.
Изображение 32
Просмотр настроек сред
23. Эта среда содержит группу серверов для разработки. Если нужно ограничить
использование этой среды для определенных стадий, это можно сделать на вкладке Stage
Type Security.
Изображение 33
Просмотр настроек сред
Упражнение 3: Определение плана
релиза и шаблона
В этом упражнении вы научитесь создавать и настраивать план и шаблон релиза, а также изучите
доступные инструменты развертывания приложения в среду.
1. Посмотрим на определение плана релиза. Перейдите в Configure Paths | Release Paths и
нажмите два раза на плане Fabrikam Call Center.
Изображение 34
Обзор плана релиза
2. Этот план определяет три стадии: Dev -> QA -> Prod. Большинство шагов
автоматизировано. Обе стадии Dev и QA должны быть явным образом одобрены перед
началом следующей стадии.
Изображение 35
Обзор плана релиза
3. Посмотрим на то, как команда Fabrikam Fiber определяет процесс развертывания вебприложения. Перейдите в Configure Apps | Release Templates и нажмите два раза на
шаблоне Fabrikam Call Center. Будет запущен дизайнер шаблона релиза.
Изображение 36
Настройка шаблона релиза
4. В дизайнере есть набор компонентов и блоков, используемый в развертывании. Нажмите
на Properties.
Изображение 37
Просмотр настроек шаблона релиза
5. В этом окне видно, что шаблон релиза настроен и привязан к определению сборки.
Обратите внимание на опцию инициирования релиза после сборки – эта опция требует
использования модифицированного шаблона сборки и установки Release Management
Client на сервере сборки.
Изображение 38
Просмотр настроек шаблона релиза
6. Нажмите Escape.
7. В рамках лабораторной работы последовательность развертывания упрощена для того,
чтобы показать концепцию. Нажмите на Collapse All для получения доступа к информации.
Изображение 39
Кнопка Collapse All
8. В развернутом виде показывается только сервер VSALM, что означает, что все задачи по
развертыванию выполняются только на нем. Если посмотреть на Toolbox, там есть ветка
Servers, в которой показаны все серверы, доступные для среды выбранной стадии.
Изображение 40
Последовательность развертывания
9. Разверните VSALM. В общем последовательность развертывания включает в себя
удаление существующего веб-сайта из IIS, резервирование данных, копирование с
помощью xcopy результата сборки, создание веб-сайта в IIS и откат в случае ошибки.
Изображение 41
Последовательность развертывания
10. Разверните Remove Web Site. Оно настроено на удаление сайта “FabrikamDev” из IIS.
Изображение 42
Remove Web Site
11. Разверните Copy File or Folder. Оно настроено на резервирование веб-сайта в папку.
Изображение 43
Copy File or Folder
12. Разверните Call Center Site. Это нестандартный компонент, судя по иконке паззла в левом
верхнем углу.
Изображение 44
Call Center Site
13. Посмотрим на этот компонент, перейдя в Configure Apps | Components и нажав два раза
на Call Center Site.
Изображение 45
Просмотр настройки нестандартного компонента
14. На вкладке Source отмечена опция “Builds with application”, что означает, что этот
компонент наследует проект и определение сборки от шаблона релиза. Путь к пакету
развертывания установлен в [Build Drop Location]\_PublishedWebsites\FabrikamFiber.Web.
Изображение 46
Просмотр настройки нестандартного компонента
15. Перейдите на вкладку Deployment.
Изображение 47
Вкладка Deployment
16. Этот компонент использует инструмент XCopy Deployer, функциональность которого
заключена в файле irxcopy.cmd. Свойство Arguments установлено таким образом, чтобы
копировать все исходные файлы развертывания в место, указанное в параметре
Installation Path.
Изображение 48
Просмотр настройки нестандартного компонента
17. Вернитесь в шаблон Fabrikam Call Center и разверните Create Web Site. Оно настроено на
создание сайта в IIS.
Изображение 49
Create Web Site
18. Разверните Rollback. Оно настроено на резервирование и создание веб-сайта в IIS и
выполняется при ошибке.
Изображение 50
Rollback
19. У всех стадий в этом шаблоне релиза идентичная структура, но с разными параметрами.
Изображение 51
Обзор стадии QA
Примечание: в случае, если у стадий похожая структура, вы можете копировать
элементы из одной стадии в другую, вплоть до целых последовательностей
развертывания. Если серверы недоступны на стадии, в которую происходит копирование,
вам будет предложено заменить их на доступные. Скопировать целую
последовательность развертывания можно, нажав правой кнопкой на стадии в Release
Template и выбрав опцию копирования.
20. Посмотрим на доступные инструменты. Перейдите в Inventory | Tools.
Изображение 52
Вкладка Tools
21. Эта вкладка показывает инструменты для выполнения команд с помощью командной
строки, управления файлами и процессами, развертывания баз данных и веб-сайтов,
установки приложений, управления виртуальными машинами в Microsoft Azure и запуска
автоматизированных тестов, определенных в Microsoft Test Manager. Некоторые из них
закодированы в виде скриптов, некоторые содержатся в исполняемых файлах, и вы
можете при необходимости добавить любой из ваших инструментов.
22. Перейдите на вкладку Actions.
Изображение 53
Вкладка Actions
23. Действия – это определенное использование инструмента. Например, несколько действий
используют IIS Deployer для управления IIS.
Изображение 54
Просмотр действий
Упражнение 4: Пример автоматизации
релиза
В этом упражнении вы настроете сборку Team Foundation Server для continuous integration с
учетом того, что она будет автоматически инициировать релиз, и пронаблюдаете всю
последовательность этого релиза через среды разработки, QA и production.
1. Войдите под аккаунтом Brian Keller (VSALM\Brian). Пароль: P2ssw0rd.
2. Запустите Visual Studio 2013 и откройте Team Explorer. Вы должны быть подключены к
командному проекту FabrikamFiber, если этого не произошло, нажмите Connect to Team
Projects (
) и инициируйте подключение.
Изображение 55
Team Explorer – Home
3. Нажмите на Builds.
Изображение 56
Builds
4. Нажмите правой кнопкой мыши на определении сборки “Nightly Fabrikam (Dev)” и
выберите опцию Edit Build Definition.
Изображение 57
Редактирование определения сборки
5. Перейдите на вкладку Trigger.
Изображение 58
Вкладка Trigger
6. Название сборки подразумевает, что приложение собирается каждую ночь, хотя сейчас
сделано так, что для инициирования процесса нужно ручное вмешательство. Выберите
опцию Continuous Integration для сборки при каждом чекине.
Изображение 59
Выбор опции Continuous Integration
7. Перейдите на вкладку Process.
Изображение 60
Вкладка Process
8. Для наших задач с Release Management нужен нестандартный шаблон процесса сборки.
Сейчас выбран шаблон ReleaseDefaultTemplate.11.1.xaml.
Изображение 61
Нестандартный шаблон процесса сборки
Примечание: Шаблон процесса сборки Release Management лежит в папке \Microsoft
Visual Studio 12.0\Release Management\bin.
9. Этот шаблон содержит логику для управления файлами конфигурации с учетом того, что в
решении будет две версии этих файлов. Первая версия – обычный файл конфигурации для
локального развертывания, второй – такой же, но с подставленными вместо стандартных
локальных значениями. Перед сборкой эти файлы будут подменены, чтобы там, куда они
попадут, появился файл конфигурации с нужными значениями.
10. Ниже приведен пример того, как можно это сделать – предположим, в решении есть файл
web.config. Вам нужно скопировать его и назвать web.config.token. Первый файл будет
лежать нетронутым и будет использоваться для локальных развертываний, второй будет
содержать токены вместо значений.
Изображение 62
Пример файла с токенами
11. Вернитесь в конфигурацию сборки. Пролистайте секцию Release Management и обратите
внимание на то, что параметр Release Build выставлен в True. Для того, чтобы при сборке
был инициирован процесс релиза, нужно настроить определение сборки и Release
Management.
Изображение 63
Опция Release Build
Примечание: если нужно делать сборку каждую ночь, есть смысл определить Release
Target Stage во что-нибудь иное, нежели production (development или QA), но для
демонстрации мы оставим production.
12. Нажмите Ctrl + S. Теперь все должно быть готово для того, чтобы работал сценарий
continuous integration, в котором каждый чекин инициирует сборку и релиз.
13. В Team Explorer – Home нажмите два раза на первом решении
FabrikamFiber.CallCenter.sln.
Изображение 64
Открытие решения FabrikamFiber
14. Запустите Internet Explorer и нажмите FF DEV для запуска сайта Fabrikam Fiber,
развернутого в среду development. Версии QA и Production развернуты на этом же
сервере, но имеют другие порты.
Изображение 65
Ссылка на Fabrikam Fiber (среда development)
15. Изменим “Fabrikam Fiber Support” на “Fabrikam Fiber Support v2.0”. Откройте в Visual
Studio файл FabrikamFiber.Web | Views | Shared | _Layout.cshtml.
Изображение 66
Файл _Layout.cshtml
16. Замените содержимое тега h2 на “Support v2.0”.
Изображение 67
Изменение веб-сайта
17. В Team Explorer – Pending Changes нажмите Check In.
Изображение 68
Чекин
18. Если сейчас открыть Team Explorer – Builds, можно увидеть, что чекин инициировал
процесс сборки. Нажмите два раза на сборке.
Изображение 69
Сборка в процессе
19. Дождитесь окончания сборки и нажмите на View Log.
Изображение 70
Ссылка View Log
20. Если пролистать вниз лог, можно увидеть шаги, связанные с Release Management.
Изображение 71
Шаги Release Management
21. Запустите локальный клиент Release Management и перейдите в Releases | Traffic
Overview.
Изображение 72
Загрузка Release Management traffic overview
22. Сейчас план релиза Fabrikam Call Center показывает, что происходит развертывание в
среду development.
Изображение 73
Traffic overview – релиз в процессе
23. Нажмите два раза на стадии “Dev”.
Изображение 74
Подробный обзор traffic view для среды “Dev”
24. Если вы дождались окончания развертывания, вы увидите, что последний релиз (в верху
списка) в среде “Dev” ожидает одобрения.
Изображение 75
Релиз в процессе
25. Как вы уже увидели, шаги подтверждения, развертывания и проверки автоматизированы,
но после них необходимо вручную одобрить переход на следующую стадию. Если
настроить (на виртуальной машине не настроено), Brian Keller получит уведомление об
этом.
26. Нажмите My Approval Requests для просмотра ожидающих одобрения заявок.
Изображение 76
Ссылка на My Approval Requests
27. Нажмите два раза на ожидающем одобрения запросе.
Изображение 77
Ожидающие одобрения запросы
28. Нажмите на View Sequence.
Изображение 78
Ссылка View Sequence
29. Можно посмотреть на последовательность развертывания, чтобы получить информацию
обо всех параметрах, использовавшихся для каждой из стадий – для каждого релиза они
становятся read-only.
Изображение 79
Параметры развертывания
30. Нажмите на View Log.
Изображение 80
Ссылка View Log
31. В логе содержится подробная информация и состояние каждого из шагов в процессе
релиза – развертывание было автоматически подтверждено, инциировано и проверено
для стадии “Dev” и теперь дожидается одобрения. Для шага Deploy есть еще
дополнительная информация – нажмите на (...) в колонке Details.
Изображение 81
Подробная информация для шага Deploy
Примечание: Информацию о последующих шагах можно включить опцией “Include
Future Steps”.
32. В логе развертывания есть информация по выполненным действиям. Нажмите на View Log
для Remove Web Site.
Изображение 82
Просмотр лога по действиям
Примечание: если какое-то действие не было выполнено, то вывод в этом инструменте
должен помочь в отладке проблемы и выяснении, произошла ли она на сервере
развертывания или во время развертывания.
33. Лог показывает, что удаление сайта FabrikamDev было произведено успешно.
Изображение 83
Просмотр лога действий
34. Закройте Notepad и вернитесь в Deployment Log.
35. Перед тем, как одобрять релиз, посмотрим на развернутый сайт в Internet Explorer.
Нажмите на “FF DEV” .
Изображение 84
Ссылка “FF DEV”
36. Мы видим сделанные нами изменения
Изображение 85
Успешно развернутое приложение
37. В Release Management перейдите в My Approval Requests, выберите релиз и нажмите на
Approve.
Изображение 86
Одобрение релиза
38. В диалоговом окне Approval Confirmation введите комментарий “Dev deployment looks
good” и нажмите на OK.
Изображение 87
Добавление комментария
39. Развертывание перейдет на стадию QA и автоматически развернет веб-сайт в
настроенную среду. Дождитесь момента, когда потребуется одобрение.
Изображение 88
Ожидание одобрения для QA
40. После окончания развертывания и автоматической проверки кто-то из команды QA
должен одобрить релиз. Brian – член команды. Зайдите на веб-сайт QA, нажав на ссылку
“FF QA” в Internet Explorer.
Изображение 89
Успешное развертывание в среду QA
41. Нажмите в Release Management в My Approval Requests на Approve.
Изображение 90
Одобрение релиза
42. Введите комментарий “QA deployment looks good” и нажмите на OK.
Изображение 91
Добавление комментария
43. Изучите информацию по “Prod” – переходить никуда не надо, сделайте это с помощью
скриншота ниже. Шаг подтверждения не автоматизирован, как это было в предыдущих
стадиях, что значит, что ответственный за это человек должен явным образом
подтвердить начало развертывания в промышленную среду.
Изображение 92
Конфигурация стадии “Prod”
44. Найдите ожидающий подтверждения запрос в My Approval Requests и обратите внимание
на то, что у Brian есть несколько опций помимо подтверждения - это переназначение
задачи и отказ. Подтвердите развертывание, нажав на Approve.
Изображение 93
Подтверждение запроса на развертывание в production
45. Введите комментарий “Ready for production”. Вы можете выбрать из двух опций –
разворачивать сейчас или запланировать развертывание на позднюю дату. Оставьте
выбранную опцию и нажмите на OK.
Изображение 94
Подтверждение запроса
46. Откройте сайт “FF PROD”. Может понадобиться обновить страницу несколько раз прежде
чем закончится развертывание сборки.
Изображение 95
Успешное развертывание в среду production
47. Теперь команде Ops Team надо проверить развертывание. Выберите запрос и нажмите на
Approve.
Изображение 96
Подтверждение развертывания в production
48. Введите комментарий “Ops approved” и нажмите на OK. У команды Ops может быть
собственный набор тестов для проверки того, что все работает и готово для
использования конечными пользователями.
Изображение 97
Подтверждение развертывания в production
49. Перейдите в Releases | Releases и убедитесь, что проект был развернут в «Prod» и имеет
статус “Released”.
Изображение 98
Сборка была развернута в production
50. Бывают ситуации, в которых есть необходимость в ручном запуске релиза конкретной
сборки. Предположим, что на развернутом в production сайте обнаружили проблемы с
масштабируемостью, и надо, чтобы команда QA провела тестирование в среде QA.
51. Нажмите на вкладке Releases на New.
Изображение 99
Кнопка New
52. Назовите релиз “QA Testing”, выберите шаблон Fabrikam Call Center, выберите стадию QA,
и нажмите на “Select…”.
Изображение 100
Ручной вызов релиза
53. Выберите самую старую сборку в Search Builds.
Изображение 101
Выбор сборки
54. Нажмите на Start (опционально).
Изображение 102
Кнопка Start
55. Если вы выполнили эту последовательсть действий как раньше, то нужная сборка должна
развернуться в среду QA.
56. Подробнее про Release Management: http://www.visualstudio.com/explore/releasemanagement-vs.
To give feedback please write to VSKitFdbk@Microsoft.com
Copyright © 2016 by Microsoft Corporation. All rights reserved.