ClearCase – система конфігураційного і версійність контролю, Різне, Програмування, статті

Зміст


Частина 1:
Введення
Опис можливостей
Частина 2:
На чому заснована програма
Інтеграція з засобами розробки
Додаткові можливості
Web-інтерфейс
Деякі особливості ClearCase
Частина 3:
Особливості створення видів
Довідкова інформаціяВисновок
Додаткова інформація

Введення


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


Всі ці рішення в сукупності складають RUP (Rational Unified Process) – Методологічну енциклопедію, в якій описані всі етапи створення якісного програмного продукту. Користуючись подібної енциклопедією і застосовуючи відповідні інструменти, рекомендовані Rational, можна створювати програмні продукти якісно і в строк.


Особливе місце в RUP займає SCM (Source Code Management) – управління вихідним текстом. SCM описує спосіб контролю і супроводу інформації, що становить програмний проект. SCM – це методологія, яку підтримує продукт ClearCase, призначений для відстеження та детального протоколювання всього, що пов’язано зі зберіганням всіх артефактів, які супроводжують проект (тут і далі термін “артефакт” слід трактувати як “зберігається документ”. Працюючи над проектом, кожен учасник створює певний набір файлів-артефактів: документів, вихідних текстів, бінарних файлів і т.д.).


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


Опис можливостей



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

Рис 1. Головне вікно ClearCase.
Одне з безперечних достоїнств ClearCase – гнучкість в налаштуванні. Зверніть увагу на русифіковані пункти меню – вони створені виключно за допомогою стандартних можливостей продукту


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


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


Маючи в своєму розпорядженні ClearCase, кожен учасник проекту отримує доступ як до всіх файлів проекту, так і до певної його частини. Більш того, за допомогою спеціальних налаштувань один і той же учасник може отримати доступ до конкретної версії файлу із потрібного проекту. Таким чином, при використанні ClearCase стає можливим редагування абсолютно будь-яких версій файлів, що входять до складу того чи іншого проекту. Для досягнення подібного ефекту ClearCase використовує потужну систему настроюваних фільтрів (у системі вони називаються ВИДАМИ – VIEWs), що приховують непотрібну інформацію. Ідеологія програми досить проста: по-перше, будь-які зміни залишаються в базі даних, по-друге, в будь-який момент можна перейти до будь-якої версії, якщо поточна містить багато помилок

Рис. 2. Створення виду.
На етапі створення виду розробник вибирає його тип і місце зберігання локальних службових даних


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

Рис. 3. ClearCase Details.
Основне вікно при роботі з даними. Тут зосереджені всі керуючі елементи і підконтрольні дані. Додатково ClearCase підтримує інтеграцію і зі звичайним Експлорером через систему контекстних меню


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


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


Крім того, ClearCase дозволяє об’єднувати географічно віддалені команди розробників допомогою додаткового модуля MultiSite, що здійснює реплікацію (передачу) поточного стану проекту на зазначений сайт. Тобто якщо команда дуже розкидана географічно, то MultiSite дозволить синхронізувати проект через Інтернет для всіх команд розробників.


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

Рис. 4. Вікно дерева версій для одного файлового елемента.
Кожен гурток є версією редакції, а червоні стрілки вказують на об’єднання версій


ClearCase забезпечує тісну інтеграцію з продуктами самої Rational (Rational Rose 2001, SoDA, Rational ClearQuest, RequisitePro), Із засобами розробки та офісними додатками компанії Microsoft (Visual C + +, Visual Basic, MS Word), а також з продуктами інших компаній (більш докладні відомості про питання інтеграції та сумісності ClearCase із засобами розробки можна знайти на сайті www.interface.ru).


На чому заснована програма


Для реалізації повного контролю над версіями в спеціальну базу даних – VOB (Version Object Base) – заносяться всі зміни даних проекту.


Репозитарії, що зберігають всю проміжну інформацію про стан проекту, можуть перебувати в локальній мережі як на одному комп’ютері, так і окремо. Фізично VOB являє собою якусь файлову структуру, закодовану особливим чином. Основою VOB є елементи, що представляють собою файли або каталоги. Елемент повинен і може мати одну або декілька версій.


Всі елементи VOB мають свою унікальну версію. При створенні VOB отримує певний набір характеристик, на підставі яких в подальшому можна визначити (при наявності відповідних повноважень) історію його створення. Над VOB можна здійснювати операції монтування / демонтування, створення / видалення. Для роботи з конкретним репозитарієм кожен учасник монтує його на своєму комп’ютері.


Створення однієї тільки бази даних для повноцінної роботи в ClearCase недостатньо, необхідний також клієнт для доступу до неї. Для всіх маніпуляцій над базою даних, у відповідності з правами користувачів, застосовується механізм настроюваних видів (VIEW), що є технологічним засобом фільтрації знаходиться в VOB інформації і перетворює все підмножина елементів зі своїми версіями в вигляд, зрозумілий не тільки машини, але і людині. Такий підхід дозволяє розробнику або технічному письменникові бачити не всі файли, що становлять проект, а тільки необхідні для вирішення конкретного завдання. Таким чином, ClearCase дозволяє досить легко абстрагуватися від поточного стану і зосередитися на певній частині проекту.


Виключно через систему видів можливі всі операції, властиві не тільки ClearCase, а й будь-якого іншого засобу версійність і конфігураційного контролю, такі як установка контролю файлу (Add To Source Control), при якому для кожного елемента створюється дерево версій, операції Check-in і Check-Out, що дозволяють редагувати окремий файл, створюючи дерево версій, на якому відображена повна історія розвитку окремого елемента.

Рис. 5. Історія редагування файлу


Крім цього ClearCase забезпечує менеджерів проекту і розробників спеціальним модулем звітності, за допомогою якого можна отримувати довідкову інформацію про історію редагування того або іншого елемента окремо або групи елементів. Звіт може бути експортований в Microsoft Word (за допомогою інструменту SoDA), виведений на екран або опублікований в Інтернеті.


Види в програмі представлені двома типами – Dynamic і Snapshot, що мають свої переваги і недоліки, але при спільному використанні здатними відкрити нові можливості в контролі над файлами.


Специфіка виду Dynamic полягає в тому, що даний вид (Windows NT, UNIX) створює віртуальну файлову систему, на якій розміщуються всі підконтрольні дані. Сама файлова система розміщується також на віртуальному диску, фізично розміщеному на сервері. Для кінцевого користувача в цьому випадку робота з таким видом зведеться до роботи з новим мережевим диском.


Даний спосіб дозволяє здійснювати контроль над файлами в реальному масштабі часу. Основні переваги даного способу представлені перенастраиваемой видами. Ефективність використання особливо яскраво проявляється Dynamic View у випадках, коли менеджерам необхідно одночасно контролювати кілька проектів, або для налаштування конфігурацій, коли необхідно підтримувати однакові версії вихідних файлів для різних операційних систем.


Вид типу Snapshot виправдовує свою назву, створюючи “знімок” поточного стану проекту на локальній машині. Розробник отримує на своєму диску точну копію або всього проекту, або необхідної його частини – Файлу, групи файлів … Важливим моментом при такій роботі є синхронізація локальних даних із загальним проектом, яка в даному випадку виконується не автоматично, а по команді користувача. Це робить можливої ​​віддалену роботу над проектом, дозволяючи будь-якому розробнику взяти матеріал “на дім”, після чого повернути нові версії файлів в проект.


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


Як уже говорилося раніше, для кожного файлу створюється дерево версій. Дерево складається з кореня і версійність відгалужень. Тут слід зазначити два різновиди відгалужень: просте відгалуження (Branch), створюване для окремого файлу і в будь-яких кількостях, і головне відгалуження (Private Branch) – для всього проекту, коли створюється нова гілка (може бути тільки одна) для всіх файлів, що становлять проект.


Для об’єднання версій в ClearCase передбачена спеціальна утиліта – MergeManager – менеджер злиттів, який під контролем менеджера проекту збирає з двох наданих файлів один. Збірка здійснюється або автоматично (тривіальна збірка), коли відмінності між файлами невеликі, або з обраної менеджером проекту рядку коду для злиття (нетривіальна збірка). Після закінчення злиття створюється нова версія, яку далі також можна правити, об’єднувати з іншими версіями, робити відгалуження.


Злиття файлів можна робити як з ClearCase, так і з командного рядка. Допускається злиття тільки текстових файлів.


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


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


Особливо хочеться відзначити можливість складання проекту. За допомогою утиліти OMake можлива збірка проекту в виконуваний модуль. Утиліта працює з командного рядка і не залежить від типу використовуваного компілятора, головне – щоб його можна було викликати з командного рядка. При цьому сценарій складання базується на звичайних make-файлах.


Інтеграція з засобами розробки



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


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


Таким же чином інтеграція відбувається з Microsoft Word і Microsoft Front Page. В останніх двох випадках з’являється можливість злиття не тільки текстових файлів, але і файлів з розширенням DOC, XML, HTML.


В цих пакетах вбудовування виглядає так само, як і в Visual Studio, – всі функції контролю версій доступні через їх головне меню.


Додаткові можливості



Компанія Rational допомогою RUP регламентує всі етапи розробки програмного забезпечення, що об’єднує в собі всі знання і досвід. Для кожного з наведених у RUP етапів компанією Rational створено спеціальне програмне забезпечення, зокрема ClearCase. Розширивши його за рахунок деяких програмних продуктів або додаткових модулів, можна отримати деякі додаткові можливості.


Розглянемо продукти і модулі, які можна використовувати спільно з ClearCase.



Web-інтерфейс



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

Рис. 7. Тут наведено початкове вікно, де користувач вибирає локально збережені дані проекту та ім’я виду, до якого здійснюється підключення клієнта


Інтерфейс програми простий і зрозумілий, спосіб роботи також не викликає складнощів: всі необхідні для роботи файли переносяться на локальний комп’ютер і модифікуються будь-яким відомим способом. Доступ до тим чи іншим файлам репозитарія здійснюється за допомогою вибору відповідного виду, попередньо фізично створеного на сервері (наприклад, окремий вид для розробників, технічних письменників і т.д.). Відредаговані файли повертаються назад в систему. Web-доступ організовується c допомогою Internet Information Server або Web-серверів Netscape

Рис. 8. Так виглядає вікно роботи з проектами.
У верхній частині браузера – найменування доступних в даний момент операцій


Деякі особливості ClearCase



Багато чого з вишеоопісанного, можливо, вже знайоме читачам, застосовували подібні засоби контролю і управління.


Хочеться ще раз відзначити особливість використання ClearCase в Windows NT: цей продукт має потужний графічним призначеним для користувача інтерфейсом і потужним інтерфейсом командного рядка. Відповідно кожна операція може бути виконана двома різними способами. Командний рядок дозволяє підлаштовувати продукт під конкретні потреби конкретної компанії. Без допомоги командного рядка досить складно зробити деякі тонкі настройки, що мають відношення до роботи з даними.


Кожна операція, вироблювана над даними, попередньо описується як значуща і неподільна. Набір таких описів і правил носить назву Configuration Management і є частиною методології RUP.


Configuration Management повністю регламентує, що, як і ким має робитися в проекті і як використовувати для цих цілей ClearCase. Погодьтеся, мало мати інструмент, потрібно вміти ним користуватися.


Спробуємо розглянути (схематично), яким чином ClearCase дозволяє контролювати проект. Для цього звернемося до налаштування видів і здійснимо злиття версій.


Особливості створення видів


Отже, якщо згадати базові можливості ClearCase в області зберігання інформації, то виходить, що ми повинні створити репозитарій (VOB), Створити вид (один або декілька), потім будь-яким відомим способом копіювати / зберігати файли та директорії на диск, створений ClearCase, і встановити за ними контроль.

Рис. 9. Тут зображений вид файлу Alex.cpp, виведеного в стан Check-Out.
Скріншот зроблений з поточного виду


Тут криється певна проблема: як організувати при цьому спільний доступ до одного файлу і як будуть підтримуватися різні версії і різні проекти? Це не пусті запитання! Давайте подивимося, що є в арсеналі ClearCase для вирішення даних проблем. Але перш хочу ще раз нагадати дуже важливий момент: ClearCase має свою особливу ідеологію роботи, яка не завжди зрозуміла з першого погляду, оскільки вимагає деякого осмислення. Тому слід утриматися від спроб “підім’яти” його під свої потреби. Швидше за все, це не вийде, так як для отримання найбільшої ефективності простіше буде перебудувати існуючий підхід – на той, що пропонує ClearCase.


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

Рис. 10. Тут зображений вид файлу «Alex.cpp», з іншого комп’ютера


Слід мати на увазі, що ClearCase має особливу файлову систему – MVFS (MultiVersion File System), Яка дозволяє отримувати доступ до версії конкретного файлу і виробляти його правку. Тут необхідно враховувати, що при простому зверненні до потрібного файлу ClearCase надає останню версію або версію, що знаходиться в стані Check-out (Для розробника, який взяв файл на редагування, ClearCase буде підставляти версію Check-out, для всіх інших учасників – останню; рис. 9, рис. 10, рис. 11 і рис. 12 відповідно).











Рис. 9.

Рис. 10.


Рис. 11. Так виглядає дерево версій для файлу в поточному вигляді


Рис. 12. Так виглядає дерево версій для файлу в поточному вигляді


Таке становище призводить до того, що кожен розробник може взяти один і той же файл і зайнятися його доопрацюванням … Але чи правильно це?


Відповідь – НІ. Це невірно, оскільки після того, як розробники закінчать правку файлу і дадуть команду Checkin, ClearCase не зможе просто створити нову версію – йому доведеться викликати MergeManager для об’єднання нової версії з уже існуючою. А адже розробнику слід якомога рідше вдаватися до даного модулю, щоб не ускладнювати і без того непросту розробку програмного забезпечення. Правда, вихід є і з такої ситуації.


Коли користувач виводить файл в стан редагування (Check-out), ClearCase виводить вікно, в якому просить ввести коментар для події, а також те, яким чином файл буде представлятися далі в проекті: RESERVED або UNRESERVED.


Стан RESERVED перетворює версію в зарезервовану за конкретним власником, і ClearCase не дозволить іншому користувачеві зробити нову.


Стан UNRESERVED дозволяє всім учасникам проекту створювати свої підверсії файлу, але при цьому самий “спритний” користувач, натиснув кнопку Check-in першим, встановлює контроль за файлом як зазвичай, а іншим доведеться виробляти сліяніe з новою версією.

Рис. 13. Так виглядає дерево у випадку, якщо два користувачі одночасно ввели один і той же файл в стан Check-in. Як бачимо, зробити це можна, тільки чи варто підміняти роботу однієї людини роботою іншого?

Звідси висновок: якщо ви користуєтеся тільки однотипними видами, то в більшості випадків краще користуватися операцією RESERVED.


Зрозуміло, ClearCase пропонує і більш ефективні способи роботи, правда, для їх здійснення на практиці необхідні деякі знання.


Кожен вид будується на базі спеціальних правил (Rules), Які можна знайти на вкладці з властивостями виду. Правило за замовчуванням відображає лише те, про що ми говорили вище, і виглядає наступним чином:


element * CHECKEDOUT
element * /main/LATEST


Це означає: показати у вигляді всі елементи в стані CHECKEDOUT або LATEST. Так відбувається підстановка у вигляді файла з потрібною версією в якості файлу за замовчуванням.


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


В ClearCase є дві можливості зміни існуючих правил: ручна правка (при цьому потрібно знання синтаксису правил), автоматична правка (побудова профілів і видів на їх основі або асоціація видів з відповідними профілями).


Розглянемо спочатку побудова видів на базі профілів.


Профілі можна створювати відразу після інсталяції ClearCase в окремо відведений каталог, відкритий для загального доступу. Тут криється основна проблема початківців користувачів! ClearCase сам не створює каталоги і не налаштовує свій доступ до них – це доводиться робити вручну. Шлях до створеного каталогу (абсолютно пустому) прописується на вкладці “Адміністрування”, як показано на рис. 14.

Рис. 14. Дана вкладка представляє собою частину вікна адміністрування


Після налаштування шляхів стає повністю доступною вкладка BranchesClearCase HomeBase.

Рис. 15. Зверніть увагу на виділені пункти. Вони з’являться лише при вказівці шляху до правильної директорії Profiles, в іншому випадку пункти можуть або відсутні, або не активуватися


При коректної установці можна сміливо натискати на кнопку View Profile і створювати новий видовий профіль. Іменувати його можна або власним іменем, або за версією проекту (в залежності від конкретної ситуації).


Обов’язково слід вказати ім’я VOB, Для якого будується вид, а потім найменування відгалуження. В результаті операції буде створений новий вид (новий диск), в якому відсутні файли проекту. Відсутність це тимчасове, оскільки створення виду за профілем увазі злиття одного або декількох файлів з попереднього виду в поточний. Іншими словами, для паралельної розробки можна брати не весь проект, а тільки зазначені його частини (файли, директорії). Зрозуміло, всі зміни будуть відображені на дереві версій.


Тут необхідно акцентувати увагу на тому, що методом профілів можна організувати не тільки паралельну розробку, але і розбивку проекту на кілька частин. Наприклад, одна частина проекту – DEVELOPMENT – Доступна всім і відображає всі версії всіх файлів, але з поточною версією тільки на гілки MAIN, А друга частина – RELEASE – Містить тільки ті файли, які підлягають компіляції. І нарешті, DEBUG – Частина, яка містить налагоджувальні версії файлів. Всі ці гілки можна зробити за допомогою профілів або за допомогою ручної правки правил.

Рис. 16. Приблизно так буде виглядати дерево версій одного файлу з Dev / View. Як бачите, друга версія файлу була взята на доопрацювання в різні проекти


Всі перераховані можливості дозволяють гнучко налаштовувати середовище ClearCase. У свою чергу, можливість побудови подібних видів дозволяє не прив’язуватися строго до одного засобу розробки. Таким чином, ClearCase є середовищем зберігання Cборка і супроводу для будь-яких засобів розробки.


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

Рис 17. Так можна порівняти, а потім і об’єднати два каталоги.
Зверніть увагу на червону стрілку і сині смуги – це відсутній файл, що вимагає об’єднання. Тут необхідно пам’ятати, що каталог також є елементом і йому присвоюється новий номер версії кожен раз, коли до складу проекту вноситься новий файл або підкаталог

Рис 18. Даний малюнок демонструє додаткові можливості в порівнянні складу каталогів, узятих з різних версій наборів. Необхідно нагадати, що ClearCase зберігає не тільки історію редагування кожного елемента, а й запам’ятовує складу файлів у проекті. Таким чином, розробник отримує можливість повернутися на кілька кроків назад з точки зору складу проекту


Ми розглянули найпростіший спосіб створення видів. Якщо ж розробник (менеджер проекту) здатний запам’ятати деякі правила створення видів, то нові види можна будувати як завгодно, змінюючи тільки правила перегляду. Якщо вид – це фільтр, то правило (Rule) – Це свого рада маска для вибору. Не завжди потрібно будувати новий вигляд і створювати новий профіль для того, щоб зв’язати воєдино кілька файлів, простіше дати команду фільтрації за правилами.


За замовчуванням ClearCase працює за правилом:


element * CHECKEDOUT
element * /main/LATEST


Це означає, що всі файли знаходяться в стані CHECKEDOUT або це їхні останні версії.


Мова правил ClearCase досить простий. Як і багато інших операцій, завдання правил можна здійснювати як з користувальницького інтерфейсу, так і з командного рядка. В останньому випадку необхідно ознайомитися з командами “edcs“- Редагування запису для поточного або встановленого виду,”catcs“- Переглянути поточне правило в текстовому режимі без можливості редагування і”setcs“- Встановити нове правило, причому саме правило необхідно оформити у вигляді окремого файлу, доступного всім учасникам проекту, так, щоб кожен з них міг асоціювати свій вид з необхідним в даний момент правилом.


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


На основі правил проблема вирішується дуже швидко! У процесі редагування файлів кожен розробник зазначав на дереві версій ту, яка вважалася остаточною версією з відповідним номером “REL1”, “REL2”, “REL3” і т.д. Для цього в ClearCase передбачений ще один механізм – механізм міток – простих, звичайних міток, знайомих всім з перших кроків у програмуванні. Розробник разом з менеджером проекту вибирають одну з версій на дереві і присвоюють їй ім’я. Надалі ця мітка стає синонімом конкретної версії конкретного файла, тобто одну і ту ж мітку необхідно призначати різним файлів і різним підверсії.


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


Підкоригувати вищенаведене стандартне правило для того, щоб ClearCase показував тільки всі версії з міткою “REL1”, можна так, як це зроблено на рис. 19.

Рис. 19. Зверніть увагу: перша версія для даного виду стала поточної, а самої версії призначено дві мітки (ClearCase дозволяє поставити і більше – для тих випадків, коли одна і та ж версія файлу переходить з одного релізу в інший без змін)


element * CHECKEDOUT
element * REL1


Можна, наприклад, включити у фільтр всі файли з розширенням BAT з нульовою версією, тоді правило буде мати такий вигляд:


element * CHECKEDOUT
element * REL1 element *.bat /main/0


Або можна налаштувати ClearCase так, щоб виводилися файли строго певного типу (в ClearCase, як і в житті, розширення можуть розрізнятися, а типи файлів збігатися, наприклад, архівні файли). Правило буде виглядати так:


element * CHECKEDOUT
element -eltype archive * REL1


Ð ~ Ð »Ð ¸ Ð ¿Ñ € Ð ¾ Ñ Ñ, Ð ¾ Ð ¾ Ñ, Ñ Ð ¾ Ñ € Ñ, Ð ¸ Ñ € Ð ¾ Ð ² Ð ° Ñ, ÑŒ Ð ² Ñ Ðμ Ñ” Ð ° Ð ¹ Ð »Ñ <Ð ¿Ð ¾ Ð'Ð ° Ñ, Ðμ Ð ¸ Ð »Ð ¸ / Ð ¸ Ð ² Ñ € ÐμÐ ¼ ÐμÐ ½ Ð ¸" â € | ugfixLATEST - time yesterday ",


time 10-Jul.19:00
element atrialib* …
ewLATEST
element * mainLATEST end time


І найголовніше: ClearCase дозволяє створювати архів правил у вигляді окремих файлів, які можна завантажувати директивою Include.


Таким чином, одну і ту ж функцію продукт здатний виконати декількома способами. І тут не можна сказати, що один спосіб краще, а інше гірше – всі вони однаково корисні. Сам проект тільки виграє, якщо всі способи будуть застосовуватися одночасно.


Розробник може створювати різні відгалуження версій своїх файлів виключно для власної зручності, роблячи відгалуження командою mkbranch, Менеджер проекту спільно з розробником ставить позначку з номером складання проекту на конкретну версію. Якщо необхідно здійснити редагування одного файлу силами більше однієї людини, то вдаються до допомоги MergeManager і профілів. А для створення збірок пишуть правило ConfigSpec (Configuration Specification), За яким будуть виводитися файли.


Довідкова інформація


Відмінні риси ClearCase




Специфікації



Вимоги для клієнтської частини:



Вимоги для серверної частини:



Підтримувані Web-браузери:



Підтримувані Web-cервер



Операційні системи



Інтеграція з засобами розробки:



Висновок



ClearCase на сьогоднішній день є найбільш просунутою системою версійність і конфігураційного управління, забезпеченою новітніми досягненнями в області SCM (Source Code / Configuration Management). Оскільки ClearCase є системою корпоративного рівня, рекомендувати її можна всім підприємствам, число розробників в яких більше п’яти. Всі потужні можливості цього продукту розкриваються при використанні його на великих підприємствах з великою кількістю розробників. ClearCase – воістину незамінний продукт, коли мова заходить про об’єднання регіонально віддалених команд розробників.


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


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

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

Ваш отзыв

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

*

*