[Software Engineering] Configuration and Version Management | 형상 관리 및 버전 관리

Configuration and Version Management

 

형상 관리 및 버전 관리

 

 

 

---

Configuration Management (CM; 형상 관리)

 

- 변화하는 소프트웨어 시스템을 관리하는 Policy, Process, Tool 등을 의미한다.

- 소프트웨어의 최종적인 버전은 Shared Project Repository에 저장된다.

- 개발자는 본인의 Workspace에 dl Shared Project를 복사해와서 작업한다.

 

 

 

Configuration Management Activity (CM Activity)

 

Rectangle: Document, Ellipse: Activity

 

• Version Management (VM)
  - System Component의 다양한 버전들을 추적해가는 것을 의미한다.
  - 개발 단계마다 여러 버전이 존재할 수 있으며,
    다수의 개발팀이 협업하는 환경이라면 버전의 개수는 더더욱 많을 수 밖에 없다.
  - 다양한 버전들이 존재함으로써 각 기능들의 충돌을 방지할 수 있다.
  
  
• Sytstem Building
  - Source Code를 Compile하고, 이를 Library와 Linking하여 Executable System으로 만드는 것을 의미한다.
  
  
• Change Management
  - Requirement, Design 등의 모든 변화를 추적하는 것을 의미한다.
  
  
• Release Management
  - Customer에게 직접적으로 Release하는 External Release를 준비하는 과정이다.
  - Development Version(개발 버전)과 Release Version(출시 버전)은 구분되어야 하며,
    개발 버전이 곧바로 출시되는 것은 아니다.

 

 

 

Multi-Version System Development

 

 

- 다수의 Linear Sequence Version(위 그림의 Version 1, 2, 3)들로 구성된 버전을 의미한다.

- V는 Delopment Version이며, R은 Release Version의 약자이다.

- 버그가 수정되었거나 간단한 기능이 추가될 경우 Release Version이 새로 출시된다. (R 1.0 → R 1.2)

- 비교적 큰 요구사항이 반영되어 새 기능이 추가되거나

  플랫폼이 변경되는 등 큰 변화가 생길 경우 Multi Version이 새로 추가될 수 있다. (Version 1 → Version 2)

 

---

Version Control System (VCS)

 

- 어떤 Component의 다양한 버전들을 저장하고 식별하며 접근 제어하는 시스템을 의미한다.

- Modern VCS는 아래처럼 크게 두 가지 유형으로 구분된다.

• Centralized Systems
  - Singel Master Repsitory만 유지하여 System Component의 모든 버전을 관리하는 시스템이다.
  - CVS, SVN, Subversion 등이 이에 해당된다.
  
  
• Distributed Systems
  - Repository가 여러 버전으로 존재할 수 있는 시스템이다.
  - Git, Mercurial 등이 이에 해당된다.

 

- VCS는 또한 간섭없이 독립적으로 개발하는 것을 지원하기 위해 아래와 같은 Concept을 도입했다.

• Project Repository (Public Repository)
  - 모든 Component의 Master Version을 유지하는 Repository이다.
  
  
• Private Workspace (Private Repository)

 

---

Centralized Version Control

 

- 개발자들이 Project Repository에서 본인이 작업하고자 하는 Component만 Check-Out하여 작업한다.

- Centralized Version Control에서는 Check-Out 연산과 Check-In 연산을 지원한다.

- Distributed Version Control과 달리, Centralized Version Control에서는 Private Repository만의 버전을 가질 수 없다.

 

• Check-Out Operation
  - Public Repository → Private Repository로 복사해오는 작업이다.
  
  
• Check-In Operation
  - Private Repository → Public Repository로 Changed Component들을 저장하는 작업이다.

 

 

 

Example. Check-in and Check-Out Operations

 

1. Alice가 Public Repository로부터 A1.0, B1.0, C1.0을 Check-Out한다.
   
   
2. Bob이 Public Repository로부터 X1.0, Y1.0, C1.0을 Check-Out한다.
   
   
3. Alice가 Check-Out한 Component들을 A1.1, B1.1, C1.1로 수정하여 Check-In한다.
   
   
4. Bob이 Check-Out Component들을 X1.1, Y1.1, C1.2로 수정하여 Check-In한다.
   (이때, Alice에 의해 C1.0이 C1.1으로 Version-Up되었으므로, Bob은 C1.2로 Check-In해야 한다.)

 

---

Distributed Version Control

 

- 개발자들이 Project Repository의 Clone을 생성하여 작업한다.
  (Clone은 Project Repository "전체"의 복사본이다.)

- 개발자들은 Clone을 개선해나가며 New Version을 생성하며
  본인의 Private Repository상에 Commit하고,

  최종적으로 Public Repository에 Push할 수 있다.

 

 

 

Git Operations

 

Simple Diagram for Git Operations

- Remote Repository는 Public Repository를 의미한다.

- Local Repository는 Private Repository를 의미한다.

- Git에서는 Local Repository 내에서도 여러 버전으로 나뉜다.

 

• git pull
  Remote Repository의 Clone(모든 내용)을 Local Repository로 복사하여 옮겨온다. (Check-Out과 유사하다.)
  
  
• git checkout
  - git pull을 통해 가져온 Remote Repository의 복사본 중 한 버전을 선정하여 Working Directory로 옮겨온다.
  
  
• git add (Stage File)
  - 수정한 Component(Snapshot)를 Staging Area(증간 지점)에 추가시킨다.
  
  
• git commit
  - Index에 Adding된 Component들로 새로운 버전을 구성하여 Head에 저장한다.
  - Staging Area의 Snapshot이 영속적으로 유지되도록 Repository로 옮긴다.
  
  
• git push
  - Head의 내용들을 Remote에 반영시킨다.

 

 

 

* Git (URL)

 

[Git] Git Overview | Git 개요

 

 

 

Benefits of Distributed Version Control

 

• Off-Line Working이 가능하다.
  - Off-Line 환경에서는 Push, Pull만 불가능할 뿐, 다른 모든 작업은 오프라인 환경에서 수행할 수 있다.
  
  
• Repository에 대한 Backup Mechanism이 제공된다.
  - Local Repository에 장애가 발생한 경우, Remote Repository에서 다시 Pull하여 복구할 수 있고,
    Remote Repository에 장애가 발생한 경우, Local Copies를 통해 복구할 수 있다.
  
  
• Project Repository와 Private Repository를 독립적으로 관리할 수 있다.
  - 개발자는 Private Repository에서 본인만의 Commit History(Version History)를 가짐으로써
    Project Repository에 독립적으로 개발할 수 있다.

 

 

 

Open Source Development

 

- Open Source Development에서는 특히나 Distributed VC가 필수적인데,

  많은 사람들이 한 프로젝트에 대한 Central Coordination 없이도 개발이 가능하게 하기 때문이다.

- Open Source System Manager가 많은 버전들 중 한 버전을 선정하여 Definitive System을 구성한다.

 

 

 

 

Branching and Merging

- 한 버전은 여러 버전의 Branch로 분기될 수 있으며, 최종적으로는 하나의 버전으로 Merge된다.

- 충돌이 발생하지 않는 경우, Merge는 자동으로 이루어질 수도 있다.

 

---

Reference: Software Engineering 10th Edition
(Ian Sommerville 저, Pearson, 2016)

 

Reference: Object-Oriented Systems Analysis and Design Using UML 4th Edition
(Simon Bennett, Steve McRobb, Ray Farmer 저, McGrawHill, 2010)