четверг, 13 декабря 2007 г.

Процедура проведения установки новой версии ПО (Deployment WorkFlow)

Хочу предложить вашему вниманию схему установки программного обеспечения:



Инициализация процедуры установки новой версии


Когда инициируют процедуру установки новой версии продукта?

  • достижение определенного этапа работы
  • необходимость установки конкретной версии (допустим возврат к более ранней версии или установка прежней, но на новое оборудование)
  • синхронизация версий на разных платформах, например тестовая и «производственная» (production)

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


Кто инициирует процедуру установки новой версии продукта?

  • Руководитель разработки (Development Lead)
  • Руководитель тестирования (Test Lead)

В основном, это всегда Dev Lead, но могут быть такие моменты, когда это может делать Test Lead (QA Lead). Это может быть случай когда, требуется откатить назад версию, или поставить какую-нибудь старую версию на новый сервер, ну или же просто это будет открыто в виде задачи на установку (Deployment task) о синхронизации версий приложений на тестовой платформе. Для этих целей, не обязательно привлекать Dev Lead.
В любом случае, я думаю, что правильней будет, если и Dev Lead, и Test Lead (QA Lead) будут иметь такие права


Разрешение на установку новой версии


Процедура установки не должна происходить спонтанно, внося смуту в ряды тестировщиков: «Ой, приложение не доступно?» или «А что у нас уже новая версия?». Чтобы этого не произошло, команда тестирования должна быть поставлена в известность о предстоящей установке. Это можно сделать как по средством е-мейла, так и по средством открытия Deployment задачи в Task Management System.
После получения нотификации уже отдел тестирования решает, когда ему будет удобно получить следующую версию. Т.е. добро на проведение установки дается только по завершении запланированной работы над предыдущей версией.


Разрешение на установку отправляется дальше – человеку ответственному за это (Integrator, build master, administrator)

Установка новой версии


Администратор, или билд мастер, или интегратор, в разных компаниях эта роль имеет разное название, производит установку новой версии, только после получения разрешения от команды тестирования. По завершении установки он также высылает нотификацию, что установка завершена и что QA команда может проводить приемочное тестирование или build verification test (BVT).


Приемочное тестирование (build verification test - BVT)


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


В случае, если установленная версия не соответствует критериям качества, команда тестирования вправе забраковать (reject) ее, приложив список ошибок, являющихся причиной отказа от дальнейшего тестирования.
Получив уведомление, что установленная версия была забракована (rejected) командой тестирования, руководитель разработки должен провести анализ причин. И в этом случае, могут варианты дальнейших действий. Если выяснится, что ошибки, послужившие причиной отказа, появились вследствие неправильной установки, т.е. по вине билд мастера, то рекомендуется провести переустановку версии (Redeploy). Если же установка была выполнена корректно и установленная версия действительно не удовлетворяет критериям качества, то проводится откат на предыдущую версию (Roll Back).


В случае, если команда тестирования принимает установленную версию, то на всю проектную группу рассылается сообщение, что версия принята в тестирование.


Переустановка новой версии (Redeploy)


Билд мастер проводит установку новой версии повторно. После проведения переустановки, рассылается сообщение, что версия была установлена повторно и команда тестирования может провести приемочные испытания.


Откат на предыдущую версию (Roll Back)


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


Закрытие процедуры установки новой версии


По завершению установки новой версии или после отката на старую версию, процедуру установки можно считать закрытой.



Примечание:

Конечно же, данный подход можно с легкостью реализовать посредством электронной почты, НО я все же рекомендую все установки проводить через Task Management System.
Для чего это надо?
Все просто – почтовые ящики не долговечны, искать информацию в них зачастую – сущий ад. Имея же, конкретную задачу для установки новых версий (Deployment task) мы получаем не только список и количество установок, но и полную историю установок, дающую нам возможность проводить исследования и пронаблюдать историю проекта уже после его сдачи (или провала).



В компаниях, где я работал в последнее время, такого рода схема и таски были реализованы в Atlassian Jira.



Надеюсь, что данная схема окажется полезной не только мне, но и вам.

Спасибо

2 комментария:

Анонимный комментирует...

Схемка полезная. Ещё мне кажется роли должны быть чётко разграничены, кто иницирует, кто принимает решения (т.е. не DEV lead/QA lead, а именно один), ИМХО! Из опыта: наш PM в одном проекте нарисовал подобную схемку ещё и с именами членов команды - работало :)

Алексей Булат комментирует...

Если вы имеете ввиду первый шаг, на котором инициируется деплой, то этот момент достаточно прозрачен. По хорошему, это всегда Dev Lead, но могут быть такие моменты, когда это может делать QA Lead. Это может быть случай когда, когда требуется откатить назад версию, или поставить какою-нибудь старую версию на новый сервер, ну или же просто это будет открыто в виде Deployment таска о синхронизации приложений на тестовой платформе. Для этих целей, не обязательно привлекать Dev Lead.

В любом случае, я думаю, что правильней будет, если и Dev Lead, и QA Lead будут иметь такие права.

Спасибо,
Алексей Булат

Условия копирования публикаций:

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