Hi-Tech  ->  Программирование

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

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

Введение

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

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

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

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

 

Общие шаги и основные моменты при внедрении

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

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

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

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

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

1. Формирование рабочей группы на пилотный проект

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

2. Обучение участников рабочей группы:

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

3. Обследование текущего состояния процессов конфигурационного управления и разработки программного обеспечения, определение целей и задач пилотного проекта

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

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

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

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

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

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

 

История                           из жизни
	Одна крупная организация, которая использовала инструментальные средства IBM Rational, попросила провести обучение разработчиков. Отметим, что компания использует инструментальные средства на протяжении трех лет. Руководству просто надоел то факт, что разработчики жалуются на сложность инструмента, на то, что инструмент «ведет» себя не так, как надо. И так далее и тому подобное. Руководство также захотело, чтобы все участники проекта прослушали самый полный курс из всех возможных. Хорошо. Для нас заказчик почти всегда прав... Сомнения насчет эффективного использования инструментальных средств зародились с самого начала и подтвердились на первой же встрече со специалистами заказчика. Выяснилось, что как такового поставленного процесса в организации нет. А все внедрение свелось к тому, что установили и настроили сервер, настроили клиентские места и начали работать как получится. А получалось вот как: за неимением знаний компания выбрала простую модель организации процесса УК (по default'у). В простой модели при версионном управлении есть только одна ветвь версий файлов и нет параллельной разработки. Подобный подход хорош на первом этапе - когда компания разрабатывает один продукт и у каждого файла или системы есть один владелец. То есть на первом этапе компания не поняла, что идет не в ту сторону... Прошло какое-то время, появились новые заказчики, продукт стал разрастаться. Разработчикам по тем или иным причинам приходилось сталкиваться с проблемой отсутствия параллельной разработки (Петров заболел, а Иванову поручили исправить ошибку в модуле Петрова. Сделал, откомпилировали. Петров вернулся и хочет продолжить работу над своими данными и видит, что в его коде «покопались»). Как следствие - в проекте воцарилась нервозность. Все современные средства УК, IBM Rational, в их числе позволяют избегать конфликтов, но для этого необходимо проработать процесс. Разработчики же компании решили проблему по-своему: они полностью скачивали версии файлов из версионной системы к себе локально и время от времени отдавали данные в проект. Интегратор тут же проставлял метку и проект шел дальше. Обратите внимание, что всем участникам стало ясно, что нужен процесс и специалисты сами начали что-то делать. Мораль: если разработчикам неудобно работать с версионной системой, значит у компании нет процесса УК. В версионной системе не работают, а живут! Еще раз отметим, что разработчики должны находиться все время в версионной системе и не выполнять операции check-in и check-out по принуждению раз в неделю, а делать это по мере необходимости и в любом количестве. История с заказчиком закончилась хорошо. Процесс поставили, а разработчики прослушали не пятидневный курс, а небольшой тренинг на 4-5 часов!

  5. Разработка среды выполнения проекта. Исполнение тестового примера:

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

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

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

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

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

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

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

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

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

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

 

6. Развертывание системы на машины разработчиков

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

7. Выполнение пилотного проекта:

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

 

Заключение

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

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

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

Важно!

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

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

Параметры статьи

Адрес источника: http://www.cmcons.com

постоянная ссылка на статью: http://www.po4itaem.ru/art/213_stat.html