Как правильно внедрить управление версиями и изменениями в софтверной организации

 На свете есть столь серьезные вещи, что говорить о них можно только шутя!!!
Нильс Бор,

Автор: Новичков Александр

Все софтверные организации понимают, что изменениями в ПО необходимо управлять. Для этого есть специальные дисциплины и инструментальные средства , которые необходимо использовать.
С течением времени менялось отношение к таким системам... разработчики преодолели большой путь: от «зачем это нужно» до «как я без этого жил». Сейчас все меньше задаются вопросом «зачем», а все чаще спрашивают «как». Давайте в данной статье рассмотрим «как» именно надо внедрить управление конфигурациями (УК)   и остальные процессы жизненного цикла разработки и сопровождения программных систем (программного обеспечения, информационных систем и так далее).

Сама дисциплина управления конфигурациями включает в себя такие важные составляющие, как:

• управление версиями кода (впрочем, как и любых файлов проекта);
• управление изменениями  (то, что в простонародье называется баг-трекинг. Если трактовать «изменение» широко, то в эту категорию попадут и задачи и поручения...);
• управление релизами и поставкой;
• управление отчетами.

Во многих дисциплинах (например, Rational Unified Process, MSF) дисциплина управления конфигурациями объявлена как вспомогательная, то есть она является «цементом» для всего проекта. Следуя этой логике, выведем постулат, что управление конфигурациями есть неотъемлемая часть корпоративной культуры разработки программного обеспечения. И так или иначе качество конечного продукта зависит от того насколько эффективно УК.

1. Выбор методологии, по которой будет управляться проект (важная составляющая. Выбор методики во многом определяет успех или неудачу последующего внедрения ).
2. Выбор инструментальных средств , которые будут применены (важный момент, но второстепенный по отношению к методологии. Здесь нужно руководствоваться тем, как много людей знают тот или иной инструмент , и насколько легко найти квалифицированного специалиста на рынке труда).
3. Выбор проекта, на котором будет происходить апробация (проект должен быть некритичным по срокам и сложности, иначе внедрение завалит основную работу).
4. Последующее развитие технологии в организации (рекомендуется внедрить на чем-то маленьком, а потом тиражировать на что-то большое. Если вы не хотите тиражировать, то бросьте затею внедрения .... НЕЛЬЗЯ внедрить и остановиться на чем-то маленьком - это пустая трата времени и сил).

См. историю из жизни.

Совершенствование процесса управления конфигурациями позволит:

• повысить скорость внесения изменений в ПО;
• повысить качество ПО на выходе (за счет следования регламентам и процедурам)

Внедрение процессов конфигурационного управления (УК) и управления изменениями (УИ)  делится на несколько этапов, которые детализируются на работы.
Рассмотрим основные моменты:

• выбираем самых продвинутых исполнителей и самый простой проект;
• цикл внедрения выбираем по принципу «идем в ширину», то есть не стоит брать что-то одно и внедрять досконально, лучше пройти полный цикл от начала и до конца и получить хоть-какойто ощутимый результат;
• руководствуемся правилом: лучшее - враг хорошего.

• обучение группы основам процесса и инструментальных средств управления версиями (IBM Rational ClearCase, Subversion, MS TFS);
• обучение основам процесса и иснтрументальных средств управления изменениями (IBM Rational ClearQuest, Jira);
• обучение администрированию и сопровождению

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

• уточняются требования к среде выполнения проекта;
• выбирается вариант использование средств конфигурационного управления и методология (Agile, MSF, IBM Rational Unified Process);
• выбирается модель версионирования (не люблю это слово). Проще говоря выбирается одна из моделей версионного управления;
• определяется структура документов, разрабатываемых на следующих этапах;
• определяется структура и способ взаимодействия с группой тестирования при работе с дефектами;
• определяется политика прохождения запросов на изменения, а также формируется ГИП (экранные формы для "вбивания" запросов: задач, багов и пр);
• определяется ролевой состав участников и их права и обязанности в процессе;
• определяются собираемые отчеты и метрики.
• определяются все процедуры: внесение изменений, получения сборок... итд.

Инструментальные средства настраиваются в соответствии с данной концепцией;

• определяется структура каталогов проекта и методы хранения файлов;
• при необходимости (договоренности) разрабатываются приложения к плану (инструкция по установке и настройке, регламенты работ).

Без плана жить нельзя! Многие скажут: опять обязаловка и писанина, кто ж его читать будет?
Скажем этим людям наше твердое: «вы не правы»!!!
Во-первых, пока пишем план в первой редакции (это, как правило, описание текущего процесса, то происходит осознание того правилен процесс или нет. Замечено, что если у людей нет описанного процесса чего бы то ни было, то они, находясь внутри, не могут оценить его правильность или качество (все так привыкли). НО! Стоит описать процесс, как все несуразности «всплывают» на поверхность. После этого уговаривать никого не надо.
Во-вторых, никто не говорил, что план должен быть на 100 страниц. Пусть первая версия будет выглядеть по-детски на 4 страницы. Но она БУДЕТ! Дальше будем развивать.
В-третьих, план   - это бумажное отражение наших словесных договоренностей. Нет на свете лучших договоренностей, чем записанные на бумаге или нарисованные на стене.
И последнее: на основе плана потом будут настраиваться инструментальные средства поддержки конфигурационного управления.

• разрабатывается технология выполнения процесса управления изменениями (типы запросов, схемы прохождения);
• разрабатывается технология выполнения процессов конфигурационного управления;
• разрабатываются описание технологии работ (дорабатывается план);
• на тестовом примере отрабатываются принципы конфигурационного управления (в соответствии с программой обучения).

Разработка плана осуществляется отдельным членом команды - менеджером конфигурационного управления.

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

 a. Осуществление миграции или импорта существующих данных (файлов, релизов, списка ошибок, формализованных планов);

• • формируется репозиторий проекта;
• • осуществляется проверка целостности репозитория ;
• • формируются базовые версии - срезы.

b. Реализация политики конфигурационного управления на основе написанного плана:

• определяется структура доступа к объектам конфигурационного управления (ОКУ);
• настраиваются права доступа к версионным хранилищам;
• разрабатываются скрипты автоматизированной отчетности;
• разрабатываются скрипты ограничения доступа к элементам репозитория ;
• формируются нотификационные и запретительные скрипты, четко определяющие права и обязанности участников проекта;
• определение правил рассылки уведомлений по электронной почте.

c. Настройка интеграции между версионной системой и системой управления изменениями для полноценного управления версиями и изменениями
Здесь имеется ввиду, что полный процесс УК может автоматизироваться несколькими программными связками: версии - изменения - сборки - отчеты.
Такой связкой могут быть: IBM Rational ClearCase +ClearQuest или Subversion + Jira.

d. Реализация программы управления сборкой:

• формируется процедура управления сборкой;
• формируется процедура проверки целостности билдов;
• выпуск стандартной версии ПО;
• при необходимости разрабатываются дополнительные сборочные скрипты.

a. инсталляция инструментов
b. подключение к репозиторию

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

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

Нормативная база успешного внедрения :

• стандарт ISO 12207;
• методики: IBM Rational Unified Process, Agile, MSF и прочие;
• руководства по эксплуатации систем поддержки процесса управления конфигурациями: ClearCase, ClearQuest, Jira, Subversion...

Важно!

Самое главное не допускать классической ошибки всех начинающих, а именно - избегать внедрение чего-бы то ни было от инструментов. "Давайте поставим тулы, а дальше как пойдет..." - это путь в могилу. Сначала нужно ПОДУМАТЬ, что и как будет в процессе, и только потом ПОД ЭТОТ процесс выбирать и устанавливать инструментальные средства.