Ящики

Зміст


Процес переїзду в новий будинок є однією з найкращих ілюстрацій закону Мерфі. Якщо яка-небудь неприємність може трапитися, вона трапляється. Можна витратити тижні, займаючись підготовкою, упаковкою та маркуванням своїх речей в кожній кімнаті будинку, викидаючи непотрібний мотлох, каталогізіруя всі предмети, з максимальною обережністю пакуючи всі крихкі речі. Однак, незважаючи на всі зусилля, ці речі все одно губляться, б'ються й ламаються. Іноді, щоб краще впоратися зі змінами такого роду, потрібно заздалегідь підготувати себе до будь-яких дрібниць і мати план вирішення таких питань з самого початку переїзду в новий будинок.


Неможливо плавно перейти від однієї з безкоштовних систем управління конфігурацією (Configuration Management, CM) до ClearCase так, щоб при цьому група розробки взагалі не помітила б різниці. Перехід до новій системі управління конфігурацією може сильно змінити світогляд деяких інженерів компанії. Він вимагає від них зміни способу мислення щодо процесу розробки. По суті, це може вплинути і на їхній спосіб життя.


Як правило, розробники програмного забезпечення дуже сильно прив'язані до свого способу розробки ПЗ. Дуже часто доводиться чути такі висловлювання: "Я займаюся розробкою ПО більше 25 років, так навіщо мені потрібно щось змінювати? ". Не будемо обговорювати тут проблему" якості ПЗ "в цілому. Плануючи зміна CM-системи, потрібно пам'ятати про те, що доведеться мати справу з людьми, яким не подобаються зміни, а такий перехід спричинить за собою істотну зміну їхнього способу роботи.


У даній статті планується висвітлити наступні аспекти переходу до нової CM-системі:



  1. розуміння існуючої системи та її використання, включаючи стратегії розгалуження, збірку і тестування;
  2. виконання переходу в автономному режимі для перевірки переносимості невеликих частин системи;
  3. виконання переходу в автономному режимі для перевірки переносимості всієї системи в цілому;
  4. проведення бета-тестування з деякими з розробників-випробувачів компанії для перевірки того, що випробовується, система працює в нормальному режиму (включаючи всі конструкції, розгалуження і т.д.);
  5. реалізація самого переходу, зі збереженням старої системи для забезпечення сумісності.

Перед переходом до нової системи рекомендується звернути увагу на наступні дві поради.



  1. Не піддавайтеся спокусі написати сценарії, змушують ClearCase виглядати так само, як попередня CM-система. Зазвичай це призводить до необхідності супроводжувати велику кількість заплутаних сценаріїв, а також до уповільнення роботи системи або ускладнення її обслуговування. Намагайтеся уникати такого підходу.
  2. Після переходу до ClearCase використовуйте цю систему за призначенням. Це звучить досить просто, проте багато людей з самого початку намагаються модифікувати систему. Не слід рядити жирафа так, щоб він був схожий на слона. Жираф залишається жирафом незалежно від кольору, в який його пофарбували. Перш ніж приступити до використання, необхідно розібратися, як система працює, а потім разом з інженерами компанії провести необхідні зміни процесів для налаштування даного інструменту.

Планування переходу


Розуміння поточної CM-системи


Добре, коли всі речі упаковані, будинок проданий, а машина заправлена і готова їхати, тобто, коли прийнято остаточне рішення про перехід до ClearCase. Незалежно від вживаються дій такий перехід призведе до зміни парадигми розробників компанії. Їм доведеться освоїти нові способи роботи. Наприклад, зміниться стандартний набір команд. Перш ніж переходити до ClearCase, краще спочатку розібратися, як ці системи працюють, як вони відображають поточні процеси, як їх обмеження вплинуть на групу розробки компанії.


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


Файлова система: не має контролю версій


Така ситуація є гіршою з точки зору управління змінами конфігурації при роботі в групі, однак, іноді це дуже сильно прискорює роботу окремих розробників. Використання файлової системи тільки для зберігання програмного коду не дозволяє повністю реалізувати всі переваги від використання функціональних можливостей CM-системи. Це не обов'язково погано, так як таке положення суттєво полегшує процес навчання групи розробників. У цьому випадку люди, що не володіють завищеними вимогами, схили до більш швидкому прийняттю системних оновлень. Однак проблема полягає в тому, що необхідно не лише навчати інженерів використання ClearCase, але потрібно також навчити їх основам управління конфігурацією.


Система контролю джерел коду SCCS (Source Code Control System)


Система контролю джерел коду зазвичай поставляється разом з операційною системою. Для ОС UNIX вона є початковою точкою для контролю версій. Стандартний набір команд є дуже великим і для багатьох інженерів набагато простіше використовувати систему контролю змінених версій RCS, яка обговорюється в наступному пункті. Цей інструмент зазвичай використовується для невеликих проектів, тому що він не дозволяє кільком розробника одночасно працювати з одним і тим же файлом. Відхід від використання даного інструменту полягає в вивченні декількох нових команд і нової концепції уявлень, замість прямої роботи з файловою системою. Крім того, система SCCS не має контролю версій каталогів.


Система контролю змінених версій RCS (Revision Control System)


Ця система простіше, ніж SCCS, але вона має більшість тих же самих обмежень, таких як однокористувацький доступ до одного файлу. Система RCS простіше в налаштуванні, і в ній легше знайти обхідні шляхи, якщо вони знадобляться. І тут криється основна складність, з якою зіткнутися інженери компанії при переході з системи RCS. Вони будуть продовжувати намагатися отримати прямий доступ до сховища уявлень і каталогу VOB-сховища для внесення раніше відкладених змін. Так влаштована система RCS. Необхідно бути уважним у відношенні таких конструкторських спонукань.


Паралельна система контролю версій CVS (Concurrent Versioning System)


Дана система є надбудовою над RCS і володіє додатковими властивостями, що дають можливість маркування коду та паралельного доступу до одного файлу. Цей інструмент набагато ближче до ClearCase, але він не дозволяє користувачам працювати з динамічними уявленнями. Всі ці системи не дають розробнику побачити зміни, що вносяться його колегами, до закінчення їх роботи з файлами. На відміну від них ClearCase дозволяє переглядати такі зміни в реальному часі. Знову-таки, в системі CVS відсутній контроль версій каталогів.


Система Source Safe


Дана система була розроблена компанією Microsoft для використання з Visual Studio та іншими своїми компіляторами, але вона не підтримує багато з тих можливостей, які є в ClearCase. Зазвичай, перехід від Source Safe має багато спільних проблем з переходом від системи CVS, але тільки в цьому випадку вони виникають у користувачів ОС Windows, а не UNIX.


Тепер, коли є уявлення про основні відмінності між цими CM-інструментами, можна обговорити процес роботи з ClearCase. Якщо коротко, то звичний спосіб використання моделі повинен зміниться. Зміни торкнуться всього – і того, як група розробки буде використовувати CM-систему, і того, як нова система буде працювати з іншими системами. Не потрібно намагатися підганяти ClearCase під старі способи роботи. ClearCase не призначена для того, щоб працювати як більшість інших систем. Рекомендується прочитати статтю "Усунення розриву між CM-системами: використання інструменту Case Analysis – нової системи управління конфігурацією ", щоб отримати уявлення про те, як приступити до роботи, проаналізувавши поточну систему. Залежно від раніше використовувалася CM-системи майбутні зміни можуть бути маленькими або великими. Є кілька моментів, на які потрібно звернути увагу для того, щоб зрозуміти, що ж має бути зроблено, перш ніж перейти від поточної системи до чогось нового.



Нарешті розглянемо план міграції до нової системи. Для цього необхідно пам'ятати про основні вимоги при підготовці такого переходу. Нижче обговорюються деякі з них.


Апаратні вимоги


Простір на жорсткому диску


При переході від будь-якої системи до ClearCase потрібно пам'ятати про те, що для його виконання потрібно мати достатньо велику кількість вільного простору на жорсткому диску. Як правило, вільного місця має бути, принаймні, в 2,5 рази більше, ніж займає поточна CM-система. Цього має вистачити і для поточної системи, і для файлів перетворення, і для нових даних системи ClearCase.


Центральний процесор


Слід пам'ятати про те, що ClearCase відрізняється від більшості інших систем. Система ClearCase є додатком типу клієнт-сервер, тому потрібно враховувати те, що вона вимагає більш потужного процесора, ніж більшість подібних систем. Керівництво по роботі з ClearCase містить повну інформацію про апаратні вимоги до VOB-і View-серверів і настільних комп'ютерів групи розробки. Необхідно ретельно розібратися з відмінностями між вимогами для цих серверів і належним чином розподілити наявні ресурси.


Пропускна здатність каналів введення-виведення


Системні затримки критично впливають на продуктивність ClearCase. Можна мати дуже швидкі комп'ютери як VOB-і View-серверів, а продуктивність ClearCase як і раніше буде залишатися дуже низькою. Ретельний аналіз подібної ситуації зазвичай виявляє низьку пропускну здатність локальної мережі або каналів введення-виведення жорсткого диска. Її просто може не вистачати для забезпечення необхідної продуктивності. VOB-сервери повинні мати найшвидшу мережеву магістраль, яку тільки може собі дозволити компанія. View-сервера повинні мати майже таку ж швидку мережу. У налаштуваннях мережевого комутатора необхідно заборонити автоматичне регулювання пропускної здатності мережі. В іншому випадку швидкість з'єднань за замовчанням встановиться на мінімально можливу величину. Для забезпечення максимальної швидкості роботи комутатора і мережевого інтерфейсу серверів необхідно знайти і нейтралізувати всі "вузькі місця" в корпоративній мережі.


Сценарії системи створення та тестування коду


Необхідно добре собі уявляти, наскільки діюча система створення та тестування програмного коду прив'язана до поточної CM-системі. Крім усього іншого, потрібно розуміти, що ця система – щось більше, ніж просто інструмент для компіляції та тестування коду. Вона також виконує і деякі інші функції:



Не можна забувати про те, що при переході до нової CM-систем змінюються як сам інструмент, так і основа, що протікають, з якими з дня на день працюють розробники компанії.


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


Інтегрована чи поточна CM-система з системою CRM (управління взаємодією із замовниками)? Чи є в ній система відстеження дефектів і модернізації? Якщо стара CM-система інтегрована з системами такого типу, то точки інтеграції залишаться тими ж або зміняться? У більшості випадків спосіб використання цих систем буде іншим після переходу до нової CM-системі. Якщо моделі Use Model зміняться, то, швидше за все, зміниться і наявна інтеграція. Тому, при плануванні переходу до нової система необхідно виділити окремий час на оновлення інтеграції з допоміжними системами.


Час простою


Після того, як будуть готові нова модель Use Model і план реалізації проекту знадобитися ще пара місяців, щоб завершити заміну. На жаль, керівництво компанії не може дозволити собі призупинити процес розробки на ці два місяці для переходу до нової CM-системі. Тому відповідальному за перехід персоналу доведеться понаднормово працювати у вихідні дні.


Ось чому планування так важливо. Потрібно заздалегідь намагатися зробити якомога більше роботи в "тіньовому" режимі поряд з поточними процесами розробки. Це дасть можливість випробувати нову систему до переходу на неї всіх розробників. Потрібно пам'ятати про те, що на остаточне настроювання і запуск нової системи зазвичай йде 3-4 дні. Таким чином, завчасне планування і тестування є важливими складовими успішного переходу до нової системи.


Навчання персоналу


Не слід робити ніяких попередніх припущень про рівень підготовки групи розробки – кожен повинен пройти певну тренування на новій системі, незалежно від свого досвіду. Навіть ті, хто володіє 7 річним досвідом роботи з ClearCase, могли мати справу з більш старою версією, так що, для роботи на новій системі їм теж знадобитися деяка тренування (хоча і не така, як для тих, хто взагалі не знайомий з даною системою).


Під час створення нової моделі Use Model слід залучити до роботи відповідальних за зміни ключових представників відділу розробки компанії. Вони повинні стати групою підтримки для інших співробітників при переході на нову систему. Це значно спростить процес переходу для всіх розробників.


Цілком ймовірно, що перехід на нову CM-систему надасть дуже сильний вплив на розробників компанії. Люди не люблять зміни, але якщо правильно інформувати їх, вони будуть прагнути до кращого стилю роботи. Краще всього за тиждень до переходу від старої системи до нової провести навчання, ознайомивши всіх розробників з концепціями ClearCase, відмінностями між старою і новою системами, а також новою моделлю Use Model. Однак не слід проводити таке навчання дуже рано, тому що люди будуть зайняті іншою роботою, а за відсутності можливості швидко застосувати нові знання вони швидко втратять їх, і тоді більшість переваг від тренування буде згаяно. Для забезпечення конструктивної зворотнього зв'язку з персоналом та задоволення потреб у додатковому навчанні оптимальним буде також проведення подібного навчання незабаром після остаточного настроювання нової CM-системи. Ці додаткові заняття слід запланувати заздалегідь, щоб уникнути зайвого потоку виникаючих питань від кожного розробника окремо, що буде тільки заважати нормальній роботі групи розробки.


Зміна сценаріїв


Хоча вище вже згадувалася небезпека, пов'язана з поточними сценаріями для розробок при переході до щойно розгорнутої середовищі ClearCase, про це варто згадати ще раз. Не варто намагатися використовувати ClearCase в точності такий же спосіб, як систему RCS. Такий підхід заздалегідь невдалий. Це було б подібно до того, як використовувати столовий ніж до якості викрутки – ніж неминуче повинен зігнутися. Подібне використання ClearCase призведе до значного погіршення роботи нової системи управління вихідними програмними кодами.


Сценарії дуже зручні для автоматизації стандартних операцій, але не слід повністю ховати за ними всю систему ClearCase. Краще відповідним чином навчити розробників компанії, ніж створювати у них уявлення, що ClearCase – це великий, чорний ящик, про який все знає тільки один його "маг-адміністратор". Багато хто схильний вважати, що створення і підтримка сценаріїв робить роботу більш безпечною. Однак у випадку ClearCase такий стиль роботи не ефективний, так як він вимагає занадто багато уваги і зусиль.


Слід уникати таких ускладнень і стежити за тим, що обрана модель Use Model використовувалася належним чином.


Перенесення даних


У всі версії ClearCase, починаючи з 4.1 (http://www.interface.ru/rational/cc/rclearc4.htm), компанія Rational додала кілька міграційних сценаріїв, щоб допомогти виконати перенесення даних від однієї CM-системи до іншої. Таке переміщення відбувається у два основних етапи.



  1. Експорт з поточної CM-системи (clearexport_ *, див. подробиці в довідковому керівництві для ClearCase).
  2. Імпорт в ClearCase (clearimport, див. подробиці в довідковому керівництві для ClearCase).

Малюнок 1.


Не має значення, яка з команд clearexport_ * використовується. Кожна з них створює проміжний файл під назвою cvt_data. Формат цього файлу є загальновживаної і команда clearimport його розуміє. Вона читає файл cvt_data для того, щоб визначити, як створити відповідні елементи і сегменти.


Що потрібно експортувати


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



Від відповідей на ці питання залежить те, як буде проходити експорт даних. Якщо потрібно зберегти повну історію файлів, то експорт та імпорт даних будуть довгими, до того ж не вся інформація може виявитися сумісної з ClearCase. Кожна програма експорту має різні обмеження. Тому спочатку потрібно прочитати керівництво для програми експорту, яку планується використовувати. Після завершення імпорту слід перевірити, чи вся інформація була перенесена коректно. У залежності від того, як велика повна історія файлів, планована для перенесення, весь процес може зайняти досить велику кількість часу.


Перш ніж відмовитися від зберігання повної історії, слід звернути увагу на зворотний бік зберігання лише резервної копії самої останньої інформації зі старої CM-системи. Особливо новачкам слід знати про те, що навіть у разі зберігання резервної копії все одно якийсь час доведеться підтримувати обидві системи. Більш того, тимчасова підтримка обох систем необхідна для того, щоб надати інженерам необхідний час для завершення переходу. Тому не рекомендується використовувати даний вибір крім випадків, коли розробка перебуває в стані, в якому підтримка попередніх версій не потрібна, або під час переходу від прототипу до першого випуску продукту.


Експорт даних


ClearCase підтримує програми для експорту, сумісні з версіями ClearCase 5.x. Слід зазначити, що ці програми для експорту в дійсності не імпортують інформацію в базу даних VOB, а створюють спеціальний файл даних, який може бути перетворений з допомогою команди clearimport.



У всіх цих випадках створюється спеціальний файл даних. Цей файл використовується для імпорту інформації в базу даних VOB системи ClearCase. Цей файл даних можна аналізувати і модифікувати для того, щоб привести у відповідність із запитами поточного переносу.


Тестування перед перенесенням


Перш ніж переносити в ClearCase всю систему цілком, слід спочатку зробити це для невеликої ієрархії каталогів старої системи і переконатися, що перетворення дає очікувані результати. Потрібно пам'ятати про те, що якщо результати не виправдали очікування, то завжди є можливість внести відповідні корективи у файл даних перш, ніж робити імпорт. Фактично, краще всього намагатися це зробити кілька разів до того, як виробляти перенесення всієї системи. Крім того, такі невеликі тести дають можливість оцінити час, необхідний для перенесення всієї системи.


Пробний запуск


Після завершення тестування кожного компонента слід переконатися в тому, що вся система продовжує працювати належним чином. Наскрізне тестування має проводитися без порушення поточного процесу розробки. Потрібно бути готовим час від часу запускати тестовану систему в "тіньовому" режимі – паралельно з діючою системою. Слід залучити пару розробників для роботи з системою в режимі "Обкатки" та проведення кількох повноцінних тестів. Немає нічого гіршого ситуації, коли ціна занедбаної нова система не повністю працездатний. Це не тільки згубно позначається на продуктивності і збиває розробників з пантелику, але також може призвести до випуску неякісних продуктів з відповідними кадровими рішеннями з боку керівництва. Тому необхідно переконатися в тому, що кожен сценарій був відпрацьований, і всі функціональні можливості нової системи були ретельно протестовані, включаючи процедури розробки, складання, тестування та деблокування. Фактично потрібно зробити все можливе для перевірки стійкості системи. Найсуворіші тести зроблять її тільки надійніше.


Підйом важких вантажів


У початковий період звикання персоналу до нової системи з'явиться багато скарг. До цього треба бути готовим і запланувати час на проведення додаткового навчання, урахуванням інших можливих затримок. Досвід показує, що до 50% усього часу розгортання нової системи потрібно відвести на обслуговування такого роду скарг. Навчання персоналу має бути основним пріоритетом. Не варто на кожну скаргу намагатися розробити окремий сценарій.


Неминуче деякі розробники будуть відчувати незручності при роботі з новою системою. Це не можна ігнорувати і, в той же час, слід переконатися, що вони розуміють, що система тепер діє саме таким чином, і що необхідно до цього пристосуватися. Потрібно твердо дотримуватися своєї позиції. Необхідно бути готовим до виникнення всебічного тиску, спрямованого на зміну, підгонку і модифікацію нової системи з тим, щоб все більш-менш стало подібно старій системі. Знову-таки, навчання має бути першим зброєю в боротьбі з цими скаргами. Після того, як персонал зіткнеться з такою жорсткою позицією щодо нової системи ситуація почне потроху заспокоюватися. Розробники почнуть гідно оцінювати системні поліпшення і розширення функціональності.


Перехід від однієї системи управління вихідними програмними кодами до іншої ніколи не був простим завданням. Однак при належному плануванні і підготовці група розробки зможе впоратися зі змінами при мінімальних втратах.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*