소프트웨어 공학 (15), Configuration Management

Configuration Management

---

0. Overview

1) Configuration management란?

우리가 만들 소프트웨어 프로덕트에 들어가는 다양한 소스코드, 자원 등에 대해 유지/관리하는 것

---

(1) Configuration management

- 소스 코드를 관리하고 변경되면 이력이나 파일도 관리하고, 이를 가지고 실제 릴리즈할 때 특정 릴리즈 버전에 대한 이력 등도 관리한다.

- 소프트웨어에 들어가는 여러 것들을 버전별로 이력과 함께 관리하는 것이다.

- 소스코드와 정책, 절차, 도구 등이 포함된다.

- CM을 통해서 수정이 발생하면 어떤 파일에 대해 어떤 이유로 언제, 어떤 부분이 바뀌었는지, 이후 결과물과 버전을 관리할 수 있다.

- 소프트웨어가 계속 개선되고 나아지면서 이볼루션 과정을 거치면서 릴리즈를 계속 만들어서 배포하기에 각 릴리즈마다 들어가는 것들을 컨트롤할 수 있어야한다.

 

(2) Configuration management activities

i) version management

- 큰 변화가 있으면 2.0, 3.0, 작은 변화가 있으면 1.1, 1.2 이런 식으로 올라간다.

- 시스템이나 컴포넌트 수준에서 변화가 된 것들을 관리한다.

- 버전은 진화하며 소스코드나 시스템의 버전을 명시한다.

- 시간이 지남에 따라 겪는 변화에 따른 소프트웨어 버전과 왜 바뀌었는지, 어떤 점이 바뀌었는지 등을 관리한다.

- 여러 사람이 소프트웨어를 수정하고 교환할 때 각자 작업을 할 때 방해를 받지 않고, 함께 동시에 일을 할 수 있다. 또한 다른 사람이 수정된 버전이 아닌 다른 버전을 사용도 할 수 있다.

 

ii) System building

- 소스파일이나 헤더파일 등등을 합치는 단계이다.

- c++ 등등의 언어는 컴파일과정을 거친다.

- system integration

 

iii) Change management

- 여러 버전이 존재하고, 버전에 따른 이력을 기록하여 누가, 언제, 어떤 이유로, 어떤 것을 바꾸었는지 저장하고 추적한다.

- 수정을 요구할 때 이를 받아들일지 말지 정하여 개발로 넘기는 과정도 포함된다.

- 절차, 규정, 도구도 모두 포함한다.

 

iiii) Release management

- 고객에게 소프트웨어를 제공하는 것을 관리하는 것으로 일정기간 소프트웨어에 대해 보장을 해야한다. 

- 다른 고객을 위해 다른 버전을 만든다면 여러 다른 버전의 소프트웨어를 유지할 수 있어야한다.

 

[Configuration managemnet activities]

- 컴포넌트가 개발과정에서 수정되고 변화될 수 있는데 각각의 컴포넌트를 시스템 단위로 빌딩하고, 시스템도 버전 관리한다. 변화에 대해 관리하고 시스템을 릴리즈하는 단계도 진행된다.

---

2) Agile development and CM

- Configuration Management에서 Plan based 접근은 하나의 흐름으로 존재해 통합하는 단계이지만 Agile에서는 끊임없는 반복 과정 이후 매번 소프트웨어를 출시하기에 Configuration management는 중요하다.

- 매일 Configuration management는 일어나고, 이를 자동화하도록 노력해야한다고 강조한다.

- 모든 개발자가 공유하는 저장공간(Shared project repository)에 우리 프로젝트와 관련된 파일을 가져와서 내 저장공간(Private workspace)에 카피해 이를 수정한다. 또한 다른 사람의 코드도 가져올 수 있어서 문제가 없으면 이를 share space로 옮긴다. 모든 사람들의 파일을 가져올 수 있기에 테스트도 손쉽게 할 수 있다.

---

3) Development phases

- 새롭게 개발하는 새로운 기능을 추가하는 것이 중요하다.

- 시스템을 테스트하는 단계에서는 기존 피처가 문제없는지, 버그는 없는지 등을 확인한다.

- 릴리즈 단계에서는 고객에게 소프트웨어를 내놓을테니 번호를 달고 이를 고객에게 전달한다.

 

---

4) Multi-version system

- 내가 만든 소프트웨어를 고객에게 드렸을 때 자잘한 버그나 큰 버그, 요구사항을 뺀 부분을 추가한다. 이후 소프트웨어의 버전은 점차 증가한다. 1.1 -> 1.2 -> 1.3 -> 2.0 등등

- 이때 각 고객마다 원하는 버전이 다를 수 있다. 따라서 소프트웨어는 하나의 버전만 존재하는 것이 아니라 여러 버전이 존재하게 된다. 이때마다 유니크한 번호를 줘서 이를 구분할 수 있도록하고, Configuration management에서는 이력이 각각에 이력이 남고, 똑같이 빌드할 수 있도록 작업을 해야한다.

 

[Multi-version system development]

- 릴리즈될 때는 R을 붙여서 이를 표시해준다.

- Major한 버전이 있을 때마다 소수점 앞에 있는 숫자를 늘려간다.

- Agile인 경우에는 버전이 더 자주, 많이 발생한다.

- V1.3 V1.5는 메인 라인, R1.0, R1.1은 베이스라인이다.

 

5) CM 용어

Codeline: 소프트웨어 컴포넌트의 버전에 대한 집합으로 특정 소스코드나 자원파일들의 집합을 의미한다.

Baseline: 시스템을 구성하는 컴포넌트 버전에 대한 집합으로 해당 버전을 바꾸면 안된다. 

Branching: 새로운 코드라인으로 가지치기 하는 것이다.

Mainline: 베이스라인의 시퀀스

Configuration(version) control: 위에 있는 것을 컨트롤하는 것이다.

SCI: 위의 대상이 되는 것들

 

예시

- 특정 버전을 모아두면 베이스라인이 되고, 이는 바뀌면 안된다.

- A라고 되어있으면 통상 최신 버전을 사용한다.

 

 

Merging: 수많은 버전을 합칠 때 사용한다. 시험삼아 만든 브랜치를 합치는 것을 의미한다.

Release: 고객에게 소프트웨어를 제공하는 것

Repository: 저장공간

System building: 실행파일을 만드는 것

Version: 각 파일의 버전

Workspace: 내가 파일을 수정하는 공간으로 다른 사람들이 개입할 수 없다.

 

---

1. Version management

1) Version management 

(1) 개요

- 수많은 파일의 버전을 관리하는 것으로 많은 개발자들이 서로 개발한 것을 합치는 경우에도 영향을 받지 않도록 도와준다. 

- 코드라인, 베이스라인을 관리하는 것이다.

- 구현 방법은 두 가지로 나눈다.

i) Centralized systems

- 시스템에 들어갈 모든 파일이 한 곳에 중앙 집중으로 관리된다.

- 내 컴퓨터에는 일부분만 가져와서 사용하고, 마스터 서버에는 모든 것이 다 들어가있다.

- Subversion

 

ii) Distributed systems

- 여기저기에 다 있어서 사용한다.

- 서버가 존재하긴 하지만 본인이 수정한 사항과 함께 오리진 파일을 가지고 있기에 마스터 본 프로그램을 가지고 있다. 프라이빗 워크 스페이스는 별도로 다운받는다.

- Git (Git hub)

 

 

(2) Codeline and baseline

- 코드가 바뀌었을 때 왜 바뀌었는지 이력을 관리하고, 필요할때마다 쓸 수 있어야한다.

- 소스코드나 파일은 서로 다른 버전을 가질 수 있는데 이를 관리할 수 있어야한다.

- 베이스라인: 사용할 파일들의 버전은 바뀌면 안된다.

 

(3) Baselines

- 형태가 정해져있는 파일을 만든다. (어떤 버전의 컴포넌트를 사용할 것인지 써야한다.)

- 특정 파일의 어떤 프로그램을 어디에서 가져올지 이를 정하고, 어떤 것이 먼저할지 정해야하는데 이와 관련된 특정 프로그램(Configuraton language)이 있다. 

- 명세서가 존재한다.

- 고객마다 서로 다른 릴리즈가 나갈 수 있고, 특정 고객이 문제가 있다고 한다면 새롭게 버전을 만들어서 관리해야한다. 

 

(4) Key features of version control systems

- 버전: 개별 소프트웨어에 매겨지고 이들이 묶여서 시스템으로 만들 때도 매겨진다.

- 버전은 매우 많이 발생한다. 또한 이러한 버전을 트랙킹하는 과정도 수반된다.

- Change history recoding: 변화가 어떤 파일에 대해서 누가 언제 왜 어떻게 반영됐는지 등 change history도 기록한다.

- Suppory for independent development: 각 파일들이 독립적으로 개발되면 이를 통합한다. 이때 충돌이 발생하지 않게 독립적인 개발 지원이 필요하다.

- Project support: 프로젝트 지원도 필요하다.

- 파일이 모두 스토리지에 저장되어야하기에 이와 관련된 관리가 필요하다. 

- 스토리지 매니지먼트: 이력을 모두 저장하는게 용량이 매우 커진다. 따라서 디스크 공간 최적화가 중요했다. ex) 버전 컨트롤 시스템은 변경된 내용만 저장한다. (모든 파일의 내용을 저장하지는 않는다.) 디퍼런셜 코딩

---

2) Repository

(1) Public repository and Private workspace

- 중앙집중형이면 서버에 프로젝트 레포지토리를 모두 가지고 있고, 개발자는 필요한 만큼만 프라이빗 워크 스페이스로 가져온다.

- Check out: 마스터로부터 파일을 카피해서 프라이빗 워크스페이스에 저장하는 행위

- Check in: 내 프라이빗 영역에서 작업한 것을 마스터로 올린다. 

 

(2) Centralized version control

- 개발자가 처음 해야하는 것은 check out해서 프라이빗 워크스페이스로 필요한 부분을 카피해야한다.

- 작업을 마치고 작업한 것을 프로젝트 레포지토리로 업로드해서 check in을 한다.

- 동시 다발적으로 작업을 진행하기에 내가 다운받고자 하는 것은 다른 사람이 다운받아서 warning을 해주거나 파일을 합칠 때도 문제가 발생할 수 있다.

 

[Repository check in/check out]

 

(3) Distributed version control

- 서버에 마스터 레포지터리가 만들어지고, 이를 전체 다 카피해서 사용한다. 여기서 내용을 수정하거나 따로 수정해서 작업을 한다.

- 마스터의 클론을 한다.

 

cf) Distributed에서 많이 사용하는 용어

- Commit: 수정한 부분에 대해 마킹한다.

- push: 개발을 마친다면 이를 마스터 서버에 넣는다.

- pull: 요청을 보내서 허가를 받고 푸쉬를 한다.

 

예시

 

 

(4) Benefits of distrbuted version control

- 깃허브에 오픈소스가 몰려있다. 오픈 소스가 많이 쓰이는 상황에서 분산을 많이 사용한다.

- 모두가 클론을 가지고 있어서 마스터 서버가 무너져도 복원을 할 수 있다.

- 각자 클론을 가지고 있기에 서버를 통해 통신을 할 필요 없이 전체 일부분을 개발하고, 본인 스스로 테스트한 뒤 업로드하기 좋다. -> 클론 만들고, 업로드할 때만 해도 된다.

 

(5) Open-source development

- Distributed version control을 많이 사용한다. 전세계 사람들이 모두 같이 개발을 하기에 이는 중요하다.

- pull: 개발자가 본인이 수정한 것을 통합 관리자에게 요청(pull requests)을 하고 이를 푸쉬할지를 정한다.

 

---

3) Branching and merging

- 버전을 기반으로 새로운 코드를 만드는 것은 브랜치이다.

- 떨어져있는 코드라인을 합쳐서 하나로 만드는 것은 머지이다.

- 브랜치로 따로 작업한 뒤 하나로 머지한다. 앞에 있는 코드에서 뒤에 있는 코드로 갈 때 변한 값만 수정한다. 이는 델타라고 불러서 이를 합친다.

---

4) Storage management

(1) Storage management 방법

- 디스크가 비싸서 델타만 저장하여 이를 최적화하고자 했는데 요즘은 안그러기도 한다. 하지만 대부분 이를 지킨다.

 

- 일반적으로는 최신 버전을 저장한다. 다른 버전의 코드가 필요하다면 델타를 역으로 추적해가며 어떤 변화가 있었는지를 반영해서 각 버전에 대한 내용을 꺼낼 수 있다.

 

(2) Storage management in Git

- 델타를 저장하기보단 압축기법을 사용해 통채로 내용을 저장한다. 단, 동일한 파일을 중복되게 저장하는 것을 방지한다. 

---

2. System building

1) 개요

- 소스 코드, 파일 등을 합쳐서 실행가능한 파일로 만든다.

- 개발을 위해 버전 매니지먼트 도구를 사용했으니 이와 연결해야한다.

---

2) Build platforms

- 빌드 소프트웨어를 합치는 과정을 하는데 최종적인 실행파일을 만드는 서버를 build server라고 하고, 프라이빗한 곳에서 작업을 하는 것은 development system이라 한다. development system은 IDE을 포함하기에 컴파일러, 링커, 디버거 등이 들어가서 개발자에게 제공한다. 

- 소프트웨어가 실행되는 환경을 target environment라고 한다. development system과 target environment은 다를 수 있다.

 

- 빌드할 때 어떤 순서로 할지 등에 대해 컨피규레이션 파일이 있어서 이를 통해 빌드한다.

- 컴파일러/인터프리터가 빌드 시스템과 연결된다.

 

(2) Build system functionality

- 빌드 스크립트: 어떤 툴을 사용해서 빌드할지를 써놓는다.

- 버전 매니지먼트 시스템에 가져와야할 게 있다.

- 미니멀 리컴파일: 윈도우즈나 MS 오피스와 같은 것을 빌드할 때는 매우 많은 시간이 든다. 바꾸지 않은 소스코드는 다시 빌드하지 않고, 이전에 컴파일한 것은 굳이 컴파일 하지 않는다. 이를 통해 시간을 줄인다.

- 실행 가능한 파일을 만든다.

- 테스트 자동화 

- 리포팅: 빌드 후 문제가 없는지

- Documentation generation: 사람이 보고 확인할 수 있다.

---

3) system plaforms

- 위의 내용과 동일하다. 다른 점은 아래와 같다.

- 실시간으로 돌아가거나 임베디드인 경우에는 개발 환경(시스템)과 타겟 환경(시스템)이 완전히 다르다. 예를 들어 안드로이드 어플리케이션을 짜면 개발 시스템은 주로 맥캔토시 컴퓨터, 안드로이드 스튜디오가 깔려있는 컴퓨터가 되는데 이는 사용되는 곳과는 다르다.

- 결국 주로 작고, 간단한 환경이 타겟 환경이 되는 경우가 많다. 

- 극단적으로는 스마트 전구가 예시가 될 수 있다. 

- 디밸롭하고 빌드하는 환경은 열악할 수 있다.

 

[Development build and target platfroms]

- 빌드 서버가 빌드하고 타켓 시스템이 실행가능한 파일로 만든다.

---

4) Agile building

(1) Agile building 과정

- 빌드, 테스트를 하고, 이를 바꾸는 등은 내 컴퓨터에서 하고, 체크인 후에는 다른 사람 코드에 내 코드를 추가한다. 모두 합쳐진 상황에서도 테스트를 진행한다. 내가 만든 코드가 내 컴퓨터, 다른 사람의 코드를 반영했을 때도 돌아가면 문제가 없다. 이를 통합하고, 최종버전으로 릴리즈된다.

 

(2) Continuous Integration

- 통합하는 단계는 plan based나 agile은 동일하지만 Continuous가 매우 중요하다. 

- 하루에도 몇번씩 끊임 없이 개발하고 통합한다. 이에 따라 사람이 하는 것은 최소화해야한다. 따라서 CI(Continuous INtegration), CO(Continuous operation)은 대부분 소프트웨어 툴을 사용해 자동화로 한다. 

 

(3) Pros and cons of continuous integration

- 장점: 다른 사람과 독립적으로 작업한다. 매일 통합을 하면 항상 최신 버전의 동작가능한 소프트웨어가 존재한다. waterfall은 한참 이후에 사용 가능하다.

- 단점: 시스템이 매우 크다면 빌드하는데 매우 오랜시간이 걸린다. 이에 따라 매일 통합하는 것이 매우 어렵다.  개발 플랫폼과 타겟 플랫폼이 다르면 이것 또한 쉽지 않다. 수정/빌드/체크 등을 하는데 꽤 오랜 시간이 걸리기 때문이다. 플러터는 이를 개선했다. 

 

(4) Daily building

- 매일 빌드하는 경우이다. 

- 빌드 시간을 정한다. 모든 개발자는 빌드 시간 이전에 개발을 마치고 테스트도 마쳐야한다. 

- 이러한 경우에는 빌드 시스템이 자동으로 빌드하고 테스트 팀에게 전달한다. 테스트 팀도 자동화된 도구를 가지고 테스트한다.

- 이를 앞에서 얘기한 agile의 continuous하게 한다면 시간에 맞춰서 빌드 시스템에 이를 올리고, 예약한 시간에 맞춰서 자동으로 빌드할 것이다. 이후 테스팅 소프트웨어를 끄집어내서 자동으로 테스트한다. TDD 코드도 사용할 수 있고, part1에서 단계별로 테스트를 진행하기도 한다. 사람이 개입하지 않는다. 이후 소프트웨어가 리포팅한 것을  띄운다. 자동으로 워닝, 에러, 에러 레벨 등을 담당자에 이메일을 자동으로 보낸다. 이후 리페어한다. 얼마나 주기를 빠르게 하냐에 따라 CI를 할 수 있다. 개발자가 본인의 코드로 통합하면 자동화가 가능하다.

---

5) Minimizing recompilation

- 앞서 빌드를 한번 했고, 그 과정에서 컴파일된 버전이 있으면 재사용하도록 한다.

- 이를 위해 시그니처를 준다. 이는 소스코드나 파일에 유니크한 식별자를 주는 것이다. 동일한 내용의 파일인지 아닌지 이를 통해 확인한다.

 

---

6) File indentification

(1) Modification timestamps

- 파일이 언제 수정됐는지에 대한 시간을 남긴다. 매우 작은 시간을 주어 이를 구별한다. 하지만 이는 자주 쓰지는 않는다.

(2) Source code checksum

- 더 많이 사용하는 방식으로, 공식을 하나 만들어서 파일을 읽을 때 입력파라미터를 전달한다. 이에 따라 바뀌는 상태값이 존재하는데, 이를 함수에게 전달하고 파일이 끝났을 때 파일에 대한 checksum 값이 나온다.

 

- checksum이 같으면 같은 파일, 다르면 다른 파일이다. 

- timestamp는 시간을 숫자로 환산한다. 

---

3. Change management

1) Change management

변화에 대한 요구사항을 어떻게 반영할지를 관리한다.

---

(1) 개요

- 고객이 요구하거나 버그 리포트를 받아서 수정한다.

- 기능 개선이나 버그를 모두 받아서 모두 처리하는 것이 아닌 비용이나 장단점, 여건, 우선순위를 분석하는 것으로부터 시작한다. 이후 체인지하자고 승인이 나면 시스템에 반영한다. 이를 change management라고 한다.

 

(2) 프로세스

- 고객이 변화 요청을 할 수 있고, 혹은 Customer support에서 이를 받아서 chage requests가 발생할 수 있다. 고객 대응센터에서도 고객만족도 측면에서 굳이 변화가 필요없다고 판단되면 Change request를 날릴 수 있다. 

- Change requests이후 해당 부서로 오고, select가 되면 수정하고 이를 테스트해서 반영한다. 이를 다 반영하면 close한다. 혹은 개발이 없는 CR를 close할수도 있다.

- 변화에 따른 비용, 영향을 계산한다. 주로 프로젝트 리더가 이를 분석한다. 이후 이를 등록한뒤 수정을 한다.

 

---

2) Change requests from

- 누가 변화 요청을 했는지, 언제 했는지, 무슨 내용을 요청하는지 먼저 작성하고, 분석을 한 뒤에는 분석한 사람, 영햐을 받는 관련 요소 등을 전달받는다.

- 이후 승락을 받으면 작업과 우선순위 등을 적고, 소요 시간, CCB(이를 받아들일지 결정을 낸 기간) 등등에 대한 내용이 채워진다.

- 추가적인 정보가 절차가 진행되면서 채워진다.

---

3) Factors in change analysis

- 변화에 대해 고민을 해봐야할 부분

- 꼭 변화를 해야하는가?

- 고객 중에 얼마나 이와 관련이 있는가

- 변화를 통한 이익이 무엇인가

- 변화를 위해 투입되어야하는 비용이 얼마나 되는가

- 다음 버전에 해도 되는가? 그러면 다음 버전에서 개발을 진행한다. 

---

4) Derivation history

- 파일 앞에 누가 작성을 했는지, 버전이 얼마인지, 내용은 무엇인지, 언제 만들었는지 등에 대해 작성한다.

---

5) Change management and agile methods

- 스크럼 미팅을 하면서 고객이나 PL이 소프트웨어를 보고 의견을 준다. 이와 관련된 시간을 주기적으로 받는다.

- 새롭게 개발을 해야하는 것보다 지금 코드에서 변경해야할 부분이 있으면 먼저 작업을 하는 것이 좋다.

- 소프트웨어를 개선하고, 리팩토링하는 것은 늘상 상시해야한다. 

---

4. Release management

1) Release management

시스템을 고객에게 제공하는 것을 관리한다.

---

(1) mass market software

- 고객이 누군지는 모르겠지만 필요할 때 가져다가 쓴다.

- 오픈소스 소프트웨어도 이에 해당된다.

- major releases: 매우 큰 변화가 있을 때의 버전

- minor releases: 버그 개선이나 매우 작은 변화가 있을 때의 버전

 

(2) custorm software

- 누구의 요청에 의해 제작한 커스터마이즈된 소프트웨어

- 개별 고객을 위해 릴리즈가 달라진다.

- 고객도 여러 명이 사용하기도 하고, 별도의 기능을 따로 반영하면 동시에 많이 돌아간다.

- 릴리즈에 대한 관리가 매우 중요하다.

 

---

2) Release components

- 소프트웨어에 대한 릴리즈에 대해 관리해야하는 것은 다음과 같다.

- 소스코드, 컨피규레이션 파일, 데이터 파일, 문서, 설치 프로그램 등이 될 수 있다.

- Reproduce, re-created가 동시에 계속 이루어져야하기에 이를 계속 관리하는 것이다.

---

3) system release, planning

- 언제 우리가 릴리즈를 해야하는지 결정하는 인자다.

- 경쟁자, 마케팅 팀의 의견, 플랫폼이 바뀌는 경우(하드웨어 플랫폼도 포함된다.), 시스템 품질

---

4) Release creation

- 소스코드를 만들어서 형상관리툴에 넣는 것, 컨피규레이션 파일을 통해 빌드하는 것, 인스트럭션을 업데이트하는 것, 설치하는 방법에 대한 스크립트, 홍보 웹페이지 등등도 릴리즈하기 위해 필요한 요소이다.

---

5) Release tracking

- 트랙킹은 어느 순간에 이전 버전 중 하나를 정확히 만들어야하는데, 이를 고객에게 전달하기 위해 트랙킹은 필요할 수도 있고, 문제가 발생할 때 개발환경의 재구축을 위해 필요할수도 있다.

---

6) Release reproduction

- 우리의 소스코드와 데이터도 들어가야하지만 컴파일을 위한 툴, 운영체제, 라이브러리도 관리한다. 

- 우리 소프트웨어가 운영하고 빌드되는 환경도 포함해야한다.

---

7) Release planning

- 시간이나 다양한 부분을 정의한다.

---

8) Software as a service

- 소프트웨어를 배포하기에 설치하는 것을 기준으로 얘기했으나 이미 설치가 되어있으면 이를 바꾸기 어렵다. 이에 따라 웹베이스드로 많이 한다. 따라서 서버형 프로그램과 웹 베이스드 프로그램이 많아진다. 이는 실행을 할 때 고객에게 최신 버전을 전달할 수 있다.

- 최근에는 SaaS처럼 웹 베이스드인 경우에는 릴리즈에 용이하다.