Software Engineering - Configuration Management

Configuration management (CM)

• Software system은 개발, 사용 중에 끊임없이 변화한다.
• Software system의 소스코드, 자원, 변경 내용과 이력, 버전별 내용, 정책, 프로세스, 개발도구 등을 관리한다.
• 변경이 발생하면 변경 파일, 변경 이력을 관리하며, 출시 시에는 특정 버전에 어떤 파일이 들어갔는지, 어떤 변화가 생겼는지에 대하여 관리한다.
• 각 버전별의 수정 사항, 수정 날짜, 수정 이력, 각 버전에 통합되는 결과물에 대한 이력에 대한 추적이 힘든 일이기 때문에 CM을 통하여 관리하여야 한다.
• 서로 다른 개발자가 참여하는 팀프로젝트에 필수적이다.

CM activities

Version management

• System component에 대한 다양한 버전의 변경 사항 이력을 기록한다.
• 하나의 system을 서로 다른 개발자가 사용하거나 수정할 수 있으며 version management를 통해 서로에게 간섭 없이 목적에 맞게 사용할 수 있다.
• 각각의 사용자의 목적에 맞는 version을 선택하거나 서로 다른 기능을 구현함에 있어 서로에게 간섭을 주지 않을 수 있으며, 특정 개발자의 수정 사항이 다른 개발자에게 영향을 주지 않는다.

System building (building이 중요한 의미)

• Program components, data, libraries를 통합하고 컴파일하여 실행가능한 system을 만든다.
  Change management
• 개발자나 고객을 위한 소프트웨어의 변화 이력을 관리한다.
• 수정의 영향 및 비용 등을 고려하며 수정을 받아들일지 말지에 대하여 결정한다.

Release management

• 외부 출시를 위한 소프트웨어를 준비하며, 고객의 사용을 위한 버전의 변화를 관리한다.
• 항상 최신 버전이 투입되는 것이 아니다
• 목적에 맞게 안정적인 버전이 제공될 수도 있다

Agile development and CM

• Agile은 수정이 매우 잦기 때문에 CM이 매우 중요하며 Tools을 통한 자동화를 이루어야 한다.
• 특정 버전의 components들은 shared project repository에 저장되어 공유되며, 개발자들은 자신의 private works space로 복사하여 작업을 진행한다.
• 개인의 작업 공간에서 코드를 수정하고 통합하여 새로운 시스템을 building하여 안정성을 테스트한다. 테스트가 성공적이라면 수정된 components를 shared project repository로 반환한다.

Development phases

• Development phase에서 개발팀은 software configuration을 관리할 책임이 있으며 소프트웨어에 새로운 기능을 넣는 것이 중요하다.
• System testing phase에서는 버그를 수정하거나 누락된 부분을 보완하는 것이 중요하다.
  • 수정은 버그 수정, 기능 향상, 보안 강화 등에 대하여 이루어지며 새로운 기능을 추가하지 않음
• Release phase에서는 새로운 version number를 달고 고객에게 출시하며 기능을 추가하거나 버그 및 취약점에 대한 수정을 하는 등 책임을 지는 것이 중요하다.

Multi-version systems

• 서로 다른 계발 단계에 대한 다양한 버전이 존재하며, 고객들의 필요에 의해 다양한 버전이 동시 다발적으로 사용될 수 있다.

• 서로 다른 버전에 여러 개발팀이 참여한다.
  

• 버전은 개발 과정에서 변화하며 특정 버전이 선택되어 고객에게 출시된다.

• Minor버전은 사소한 기능의 첨삭, 버그 개선 등이 이루어지지만, major 버전의 수정은 시스템 구조 등이 변화한다.

CM 용어

Codeline

• Software component의 version의 집합과 component와 연관되는 configuration items
  

Baseline

• System을 구성하는 component 버전의 집합
• 특정 버전을 기재하지 않는 이상 baseline안의 component 버전은 바뀔 수 없다.

Branching

• 이미 존재하는 codeline에서 새로운 codeline이 만들어지는 것.
• 이미 존재하는 codeline과 branching은 독립적으로 개발된다.

Mainline

• Baseline의 sequence : system의 다른 버전을 나타낸다.

Configuration control

• 모든 버전의 구성요소를 식별 & 저장하고, 변화를 관리하기 위하여 변화에 대한 이력을 관리하고 기록한다.

Configuration item or software configuration item(SCI)

• Software project와 관련된 디자인, 코드, test data, 문서 등을 포함한 모든 item이 configuration의 대상이 된다.

Merging

• Main branch가 존재하는 상황에서 새로운 버전의 출시가 목적이 아닌 기능 시험을 위해 새로운 branching을 만들고 성공적인 테스트를 거쳐 다시 main branch로 합병되는 것.
• 다른 codeline을 가진 분리된 버전을 합쳐 software의 새로운 버전을 만든다.

Release

• 고객이 사용할 소프트웨어를 출시하는 것

Repository

• 구성요소의 변화에 관한 meta data와 버전의 소프트웨어 구성요소에 관한 shared database

System building

• Software의 구성요소와 libraries를 컴파일 하여 실행가능한 system을 만드는 것.

Version

• Configuration item의 instance
• Version은 고유한 식별자를 갖는다.

Workspace

• 다른 개발자의 사용이나 개발에 영향을 주지 않고 작업을 할 수 있는 private work area

Version management

• Codeline, mainline 등의 수많은 파일들이 merging, 수정 및 개선, re-building 등 수많은 작업이 필요하며 이것을 총체적으로 하는 것이 version management
• 서로 다른 버전에 대한 이력을 관리하는 작업.
• 서로 다른 개발자는 서로에게 간섭을 일으키지 않도록 해야 한다.
• Codeline과 baseline 관리가 주목적이라고 할 수 있다.

Codeline과 baseline

Codeline : Sequence of versions of source code

• Codeline은 각각의 구성요소에 대한 서로 다른 버전을 가질 수 있다.

Baseline : definition of a specific system

• Baseline은 특정 버전에 대한 구체적인 것을 기술하기 때문에 형태가 정해져 있다.
• Build 과정에서 필요한 파일의 위치나 정보를 text파일에 저장하는데 configuration language를 사용하며 text파일을 읽는 tool이 있다.
• 정해진 양식인 Configuration language를 통하여 어떤 구성요소가 특정 시스템의 버전에 포함될지와 어떤 순서로 가져올지, 어떤 디렉토리에서 가져올지에 대하여 서술한다.
• 완성된 시스템에 포함된 특정 버전에 대하여 버그 확인 등을 위하여 동일 버전을 다시 만들어야 하는 경우도 많으므로 base line에 대한 명세는 중요하다.

Version control systems

• 서로 다른 버전의 구성요소를 식별하고, 저장하며, 접근을 제어한다.
• 크게 2가지의 VC System이 존재한다.

Centralized systems

• 개발된 모든 버전의 구성 요소를 관리하는 하나의 master repository가 있고, 필요시에 전체 부분의 일부분을 private workspace로 가져와 작업할 수 있다.
• Subversion이 중앙 집중형 VC System에 자주 사용되는 tool이다.

Distributed systems

• 다양한 버전의 구성요소를 분산되게 저장한다.
• Git이 분산 VC System의 대표적인 예이다.
• 개발자는 모든 master bone을 복사하여 작업할 수 있으며, private space에서 원본과 수정한 작업본을 가질 수 있으므로 mater bone이 분산되어 있다고 표현한다.

Key features of version control systems

• Version and release identification
• Change history recording
• Support for independent development
• Project support
• Storage management (disk space optimization)
  • 변경된 내용만 저장함으로써 용량을 줄인다.

Public repository & private workspace

• Repository는 master version을 관리하는 저장소를 말하며, private workspace는 개발자가 작업을 하기 위하여 자신의 환경에 master version를 복사해서 작업하는 환경을 의미한다.

Check-out

• project repository에서 private workspace로 복사하는 행위

Check-in

• private workspace에서 수정한 작업을 project repository로 반환하는 행위
  

Centralized version control & distributed version control

• 똑 같은 파일에 대하여 동시에 작업을 한다면 VC System에서 check-out/in 과정에서 경고한다.
• Distributed 환경에서는 개발자가 완료한 작업을 push를 통하여 project repository에 반영할 수도 있고, integration manager의 동의를 구하는 pull request 방식을 사용할 수 있다.
• Commit은 수정했다는 것을 알리기 위한 marking용도
  

Benefits of distributed version control

Backup mechanism

• 모두가 clone을 가지고 있기 때문에 repository가 오염되어도 local copies로부터 복원가능

Off-line working

• 각각의 개발자가 모든 코드를 가지고 있기 때문에 off-line으로 작업이 가능하다.

Project support is the default way of working

• local에서 컴파일과 테스트가 가능하다.

Open-source development

Distributed version control is essential

• 중앙에서의 조정 없이 동시다발적으로 작업을 할 수 있다.
• Pull-request를 통하여 public-repository를 관리할 수 있다.

Delta

• 원래 버전에서 다음 버전에서의 변화값
• Branching이 merging이 될 때 delta값만을 합치는 데 이용한다.
  

Storage management

• 초기에는 storage관리가 매우 중요했으며 delta값만 저장했다.

Storage management in Git

• 최근에는 disk가 저렴 해졌기 때문에, git은 더 빠른 방법은 선택한다.
• Git은 delta를 저장하는 것이 아닌 표준 압축 알고리즘을 통해 파일 전체를 저장하며 그와 관련된 meta-information도 저장한다.
• 중복된 파일은 저장하지 않는다.
• 여러 개의 작은 파일이 인덱스된 작은 파일로 합쳐지는 packfile개념을 사용한다.

System building

• System components, 외부 라이브러리, configuration files 등을 compiling과 linking과정을 거쳐 실행 가능한, 완전한 시스템을 만드는 과정
• System building tools는 version management tools와 상호작용해야 하며 일반적으로 통합된 경우가 많다.

Build platforms

Build server

• Version management tool로부터 소스코드를 가져와서 최종적인 실행파일을 만들어내는 시스템

Development system

• 컴파일러, 소스 코드 에디터 등 IDE를 지칭한다.

Target environment

• 소프트웨어가 실행되는 환경
  

Build system functionality

• Build script generation(configuration 파일과 같이 build의 순서를 지정한다)
• Version management system integration
• Minimal re-compilation (이전에 컴파일한 것이 변경이 없다면 재 컴파일하지 않는다)
• Test automation
• reporting
• Documentation generation
• executable system creation

System platforms

• Real-time이나 embedded system의 경우 개발환경과 target 환경이 다르다.
  

Agile building

• Mainline system에서 check out을 한 뒤 시스템을 build한 뒤 자동적인 테스트를 거쳐야한다.
  • 다운받은 파일이 문제가 없는지 확인하는 과정
• 수정을 하고 private workspace에서 시스템을 build해야 한다.
• Build server의 build system에서 시스템을 테스트하고 이상이 없다면 commit 단계를 거친다.
• Continuous integration : 지속적인 작업이 중요하며 자동화가 중요하다.

Pros and cons of Continuous integration

Pros

• 독립적으로 일을 하며 문제를 발견하고 수정을 빠르게 할 수 있다.
• 항상 최신 버전의 동작할 수 있는 소프트웨어가 존재한다.

Cons

• 시스템이 커지면 빌드에 시간이 매우 오래 걸리기 때문에 빌드와 테스트가 힘들어진다.
• 개발 환경과 target 환경이 다르면 실행이 불가하거나 시간이 매우 오래 걸려 매일하기 힘들다

Daily building

• Plan-based 방식의 경우에 매일 정해진 시간에 빌드를 진행하는 경우가 많다.
• 개발자가 만든 새로운 버전이 있으면 지정된 시간 이전에 완료해야 한다.
• 빌드나 테스트가 자동화되어 진행된다.
• 결과물로 문서가 나오며 그에 따라 문제를 발견하고 수정한다.

Minimizing recompilation

• They do this by checking if a compiled version of a component is available. If so, there is no need to recompile that component.
• 코드가 변경되었는지에 대하여 unique signature로 식별할 수 있다.
• 식별자를 보고 컴파일의 여부를 결정한다.

File identification

Modification timestamps

• 파일이 언제 수정되었는지에 대한 시간 정보를 준다.
• 시간을 추적하는 것도 어렵고, 시스템의 시간 동기화 문제도 있기 때문에 잘 사용되지 않는다.

Source code checksums

• 식별할 수 있는 함수를 만들어 일정 코드를 입력시켜 파일을 식별한다.
• 파일의 이름, 생성 시간 등의 추가 정보를 기입할 수 있다
• 일정한 식이 있고, 파일에서 읽어 드린 일정 부분을 입력 파라미터로 넣는다
• 이전에 들어온 값들에 의해 바뀌는 내부의 값이 있고 이 값으로 식별한다.
  • 내부에서 바뀐 값과 파일의 이름, 내용, 속성 등을 반영한 하나의 코드 값이 나오는데 이것이 checksum이며 이것으로 식별한다.

Change management

• 조직적 필요와 요구사항은 계속해서 바뀌며, 버그는 수정되어야 하고, 환경에 맞게 기능을 개선하는 등의 변화가 일어나야 한다.
• Change management는 시스템 evolution과정을 관리하며, 비용적으로 효율적이고 긴급한 change요구에 우선순위를 부여한다.

1. 비용과 변화에 의한 이익을 분석한다
2. 변화가 가치가 있는지에 대해 분석하고 순위를 조정하는 등의 과정을 거친 후 승인한다.
3. 승인된 요구사항에 대해서는 시스템에 수정되어 들어간다.
   

• 고객 지원에서 해결 가능한 change request를 해결할 수 있다.
• CR분석팀에서에서 추가 개발 없이 다른 방법을 사용하여 CR을 해결할 수 있다.

Factors in change analysis

• The consequences of not making the change
• The benefits of the change
• The number of users affected by the change
• The costs of making the change
• The product release cycle

Change management and agile methods

• 고객이 직접적으로 change management에 참여할 수 있다.
• 새로운 코드보다 기존의 코드를 수정 및 변경을 통해 해결할 수 있는 변화가 있다면 먼저 우선순위를 두고 토론해야 한다.
• Refactoring은 오버헤드가 아닌 개발 과정의 필수 요소이다.

Release management

Mass market software

• 고객을 특정하지 않고 회사에서 정의한 후 판매하는 소프트웨어
• Major release : 소프트웨어의 큰 틀을 수정, 완전히 새로운 버전
• Minor release : 버그 수정, 기능 개선 등

Custom software

• 특정 고객을 위하여 만든 소프트웨어
• 틀은 비슷한 소프트웨어라도 고객에 따라 소프트웨어가 달라진다.
• Release 과정이 많기 때문에 중요하다.

Opensource

• Mass market 특성을 가지고 시작하여 custom의 성질을 띠게 된다.

Release components (RE-CREATE를 위해서 데이터 유지가 중요하다)

• Code / configuration file / data files / installation program / 문서 / packaging

Release tracking

• 소프트웨어가 출시되었다면 이후에도 정확하게 똑 같은 제품으로 만들어질 수 있어야 한다.

Factors influencing system release planning

Release creation

• 프로그램의 실행 가능한 코드와 그와 관련된 데이터 파일은 version control system에서 식별되어야 한다.
• 다른 하드웨어와 운영 체제를 위한 설정 설명서가 있어야 한다.
• 고객이 자신의 환경에서 사용할 수 있도록 update 설명서가 있어야 한다.
• 프로그램의 설치에 관한 script가 있어야 한다.
• 소프트웨어에 대한 정보나 홍보를 위한 web page도 포함된다.

Release reproduction (특정 버전을 복원 가능해야 한다)

• 소스 코드의 특정한 버전에 대해 기록해야 한다.
• 소스코드와 모든 데이터, configuration file 등도 사본을 가지고 있어야 한다.
• 라이브러리, 컴파일러, 운영체제 등 모든 도구에 대한 정보를 가지고 있어야 한다.

Software as a service

• 최근의 소프트웨어는 web-base이다.
• 고객에게 전달되는 코드를 항상 개발자가 가지고 있으며, 개발자의 서버를 수정하여 고객에게 서비스로 제공한다.