Чому це називається Управління конфігурацією програмного забезпечення (SCM)?

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

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

То чому ми використовуємо термін "Управління конфігурацією програмного забезпечення"? Чи не було б "Управління програмним забезпеченням" більш охоплюючим? Або не вистачає мого розуміння того, що вважається "конфігурацією"?

Термін управління конфігурацією належить до загальної інженерної лексики.

Її мета - вести облік характеристик усіх деталей / компонентів складної системи (наприклад, автомобіля, ракети, електронного пристрою), і звичайно зміна цих характеристик при заміні компонента на аналогічний компонент. Конфігурація описує саме конкретний продукт.

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

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

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