> [!abstract] Introduction > 프로젝트의 어떤 요소가 알려지는 일 없이 제멋대로 바뀐다면 참여자 전체에게 영향을 끼칠 수 있기 때문에, 특히 모두에게 열린 프로젝트라면 프로젝트를 통제 하에 두는 것은 매우 중요한 일입니다. 만약 시스템 테스트를 통과하거나 이미 릴리즈된 코드를 개발자가 멋대로 바꾼다면? 이미 구현이 완료된 데이터베이스 스키마를 데이터베이스 관리자가 멋대로 바꾼다면? OpenAPI 스펙을 임의로 바꾸고 공지하지 않는다면? 이 모든 문제를 해결하는 것이 바로 형상 관리*Configuration Management*입니다. # Configuration Management 형상 관리의 목적은 형상을 인식하고, 제어하고, 형상의 변화를 추적하고, 형상을 감시하며 작업물*work product*의 통합성을 유지하는 것이다. 핵심은 프로젝트 내에서 발생하는 모든 변화를 통제하는 것이다. 이를 이루기 위한 세가지 목표가 있고 프랙티스들의 관계는 아래와 같다. ![[ConfigurationManagementDiagram.png]] 이제 각 목표와 하위 프랙티스들을 살펴보자. # Establish Baselines 첫번째 목표는 베이스라인(baseline)을 확립하는 것이다. 그런데 베이스라인이란 도대체 무엇일까? 베이스라인의 정의는 아래와 같다. > [!info] Definition > A set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development, and which can be changed only through change control procedures.(CMMI, IEEE) 베이스라인은 정식으로 리뷰되고 합의된 작업물이나 명세 사항*specification*의 모음집을 의미한다. 이렇게 만들어진 베이스라인은 추후 개발의 초석이 되며, 변화 제어 과정*change control procedure*을 통해서만 바뀔 수 있다. 베이스라인을 세우기 위한 프랙티스는 총 세가지다. ## Identify Configuration Items 우선 형상 관리의 대상이 되는 형상 아이템*Configuration Item*을 파악해야 한다. 그런데 형상 아이템은 대체 무엇일까? ### Configuration Item 형상 아이템이란 사용자에게 전달되는 제품들, 지정된 내부 작업물들, 그리고 이러한 작업물들을 만들고 기술하는 과정에서 얻은 제품이나 도구 등을 모두 아우른다. 형상 아이템에는 요구사항, 계획, 설계 명세 사항, 데이터베이스 스키마, 데이터 모델, 백로그(backlog), 소스 코드, 라이브러리, 바이너리 파일, 테스트 명세 사항, 파일, 테스트용 도구와 스크립트 등이 포함된다. 여기에 더해 컴파일러 등 빌드, 패키징 등의 개발활동에 사용된 도구와 환경, 그리고 빌드 스크립트 등 배포 파이프라인 상의 스크립트도 형상 아이템에 포함된다. ## Establish a Configuration Management System 그 다음 형상 관리 시스템을 확립해야 한다. 그런데 형상 관리 시스템은 구체적으로 무엇일까? ### 형상 관리 시스템 형상을 관리한다는 것은 일종의 검문과 같다. 모든 변경사항을 수용할 필요가 없고, 수용하면 새로운 문제가 생기기도 하기 때문에 절차를 거쳐 필요한 변화만 수용하는 것이다. 그래서 형상 관리 시스템은 의사결정의 과정이기도 하다. ![[TheChangeControlProcess.png]] 위 그래프는 변경 통제 과정을 다이어그램으로 나타낸 것인데, 당연히 이 과정에서 [[Version Control System|버전 관리 시스템]]*Version Control System*은 확립되어 있어야 한다. ## Create or Release Baselines 형상 관리 시스템이 확립되면 베이스라인을 만들거나 릴리즈한다. # Track and Control Changes 다음 목표는 프로젝트에서 발생하는 변화들을 추적하고 제어하는 것이다. 이를 위한 프랙티스는 총 두가지다. ## Track Change Requests for Configuration Items 첫번째는 형상 아이템에 대한 변경 요청을 추적하는 것이다. 새로 만들어지거나 바뀐 요구사항을 위한 것이기도 하지만 작업물에서 오류가 발생하는 원인이 되기도 한다. 그래서 해당 변경이 가져올 영향을 분석하고 이해관계자들과 리뷰하고 합의를 이끌어내야 한다. 그 다음 변경이 문제없이 잘 이루어지는지 끝까지 추적해야 한다. ## Control Changes to Configuration Items 다음 프랙티스는 형상 아이템의 변화를 제어하는 것이다. 각 형상 아이템의 형상을 추적하고 새로운 형상이 인가 절차를 거치도록 해야 하는데 이는 변화가 가져올 영향을 통제 하에 두기 위함이다. 인가 절차를 거치고 나면, 베이스라인을 업데이트하면 된다. # Establish Integrity 세번째 목표는 통합성*integrity*을 확립하는 것이다. 이를 위한 프랙티스는 총 두가지다. ## Establish and Maintain Records Describing Configuration Items 첫번째 프랙티스는 형상 아이템을 기술하는 기록을 만들고 유지하는 것이다. 형상 아이템이 바뀌어온 과정*revision history*, 변경 기록*change log*, 변경 요청 기록*change request records*, 그리고 형상 아이템의 상태[^1]가 기록에 포함된다. ## Perform Configuration Audits to Maintain the Integrity of Configuration Baseline 다음 프랙티스는 형상에 대한 감사를 진행해 형상 베이스라인의 통합성을 유지하는 것이다. 이를 위해 총 세가지 감사가 이루어진다. ### Functional Configuration Audit 기능적 형상 감사*Functional Configuration Audit*는 형상의 완전성*completeness*를 감사하여 모든 요구사항이 충족되었는지를 중점적으로 본다. 넣기로 한 기능이 다 들어가 있는지, 테스트를 통과했는지, 원하는 내용이 다 포함되어 있는지를 보게 된다. ### Physical Configuration Audit 물리적 형상 감사*Physical Configuration Audit*에서는 맞는 제품이 제대로 모여있는지를 평가한다. 인터페이스를 바꿔야 한다면 인터페이스가 물리적으로 제대로 바뀌었는지를 이 감사에서 보게 된다. ### Configuration Managements Audit 형상 관리 감사*Configuration Managements Audit*에서는 형상 관리 기록과 형상 아이템 그 자체가 완전하고, 지속적이고, 정확한지를 중점적으로 본다. [^1]: 준비 안됨*not ready*, 테스트, 빌드, 프로덕션, 더이상 사용하지 않음*deprecated*, 더이상 존재하지 않음*decommissioned* 등의 상태가 존재한다. --- # 출처 - Pressman, R.S. and Maxim, B.R. (2020) _Software engineering: a practitioner’s approach_. Ninth edition. New York, NY: McGraw-Hill Education.