Керування конфігурацією та версіями ПЗ

📌 Про що ця тема

Тут перевіряють, як організовують і контролюють зміни у програмному забезпеченні протягом усього його життєвого циклу. Ключове поняття — керування конфігурацією (Software Configuration Management, SCM) та його частина — керування версіями (контроль версій). Знати це треба, щоб розуміти командну розробку, відстеження змін і повернення до робочих станів ПЗ.

📖 Головне

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

• Конфігураційна одиниця — окремий елемент, який відстежують (файл, модуль, документ).

• Базова лінія (baseline) — зафіксований, погоджений стан продукту на певний момент, від якого ведуть подальші зміни.

• Основні завдання SCM: ідентифікація елементів, контроль змін, облік стану, аудит конфігурації.

• Керування версіями — підтримка історії змін: хто, коли і що змінив; можливість повернутися до попередньої версії.

• Репозиторій — сховище, де зберігаються всі версії файлів та історія змін.

• Коміт (commit) — фіксація набору змін у репозиторії з описом (повідомленням).

• Гілка (branch) — окрема лінія розробки, що дозволяє працювати паралельно, не чіпаючи основну версію.

• Злиття (merge) — обʼєднання змін з різних гілок в одну.

• Конфлікт — ситуація, коли той самий фрагмент змінено по-різному; розвʼязується вручну.

• Типи систем контролю версій: централізовані (один сервер-репозиторій, напр. SVN) і розподілені (повна копія історії в кожного, напр. Git).

• Нумерація версій часто має вигляд МАЖОРНА.МІНОРНА.ПАТЧ (напр. 2.3.1): велике число — суттєві зміни, середнє — нові можливості, мале — виправлення.

🔢 Як це працює на прикладі

Команда розробляє застосунок у Git:

1) Створюють репозиторій і роблять перший коміт — це базова лінія версії 1.0.0.

2) Для нової функції розробник створює гілку feature.

3) Вносить зміни, робить кілька комітів з описами.

4) Тим часом у головній гілці виправили помилку — версія стала 1.0.1.

5) Розробник завершує функцію і виконує merge гілки feature у головну — версія стає 1.1.0.

6) Якщо той самий рядок коду змінено й там, і там, виникає конфлікт — його вручну узгоджують, після чого завершують злиття.

⚠️ Типові помилки

• Плутають керування конфігурацією (ширше поняття — весь облік змін) і керування версіями (лише історія версій файлів).

• Вважають, що Git і GitHub — одне й те саме: Git — система контролю версій, GitHub — лише вебсервіс для зберігання репозиторіїв.

• Плутають централізовані й розподілені системи: у розподілених кожен має повну історію локально.

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

• Не розуміють, що коміт обовʼязково супроводжується описом змін.

🎯 Що завчити напамʼять

• Завдання SCM: ідентифікація, контроль змін, облік стану, аудит.

• Базова лінія — зафіксований погоджений стан.

• Коміт, гілка, злиття, конфлікт, репозиторій — базові терміни.

• Централізовані (SVN) vs розподілені (Git).

• Схема версій: МАЖОРНА.МІНОРНА.ПАТЧ.

🧠 Перевір себе

1) Чим керування версіями відрізняється від керування конфігурацією?

2) Що таке базова лінія?

3) Чим розподілена система контролю версій відрізняється від централізованої?

4) Що означає конфлікт при злитті і як його розвʼязують?

Відповіді: 1 — керування версіями відстежує історію змін файлів, а керування конфігурацією ширше: охоплює весь облік, контроль і аудит усіх складових ПЗ; 2 — зафіксований погоджений стан продукту на певний момент, від якого ведуть подальші зміни; 3 — у розподіленій кожен учасник має повну копію історії локально, у централізованій історія зберігається на одному сервері; 4 — це коли той самий фрагмент змінено по-різному у різних гілках; розвʼязують вручну, обираючи потрібний варіант, після чого завершують злиття.