Створення резервних копій програмного коду і даних

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

1. Результати дослідження управління git технологія програмний Хмарні обчислення — це модель забезпечення повсюдного та зручного доступу на вимогу через мережу до спільного пулу обчислювальних ресурсів, що підлягають налаштуванню (наприклад, до комунікаційних мереж, серверів, засобів збереження даних, прикладних програм та сервісів), і які можуть бути оперативно надані та звільнені з мінімальними управлінськими затратами та зверненнями до провайдера.

При використанні хмарних обчислень програмне забезпечення надається користувачеві як Інтернет-сервіс. Користувач має доступ до власних даних, але не може управляти і не повинен піклуватися про інфраструктуру, операційну систему і програмне забезпечення, з яким він працює. «Хмарою» метафорично називають інтернет, який приховує всі технічні деталі. Згідно з документом IEEE, опублікованим у 2008 році, «Хмарні обчислення — це парадигма, в рамках якої інформація постійно зберігається на серверах у мережі інтернет і тимчасово кешується на клієнтській стороні, наприклад на персональних комп’ютерах, ігрових приставках, ноутбуках, смартфонах тощо». Хмарні сервіси, що дозволяють перенести обчислювальні ресурси й дані на віддалені інтернет-сервери, в останні роки стали одним з основних трендів розвитку IT-технологій.

Концепція хмарних обчислень з’явилася ще в 1960 році, коли американський учений, фахівець з теорії ЕОМ Джон Маккарті (John McCarthy) висловив припущення, що коли-небудь комп’ютерні обчислення стануть надаватися подібно комунальним послугам (public utility). Розповсюдження мереж з високою потужністю, низька вартість комп’ютерів і пристроїв зберігання даних, а також широке впровадження віртуалізації, сервіс-орієнтованої архітектури привели до величезного зростання хмарних обчислень. Кінцеві користувачі можуть не перейматися роботою обладнання технологічної інфраструктури «в хмарі», яка їх підтримує. Аналогією обчислювальних «хмар» зі звичного життя можуть служити електростанції. Хоча домовласник може купити електрогенератор і піклуватися про його справність самостійно, більшість людей вважає за краще отримувати енергію від централізованих постачальників.

Майже всі сучасні характеристики хмарних обчислень, порівняння їх з електроенергетикою та використання приватних, публічних та громадських моделей були представлені Дугласом Паркхілом (Douglas Parkhill) в книзі «The Challenge of the Computer Utility», в 1966 році. Згідно інших джерел, хмарні обчислення беруть початок з 1950;х років, коли вчений Херб Грош (Herb Grosch) стверджував, що весь світ буде працювати на терміналах, якими керують близько 15 великих центрів обробки даних.

Сам термін «хмара» походить з телефонії, тому що телекомунікаційні компанії, які до 1990;х років пропонували в основному виділені схеми передачі «точка-точка», почали пропонувати віртуальні приватні мережі (VPN), з порівняною якістю обслуговування, але при набагато менших витратах. Премикаючи трафік для оптимального використання каналів вони мали змогу ефективніше використовувати мережу. Символ хмари був використаний для позначення розмежування між користувачем і постачальником.

Ключову роль в розвитку хмарних обчислень зіграв Amazon, модернізувавши свої центри обробки даних, які, як і більшість комп’ютерних мереж в один момент часу використовують лише 10% своєї потужності, заради забезпечення надійності при стрибку навантаження. Дізнавшись, що нова хмарна архітектура забезпечує значне внутрішнє підвищення ефективності, Amazon почав нові дослідження в галузі розвитку продуктів для забезпечення хмарних обчислень для зовнішніх клієнтів, і запустив Amazon Web Service (AWS) на основі розподілених обчислень в 2006 році.

На початку 2008 року Eucalyptus став першою API-сумісною платформою з відкритим кодом для розгортання приватної хмари. На початку 2008 року OpenNebula став першим проектом з відкритим кодом для розгортання приватних і гібридних хмар.

За оцінками IDC ринок публічних хмарних обчислень у 2009 році склав $ 17 млрд. — близько 5% від усього ринку інформаційних технологій. Згідно з прогнозами до 2016 року ринок хмарних послуг досягне позначки в $ 83 млрд. Крім того, за даними консалтингових компаній понад 30% підприємств у всьому світі вже розгортають, принаймні, одне хмарне рішення.

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

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

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

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

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

Національним інститутом стандартів і технологій США встановлені такі обов’язкові характеристики хмарних обчислень:

· Самообслуговування на вимогу (англ. self service on demand), споживач самостійно визначає і змінює обчислювальні потреби, такі як серверний час, швидкості доступу та обробки даних, обсяг збережених даних без взаємодії з представником постачальника послуг;

· Універсальний доступ по мережі, послуги доступні споживачам через мережу передачі даних незалежно від термінального пристрою;

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

· Еластичність, послуги можуть бути надані, розширені, звужені в будь-який момент часу, без додаткових витрат на взаємодію з постачальником, як правило, в автоматичному режимі;

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

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

З точки зору споживача, ці характеристики дозволяють отримати послуги з високим рівнем доступності (англ. high availability) і низькими ризиками непрацездатності, забезпечити швидке масштабування обчислювальної системи завдяки еластичності без необхідності створення, обслуговування і модернізації власної апаратної інфраструктури.

Зручність і універсальність доступу забезпечується широкою доступністю послуг і підтримкою різного класу термінальних пристроїв (персональних комп’ютерів, мобільних телефонів, інтернет-планшетів).

Виділяють наступні моделі надання послуг за допомогою хмари:

· Програмне забезпечення як послуга (SaaS) Прикладами програмного забезпечення як послуги, що працює на основі обчислювальної хмари, є сервіси Gmail та Google docs.

· Платформа як послуга (PaaS) Наприклад, Google Apps надає за стосунки для бізнесу в режимі онлайн, доступ до яких відбувається за допомогою Інтернет-браузератоді як ПЗ і дані зберігаються на серверах Google.

· Інфраструктура як послуга (IaaS) Найбільшими гравцями на ринку інфраструктури як послуги є Amazon, Microsoft, VMWare, Rackspace та Red Hat. Хоча деякі з них пропонують більше, ніж просто інфраструктуру, їх об'єднує мета продавати базові обчислювальні ресурси.

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

Обчислювальна хмара може бути розгорнута як: приватна, публічна, громадська або гібридна.

Приватна хмара Приватна хмара (англ. private cloud) — це хмарна інфраструктура, яка призначена для використання виключно однією організацією, що включає декілька користувачів (наприклад, підрозділів). Приватна хмара може перебувати у власності, керуванні та експлуатації як самої організації, так і третьої сторони (чи деякої їх комбінації). Така хмара може фізично знаходитись як в, так і поза юрисдикцією власника.

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

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

Гібридна хмара Гібридна хмара (англ. hybrid cloud) — це хмарна інфраструктура, що складається з двох або більше різних хмарних інфраструктур (приватних, громадських або публічних), які залишаються унікальними сутностями, але з'єднанні між собою стандартизованими або приватними технологіями, що уможливлюють переносимість даних та прикладних програм (наприклад, використання ресурсів публічної хмари для балансування навантаження між хмарами).

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

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

З’ясуємо що таке система управління версіями (СУВ). Система управління версіями — це система, що зберігає зміни в одному або декількох файлах так, щоб потім, за потреби, можна було відновити відповідні старі версії.

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

Гілки, зазвичай, використовують для зберігання експериментальних, незавершених та повністю робочих версій проекту. Більшість СУВ дозволяють кожному з об'єктів присвоювати мітки (теги), за допомогою яких можна формувати нові гілки і репозиторії.

Використання СУВ є вкрай важливими для роботи над великими проектами, до виконання яких одночасно задіяна велика кількість розробників. Використання СУВ створює низку додаткових можливостей:

— створення різних варіантів одного документу;

— документування всіх змін (коли, ким було змінено/додано, хто який фрагмент змінив);

— реалізація функції контролю доступу користувачів до файлів, передбачена можливість його обмеження;

— створення документації проекту з поетапним записом змін залежно від версії;

— додавання пояснень до змін і їх документування.

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

Рис. 1. Схема локальної СУВ Однією з найбільш часто вживаних СУВ даного типу є RCS (Revision Control System), яка до цих пір широко використовується. Навіть у сучасній операційній системі Mac OS X утиліта RCS встановлюється разом з Developer Tools. Використання цієї утиліти полягає у роботі з наборами патчів між парами змін, які зберігаються у спеціальному форматі на диску. Патч — це файл, що описує відмінність між файлами попередньої і поточної версій. Така технологія дозволяє перетворити будь-який файл у будь-який момент часу, послідовно накладаючи патчі.

Іншою важливою проблемою виявилась потреба забезпечення співпраці розробників, що працюють віддалено за іншими комп’ютерами. Для її розв’язання були створені централізовані системи управління версіями (ЦСУВ). У таких системах, зокрема, CVS, Subversion і Perforce, є центральний сервер, на якому зберігаються всі файли, що відслідковуються, і група клієнтів, котрі отримують копії файлів з нього. Упродовж багатьох років такий підхід був стандартом управління версіями (рис. 2).

Рис. 2. Схема централізованого управління версіями Зазначений підхід має низку переваг, особливо над локальними СУВ. Наприклад, коли між виконавцями проекту чітко розподілені завдання й обов’язки, то адміністратори легко можуть контролювати всіх учасників, усі процеси розробки проекту, і, попри це, адмініструвати ЦСУВ набагато простіше, ніж локальні бази на кожному клієнті. Однак, у разі використання такого підходу виникає низка суттєвих недоліків. Найбільш очевидний — централізований сервер є уразливою частиною всієї системи. Якщо сервер на певний час вимикається, то упродовж цього часу розробники не можуть взаємодіяти між собою, зберігати нові версії файлів проекту. Якщо ж пошкоджується диск із центральною базою даних і відсутні резервні копії, то втрачається абсолютно все — уся історія проекту, окрім, хіба що, декількох робочих версій, що збереглися на комп’ютерах розробників.

Зарадити проблемі може використання розподілених систем управління версіями (РСУВ) для командних розробок. У таких системах як Git, Mercurial, Bazaar або Darcs клієнти не просто отримують останні версії файлів, а повністю копіюють репозиторій. Тому у випадку, коли виходить з ладу сервер, через який організовувалась спільна робота над проектом, будь-який клієнтський репозиторій можна скопіювати знову на сервер, щоб відновити базу даних. Робота в РСУВ організована так, що кожного разу, коли клієнт отримує свіжу версію файлів, створюється повна копія всіх даних (рис. 3).

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

Рис. 3. Схема розподіленої системи управління версіями.

Однією із СУВ, що визнана ІТ фахівцями доволі ефективною для створення великих проектів, а також має потужну систему розгалуження, є Git (розроблена Лінусом Торвальдсом у 2005 році). Відповідно до документації даного програмного продукту:

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

До основних переваг Git порівняно із CVS можна віднести такі:

— розгалуження створюється швидко й легко;

— підтримується автономна робота, локальні фіксації змін можуть бути надіслані пізніше;

— фіксації змін атомарні і поширюються на весь проект, а не на окремий.

файл;

— кожне робоче дерево містить сховище з повною історією проекту;

— жодне зі сховищ за своєю суттю не є більш важливим, ніж будь-яке інше.

На сьогодні використання системи Git докорінно змінило підходи розробників щодо процесів розгалуження і злиття, які, до речі, є основними у роботі СУВ.

Основними елементами Git є репозиторій, гілки — головні і додаткові, а також основні команди й операції.

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

У системі Git репозиторій — це сховище, яке завжди знаходиться поряд з робочою директорією проекту в директорії.git.

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

Слід зазначити, що у системі Git, окрім головного, кожен учасник проекту може мати власний репозиторій. Кожен користувач звертається до центру, але окрім двосторонньої взаємодії з центром, кожен розробник може брати до уваги зміни на інших вузлах, так утворюючи субкоманду. Зокрема, застосування такого підходу може бути доречним під час роботи кількох розробників над реалізацією певної великої функції, перш ніж передати цю функцію до головного репозиторію. Відповідно до рис. 4 утворено субкоманди з таких учасників, як Розробник 1 і Розробник 4, Розробник 1 і Розробник 2, Розробник 3 і Розробник 2. З технічної точки зору це не що інше, як використання Розробником 1 віддалено репозиторію Розробника 4, і навпаки.

Рис. 4. Модель співпраці учасників субкоманди.

Особливості використання системи управління версіями Git.

Для створення репозиторію Git можна використовувати один із двох існуючих підходів. Перший підхід полягає в імпорті у Git вже існуючого проекту чи каталогу. Другий реалізується шляхом клонування вже існуючого репозиторію із сервера..

Для початку використання Git з уже існуючим проектом, слід перейти до проектного каталогу й у командному рядку ввести команду: $ git init.

Ця команда створить у поточному каталозі новий підкаталог з ім'ям.git, що міститиме всі необхідні файли репозиторію — основу репозиторію Git.

Для внесення до репозиторію вже існуючих файлів слід їх спочатку проіндексувати, а потім виконати першу фіксацію змін. Цей процес забезпечить послідовне виконання кількох команд git add, що вказують на файли, які повинні бути проіндексовані, а потім на завершення зафіксованими командою commit:

$ git add *.c.

$ git add README.

$ git commitm `initial project version'.

Комміт (commit) —- це збереження у репозиторії змін у програмному коді.

У разі виникнення потреби отримання копії вже існуючого репозиторію Git, на приклад проекту, до виконання якого слід долучити ще одного учасника, слід скористатися командою git clone. У процесі виконання цієї команди кожна версія кожного файлу з історії проекту забирається (pulled) із сервера. Наприклад, якщо потрібно зробити клон бібліотеки Ruby Git, відомої як Grit, то виконати це можна так:

$ git clone git://github.com/schacon/grit.git.

Ця команда дає вказівку системі Git створити каталог з іменем «grit», ініціалізувати в ньому каталог. git, завантажити всі потрібні дані для цього репозиторію і створити (checks out) робочу копію останньої версії.

Як і будь-яка СУВ, Git надає можливість створювати розгалуження. Розгалуження означає, що можливе відхилення від основної лінії розробки і продовження роботи без втручання до основної лінії. Гілка у системі Git — це звичайний рухомий вказівник на один зі створених коммітів.

Існує кілька підходів до використання системи Git, серед яких, найвдалішою, на наш погляд, є так звана концепція gitflow. Саме тому у подальшому нашому розгляді будемо дотримуватись цієї концепції.

Центральний репозиторій працює з двома паралельними між собою гілками: master і develop (рис. 5). Кожна гілка розглядається як основна, а вихідний код продукту буде відображати стан з внесеними змінами, що буде основою для подальших змін.

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

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

Рис. 5. Схема взаємодії робочої і головної гілок проекту.

У процесі розробки складного проекту можуть використовуватися різні види додаткових гілок, зокрема: тематичні гілки (feature), гілки версій (release) та гілки помилок (hotfix). Кожна з цих гілок має спеціальне призначення і розробники проектів обов’язково мають притримуватись певного набору правил щодо їх визначення, зокрема, яка з гілок є першоджерелом, а яка — результатом злиття інших, тощо. З технічної точки зору це звичайні Git гілки, а їх класифікації буде визначатися метою їх використання.

Рис. 6. Схема утворення тематичної гілки.

Тематичні гілки є відгалуженням від робочої гілки (develop) і після завершення розробки визначеного функціоналу на них повинні бути злиті саме з робочою гілкою. Такі гілки можна називати будь-якими іменами, окрім master, develop, release-*, or hotfix-*.

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

Коли починається робота над новою функцією проекту, то відбувається відвітлення від гілки develop. Процес створення тематичної гілки відбувається так:

$ git checkoutb myfeature develop.

Отже, відбулося створення і перехід на нову гілку «myfeature». Після завершення роботи на цій гілці вона зіллється з гілкою develop:

$ git checkout develop // з'єднання з гілкою 'develop'.

$ git merge —no-ff myfeature // злиття змін гілки myfeature з поточною develop $ git branchd myfeature // видалення гілки myfeature.

$ git push origin develop // синхронізація даних з віддаленим репозиторієм.

Використання параметра —no-ff забороняє виконання операції Fast Forward, тобто простого переміщення вказівника гілки по дереву, навіть якщо це можливо. Це дозволяє уникнути втрат інформації про існування тематичних гілок і згрупувати разом усі компоненти, з яких складатиметься новоутворена функція проекту. Порівняємо два способи процесу злиття гілок.

Рис. 7. Схема злиття гілок.

У першому випадку (ліва частина рис. 7) з історії проекту неможливо виокремити ті об'єкти, які утворювали нову функцію, а, отже, у разі потреби її вдосконалення, слід буде ретельно переглядати весь журнал повідомлень. Утім, процес повернення до всієї тематичної гілки (тобто до групи фіксацій) буде дуже складним. Уникнути зазначених проблем можна за умови використання параметраno-ff (права частина рис. 7). Звісно, такий підхід призведе до створення декількох додаткових коммітів (містять інформацію про злиття, а в разі виникнення конфліктів злиття міститимуть також зміни файлів, які призвели до них), але це не завадить проекту.

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

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

Технологія командної роботи над проектом.

Вище розглянуті особливості використання СУВ Git визначили достатню функціональність цього середовища і переконують нас у можливості його успішного використання як інструменту командної роботи над проектом. Як приклад розглянемо розробку інформаційно-аналітичної системи тестового контролю знань у рамках Git-розгалуження. Беззаперечно, що розробка будь-якого проекту повинна бути чітко спланована, розділена на етапи й основні блоки, з яких складатиметься майбутня система тестування. До таких основних блоків віднесемо такі модулі: управління користувачами, банк тестів, обробка результатів тестування. Кожен із модулів можна доповнювати, розширювати, додаючи нові можливості і функції, але при цьому потрібно ретельно і виважено здійснювати створення нової версії програмного продукту, без втрат інформації на попередніх кроках розробки..

Важливим етапом командної роботи є обрання так званого лідера команди (team leader), тобто людини, яка керуватиме повністю процесом розробки проекту, контролюватиме процеси розгалуження і злиття гілок тощо. Тому бажано, щоб таким лідером був не студент, а викладач, тобто керівник дипломних робіт або адміністратор, який координує роботу всіх проектів кафедри. Саме лідер команди (адміністратор) починає роботу над проектом зі створення початкового комміту — створюється гілка master, і початкових налаштувань системи — створюється гілка develop. Далі, визначавшись з основними модулями, які необхідно розробити, завдання видається студентам-дипломникам, кожен з яких працює окремо, створюючи свою тематичну (feature) гілку..

Першим було розроблено блок керування користувачами, що включав у себе такі етапи: створення списку користувачів, створення структури бази даних, створення системи управління користувачами. Усе це було розроблено на тематичній гілці — feature/users_manage з подальшим її злиттям з гілкою develop..

Наступним кроком була розробка блоків, що дозволяють створювати сховища завдань, редактор завдань та каталог завдань. Ці модулі було розроблено на тематичній гілці — feature/task_catalogue, яка також була злита з гілкою develop..

Далі, модулі класифікації тестів, перегляду результатів тестування і власне самого тестування розроблялися на тематичній гілці — feature/test_processing, що також була злита з основною гілкою develop..

Об'єднання вище описаних трьох гілок дає змогу підготувати першу, так звану незавершену, версію продукту — release/0.1. Виправлення всіх помилок злиття на гілці версій (release) дозволяє отримати першу стабільну версію розробленої системи тестування на гілці master — версія 0.1..

У ході першого використання розробленої системи тестування виникли нові завдання, які значно покращать функціональність даного програмного продукту. У результаті чого було додано ще декілька модулів, зокрема модуль імпорту тестів, що розроблявся на гілці feature/test_importer, модуль редагування тестів, що розроблявся на гілці feature/advanced_editor, модуль математичного редактора, що розроблявся на гілці feature/math_editor. Об'єднання цих трьох тематичних гілок утворить нову версію програмного продукту — release/0.2. Виправлення помилок злиття на гілці версій (release) дозволяє отримати другу стабільну версію розробленої системи тестування на гілці master — версія 0.2..

Подальше вдосконалення системи, виправлення виникаючих помилок злиття на гілці версій дає змогу отримати наступні версії програмного продукту — версія 0.2.1..

Отже, розробка окремих модулів, з яких складається система тестування відбувається на окремих тематичних гілках, окремими користувачами в рамках виконання їхніх робіт. Це дозволяє виконувати роботу незалежно від інших учасників проекту, значно спрощує процес злиття розроблених модулів в єдине ціле, оскільки цим займається лише адміністратор. Що ж до структурної схеми проекту, то саме використання тематичних гілок дозволяє значно спростити гілку develop, а на головній гілці master розміщувати лише стабільні версії програмного продукту. Загальну схему розробки системи тестування з використання Git-розгалуження представлено на рис. 8..

Рис. 8. Загальна схема розробки проекту системи тестового контролю.

Висновки та перспективи подальших досліджень.

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

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

Список використаних джерел.

1. Киричек Г. Г. Модель оцінки плагіату програмного коду на основі системи контролю версій / Г. Г. Киричек, О. О. Киричек // Восточно-Европейский журнал передовых технологий. — 2012. — № 2/2. — Вып. 56. — С. 25−28.

2. Robbins Jason. Analysis of Git and Mercurial [Заглавие с экрана] /Jason Robbins.—Режим доступу: http://code.google.com/p/support/wiki/DVCSAnalysis.

3. Scott Chacon. Pro Git // Apress. — 2013. — 294 с.

4. Моя шпаргалка по работе с Git. Записки программиста. 2011. [Електронний ресурс]. — Режим доступу: http://eax.me/git-commands/.

5. Эли М Доу. Управление исходным кодом с помощью Git. 2009. [Електронний ресурс]. — Режим доступу: http://www.ibm.com/developerworks/ru/library/l-git/.

6. Driessen V. A successful Git branching model. 2010 [Електронний ресурс]. — Режим доступу: http://nvie.com/posts/a-successful-git-branching-model/.