Конфігураці́йне керува́ння (, SCM) в програмній інженерії — комплекс методів, спрямованих на систематичний облік змін, що вносяться розробниками в програмний продукт в процесі його розробки та супроводу, збереження цілісності системи після змін, запобігання небажаних і непередбачуваних ефектів, формалізація процесу внесення змін.

В ряді джерел можна побачити абревіатуру SCCM — Software Configuration and Change Management. При тому, що в розумінні SWEBOK і відповідних стандартів SCM і SCCM тотожні, термін SCCM іноді використовується для того, щоб підкреслити принципову значимість управління змінами як складової частини конфігураційного управління.

SCM-діяльність тісно пов'язана з роботами по забезпеченню якості програмного забезпечення (Software Quality Assurance — SQA). Історія розвитку Концепція конфігураційного керування виникла задовго до появи перших масштабних комп'ютерних систем. Вона сформувалася у 1950-х роках у військовій та аерокосмічній промисловості США. Головним рушієм виступило Міністерство оборони США, якому був необхідний суворий облік та контроль фізичних компонентів, деталей та креслень складних літаків і ракетних систем. Будь-яка неконтрольована зміна у конструкції навіть дрібної деталі на етапі виробництва могла призвести до технічної катастрофи. Саме тоді було закладено базові поняття дисципліни: ідентифікація конфігурації, контроль змін та технічний базис (), які згодом були формалізовані у військових стандартах (зокрема, серії MIL-STD)Institute of Configuration Management. History of Configuration Management ..

У 1960-х та 1970-х роках, із розвитком бортових комп'ютерів, аерокосмічні відомства (зокрема NASA) почали застосовувати ці інженерні практики й до цифрових систем. Згодом, коли програмне забезпечення перетворилося на самостійну індустрію, народилася дисципліна конфігураційного керування ПЗ (SCM)Bersoff, E. H. (1984). Elements of software configuration management. IEEE Transactions on Software Engineering, (1), 79-87.. Процес адаптації вимагав переосмислення «твердих» фізичних підходів: на відміну від металевих деталей, вихідний код є абстрактним, гнучким та змінюється значно швидше. Це зрештою зумовило перехід від суворих паперових регламентів до створення автоматизованих систем контролю версій та сучасних практик DevOps.

Основні складові SCM (за SWEBOK) Згідно з міжнародним керівництвом до зводу знань з інженерії програмного забезпечення (SWEBOK), область знань «Керування конфігурацією ПЗ» складається з шести взаємопов'язаних розділів. Цей розподіл також узгоджується з міжнародним стандартом ISO/IEC 12207, який визначає керування конфігурацією як один із допоміжних процесів життєвого циклу ПЗ, виконуваний технічним і адміністративним менеджментом проєкту .

Керування процесом конфігурації (Management of SCM Process) Це діяльність із планування та контролю еволюції і цілісності продукту при ідентифікації, змінах і забезпеченні звітною інформацією. Вона охоплює: Систематичне відстеження внесених змін в окремі складові частини конфігурації, виконання аудиту змін і автоматизованого контролю за внесенням змін у конфігурацію системи або в ПЗ. Підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації. Ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами. Трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ.

Ідентифікація конфігурації ПЗ (Software Configuration Identification) Полягає в документуванні функціональних і фізичних характеристик елементів конфігурації, а також в оформленні технічної документації на них. На цьому етапі визначається склад функцій, програмного і технічного забезпечення системи, а також їхні можливі комбінації залежно від наявності устаткування, загальносистемних засобів і вимог до продукту.

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

Контроль конфігурації ПЗ (Software Configuration Control) Координація, затвердження або відхилення реалізованих змін в елементах конфігурації після їхньої ідентифікації, а також аналіз вхідних компонентів конфігурації. У межах цього процесу проводиться обов'язкова перевірка відповідності внесених змін заданим вимогам.

Облік статусу конфігурації ПЗ (Software Configuration Status Accounting) Комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін у систему при супроводі (фіксація поведінки або станів конфігурації). Інформація і кількісні показники накопичуються у відповідній базі даних і використовуються при складанні звітності, оцінюванні якості і виконанні процесів життєвого циклу.

Аудит конфігурації ПЗ (Software Configuration Auditing) Діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи. На основі аудиту складаються звіти про зміни, внесені у конфігурацію, і ступінь їхньої реалізації.

Керування версіями ПЗ та доставкою (Software Release Management and Delivery) Процес відстеження наявної версії компонентів конфігурації, створення нових версій системи на основі існуючих та забезпечення оперативного доступу до інформації про елементи конфігурації. Цей розділ безпосередньо включає управління випуском (release management) і поставкою (delivery) готового продукту користувачам. Стратегії розгалуження (Branching Strategies) У контексті конфігураційного керування стратегії розгалуження визначають правила та процеси, за якими розробники взаємодіють зі спільним кодом у межах репозиторію. Оскільки над одним продуктом паралельно працюють десятки інженерів, вибір правильної стратегії є критичним для запобігання конфліктам коду, збереження стабільності базису (baseline) та забезпечення безперервної інтеграції.

Найбільш поширеними в сучасній інженерії є дві моделі розгалуження:

GitFlow — класична модель розгалуження, орієнтована на чіткі релізні цикли. Вона передбачає використання двох постійних довготривалих гілок: `main` (або `master`), яка містить виключно стабільний продуктовий код, готовий до релізу, та `develop` — основна гілка для інтеграції нового функціоналу. Для розробки окремих фіч створюються тимчасові гілки `feature`, які після завершення робіт зливають у `develop`. Перед релізом створюється ізольована гілка `release` для фінального тестування та виправлення багів, а для термінових виправлень на продакшені — гілки `hotfix`. Ця модель забезпечує високий рівень контролю конфігурації, але може уповільнювати швидкість доставки змін. Trunk-Based Development — сучасна гнучка модель розгалуження, яка є базовою для практик CI/CD та методології DevOps. За цієї стратегії всі розробники зливають свої зміни в одну основну гілку (часто звану `trunk` або `main`) щонайменше раз на день. Гілки для окремих завдань є дуже короткоживучими (існують від кількох годин до пари днів). Такий підхід мінімізує виникнення так званого «пекла злиття» () — ситуації, коли тривала паралельна розробка в ізольованих гілках призводить до масових і важковирішуваних конфліктів при спробі об'єднати код. Для безпечного приховування незавершених функцій у стабільній гілці застосовується техніка перемикачів функціоналу (). Керування версіями базується на таких основних поняттях: Базовий стан (baseline): Формально позначений набір елементів ПЗ, зафіксований на процесах життєвого циклу. Бібліотека ПЗ: Колекція об'єктів ПЗ і документації, призначена для полегшення процесу розроблення, використання і супроводження. Складання ПЗ (Software Build): Об'єднання коректних елементів і конфігураційних даних у єдину виконувану програму. Сучасний контекст та інструментарій Сучасна інженерна практика конфігураційного керування (SCM) значно еволюціонувала з моменту появи перших стандартів і сьогодні є невіддільною складовою методології DevOps та автоматизованих процесів розробки. Практична реалізація SCM базується на трьох китах: системах контролю версій, платформах спільної розробки та автоматизації (CI/CD).

Системи контролю версій (VCS) Ядром сучасного конфігураційного керування є системи контролю версій (). Еволюція цих інструментів пройшла шлях від локальних та централізованих систем (таких як SCCS, CVS, Subversion / SVN) до розподілених систем (), серед яких абсолютним індустріальним стандартом став Git (також використовується Mercurial).

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

+ Порівняння підходів до контролю версій в SCM Характеристика Централізовані VCS (напр., SVN) Розподілені VCS (напр., Git) Зберігання історії змін Тільки на одному центральному сервері Локально у кожного розробника (повна копія репозиторію) Автономна робота Неможлива без постійного доступу до мережі Повноцінна робота (комміти, перегляд історії) без мережі Операції розгалуження (Branching) Повільні, потребують взаємодії з сервером Миттєві, виконуються повністю локально

Платформи для спільної розробки Сучасні інструменти SCM вийшли за межі простого збереження коду. Такі вебплатформи, як GitHub, GitLab та Bitbucket, перетворилися на комплексні екосистеми для керування конфігураціями. Вони об'єднують в одному інтерфейсі: Керування репозиторіями та гілками коду; Системи відстеження помилок та завдань (); Інструменти для рецензування коду () через механізми запитів на злиття коду (); Керування правами доступу та політиками захисту релізних гілок.

Автоматизація та CI/CD Сучасний контроль конфігурацій неможливий без практик безперервної інтеграції () та безперервної доставки (). Використання таких інструментів автоматизації, як Jenkins, GitHub Actions, GitLab CI/CD чи CircleCI, кардинально змінило підхід до реліз-менеджменту.

Процес збирання програмного забезпечення (), який раніше виконувався вручну, тепер відбувається автоматично за допомогою спеціальних конвеєрів () при кожному комміті або створенні запиту на злиття. Роботизовані скрипти самостійно компілюють код, запускають тести для перевірки цілісності системи та формують готові до розгортання артефакти. Це мінімізує людський фактор, запобігає появі непередбачуваних помилок при злитті коду від різних розробників і гарантує, що базис (baseline) системи завжди залишається стабільним. Практичне значення: які проблеми вирішує SCM У практичній інженерії впровадження конфігураційного керування дозволяє усунути типові ризики та критичні проблеми, з якими стикаються команди розробників у щоденній роботі. Особливо гостро ці проблеми проявляються під час масштабування проєктів.

Проблема «Працювало ж на моїй машині» (). Поширена ситуація, коли код бездоганно виконується на комп'ютері одного розробника, але викликає збої після розгортання на тестовому чи продуктовому сервері. SCM вирішує це за допомогою чіткої ідентифікації конфігурації оточення, фіксації версій залежностей, бібліотек та системних налаштувань. У сучасних підходах це реалізується через концепцію «інфраструктура як код» () та контейнеризацію, що гарантує ідентичність середовища на всіх етапах життєвого циклу ПЗ. Трасування помилок та ревізія змін. Коли в новому релізі X виявляється критична помилка (баг), SCM надає можливість виконати точне трасування. Завдяки повній історії змін та інструментам автоматизованого пошуку (наприклад, `git bisect` та `git blame`) команда може миттєво визначити, який саме комміт (зміна), коли і ким саме був внесений, та які рядки коду призвели до регресії. Це значно прискорює процес зневадження та відновлення стабільної версії системи.