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

На світі є такі серйозні речі, що говорити про них можна тільки жартома!
Нільс Бор,
Автор:Новачків Олександр
Введення
Всі софтверні організації розуміють, що змінами до ПЗ необхідно управляти. Для цього є спеціальні дисципліни та інструментальні засоби, які необхідно використовувати.
З плином часу змінювалося ставлення до таких систем ... розробники подолали великий шлях: від «навіщо це потрібно» до «як я без цього жив». Зараз все менше задаються питанням «навіщо», а все частіше запитують «як». Давайте в цій статті розглянемо«Як»саме треба впровадити управління конфігураціями (КК) І інші процеси життєвого циклу розробки і супроводу програмних систем (програмного забезпечення, інформаційних систем і так далі).
Сама дисципліна управління конфігураціями включає в себе такі важливі складові, як:
управління версіями коду (втім, як і будь-яких файлів проекту);
управління змінами (те, що в народі називається баг-трекінг. Якщо трактувати «зміна» широко, то в цю категорію потраплять і завдання та доручення ...);
управління релізами та поставкою;
управління звітами.
У багатьох дисциплінах (наприклад, Rational Unified Process, MSF) дисципліна управління конфігураціями оголошена як допоміжна, тобто вона є «цементом» для всього проекту. Слідуючи цій логіці, виведемо постулат, що управління конфігураціями є невід'ємна частина корпоративної культури розробки програмного забезпечення. І так чи інакше якість кінцевого продукту залежить від того наскільки ефективноКК.
Загальні кроки і основні моменти при впровадженні
Вибір методології, за якою буде управлятися проект (важлива складова. Вибір методики багато в чому визначає успіх чи невдачу подальшого впровадження).
Вибір інструментальних засобів, які будуть застосовані (важливий момент, але другорядний по відношенню до методології. Тут потрібно керуватися тим, як багато людей знають той чи інший інструмент, і наскільки легко знайти кваліфікованого фахівця на ринку праці).
Вибір проекту, на якому відбуватиметься апробація (проект повинен бути некритичним за термінами і складності, інакше впровадження завалить основну роботу).
Подальший розвиток технології в організації (рекомендується впровадити на чомусь маленькому, а потім тиражувати на щось велике. Якщо ви не хочете тиражувати, то киньте затію впровадження .... НЕ МОЖНА впровадити і зупинитися на чомусь маленькому - це марна трата часу і сил).
Див. історію з життя.
Удосконалення процесу управління конфігураціями дозволить:
підвищити швидкість внесення змін в ПЗ;
підвищити якість ПЗ на виході (за рахунок проходження регламентам і процедурам)
Впровадження процесів конфігураційного управління (КК) та управління змінами (УІ) ділиться на кілька етапів, які деталізуються на роботи.
Розглянемо основні моменти:
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 ...
Важливо!
Найголовніше не допускати класичної помилки всіх початківців, а саме - уникати впровадження чого-б то не було від інструментів. "Давайте поставимо тули, а далі як піде ..." - Це шлях в могилу. Спочатку потрібноПОДУМАТИ, Що і як буде в процесі, і тільки потім ПІД ЦЕЙ процес вибирати і встановлювати інструментальні засоби.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Список рекомендованої літератури	\|	Система планування інновацій, сутність і основні види

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.003 сек.