L19L20-Configuration management (Ch25)

Topics covered 다루는 주제

• Version management 버전 관리
• System building 시스템 빌드
• Change management 변경 관리
• Release management 릴리스 관리

 

Configuration management 구성 관리 (CM)

• Software systems are constantly changing during development and use. 소프트웨어 시스템은 개발 중이나 사용 중에도 지속적으로 변경된다.
• Configuration management (CM) is concerned with the policies, processes and tools for managing changing software systems. 구성 관리는 변경되는 소프트웨어 시스템을 관리하기 위한 정책, 프로세스 및 도구와 관련이 있다.
• You need CM because it is easy to lose track of what changes and component versions have been incorporated into each system version. 어떤 변경과 컴포넌트 버전이 어떤 시스템 버전에 포함되었는지를 놓치기 쉽기 때문에 CM이 필요하다.
• CM is essential for team projects to control changes made by different developers. CM은 여러 개발자가 동시에 작업하는 팀 프로젝트에서 변경을 통제하는 데 필수적이다.

 

CM activities 구성 관리 활동

• Version management 버전 관리
  • Keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other. 시스템 컴포넌트의 여러 버전을 추적하고, 다른 개발자가 수행한 변경이 서로 충돌하지 않도록 보장한다.
• System building 시스템 빌드
  • The process of assembling program components, data and libraries, then compiling these to create an executable system. 프로그램 컴포넌트, 데이터, 라이브러리를 조합하고 컴파일하여 실행 가능한 시스템을 만드는 과정이다.
• Change management 변경 관리
  • Keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes should be implemented. 고객 및 개발자의 변경 요청을 추적하고, 변경의 비용과 영향을 분석하여 적용 여부를 결정하는 작업이다.
• Release management 릴리스 관리
  • Preparing software for external release and keeping track of the system versions that have been released for customer use. 외부 릴리스를 준비하고, 고객에게 배포된 시스템 버전을 추적한다.

 

Configuration management activities 구성 관리 활동 흐름

 

Agile development and CM 애자일 개발과 구성 관리

• Agile development, where components and systems are changed several times per day, is impossible without using CM tools. 컴포넌트와 시스템이 하루에도 여러 번 변경되는 애자일 개발은 CM 도구 없이는 불가능하다.
• The definitive versions of components are held in a shared project repository and developers copy these into their own workspace. 컴포넌트의 기준 버전은 공유 저장소에 저장되며, 개발자는 이를 자신의 작업 공간으로 복사하여 사용한다.
• They make changes to the code, and then use system building tools to create a new system on their own computer for testing. Once they are happy with the changes made, they return the modified components to the project repository. 개발자는 코드 변경 후 시스템 빌드 도구를 사용하여 로컬에서 테스트한 후, 변경한 컴포넌트를 프로젝트 저장소에 반영한다.

 

Development phases 개발 단계

• A development phase where the development team is responsible for managing the software configuration and new functionality is being added to the software. 개발 팀이 소프트웨어 구성 관리를 책임지며 새로운 기능을 추가하는 개발 단계
• A system testing phase where a version of the system is released internally for testing. 시스템 테스트 단계에서는 시스템 버전이 내부적으로 배포되어 테스트된다.
  • No new system functionality is added. Changes made are bug fixes, performance improvements and security vulnerability repairs. 새로운 기능은 추가되지 않으며, 변경은 버그 수정, 성능 개선, 보안 취약점 수정 등에 한정된다.
• A release phase where the software is released to customers for use. 고객에게 소프트웨어가 릴리스되는 배포 단계
  • New versions of the released system are developed to repair bugs and vulnerabilities and to include new features. 릴리스된 시스템의 새로운 버전은 버그 수정, 취약점 개선, 기능 추가를 위해 개발된다.

 

Multi-version systems 다중 버전 시스템

• For large systems, there is never just one ‘working’ version of a system. 대형 시스템에는 단 하나의 ‘작동 중인’ 버전만 존재하지 않는다.
• There are always several versions of the system at different stages of development. 서로 다른 개발 단계에 있는 여러 버전이 항상 존재한다.
• There may be several teams involved in the development of different system versions. 서로 다른 시스템 버전을 개발하는 여러 팀이 동시에 참여할 수 있다.

 

Multi-version system development 다중 버전 시스템 개발 

 

CM terminology 구성 관리 용어 정리

Term	Explanation	해석
Baseline	A baseline is a collection of component versions that make up a system. Baselines are controlled, which means that the versions of the components making up the system cannot be changed. This means that it is always possible to recreate a baseline from its constituent components.	베이스라인은 시스템을 구성하는 컴포넌트 버전들의 집합이다. 베이스라인은 통제되며, 그 구성 요소들은 변경될 수 없다. 따라서 동일한 구성 요소들을 사용해 베이스라인을 재구성할 수 있다.
Branching	The creation of a new codeline from a version in an existing codeline. The new codeline and the existing codeline may then develop independently.	기존 코드라인에서 파생된 새로운 코드라인을 생성하는 것. 두 코드라인은 이후 독립적으로 개발될 수 있다.
Codeline	A codeline is a set of versions of a software component and other configuration items on which that component depends.	코드라인은 소프트웨어 컴포넌트와 해당 컴포넌트가 의존하는 구성 항목들의 버전 집합이다.
Configuration (version) control	The process of ensuring that versions of systems and components are recorded and maintained so that changes are managed and all versions of components are identified and stored for the lifetime of the system.	시스템과 컴포넌트의 버전을 기록하고 유지함으로써 변경을 관리하고, 모든 버전이 시스템의 수명 동안 식별되고 저장되도록 하는 프로세스이다.
Configuration item or software configuration item (SCI)	Anything associated with a software project (design, code, test data, document, etc.) that has been placed under configuration control. There are often different versions of a configuration item. Configuration items have a unique name.	설계, 코드, 테스트 데이터, 문서 등 구성 관리 대상이 된 소프트웨어 프로젝트의 항목. 구성 항목은 종종 여러 버전을 가지며 고유한 이름을 갖는다.
Mainline	A sequence of baselines representing different versions of a system.	시스템의 서로 다른 버전을 나타내는 베이스라인들의 연속이다.
Merging	The creation of a new version of a software component by merging separate versions in different codelines. These codelines may have been created by a previous branch of one of the codelines involved.	다른 코드라인에 존재하는 서로 다른 버전을 병합하여 새로운 버전을 만드는 것. 이들 코드라인은 이전 브랜치로부터 파생되었을 수 있다.
Release	A version of a system that has been released to customers (or other users in an organization) for use.	고객이나 조직 내 다른 사용자를 위해 릴리스된 시스템 버전이다.
Repository	A shared database of versions of software components and meta-information about changes to these components.	소프트웨어 컴포넌트의 버전과 변경 내역에 대한 메타정보를 저장하는 공유 데이터베이스이다.
System building	The creation of an executable system version by compiling and linking the appropriate versions of the components and libraries making up the system.	시스템을 구성하는 컴포넌트와 라이브러리의 적절한 버전을 컴파일하고 연결하여 실행 가능한 시스템을 만드는 과정이다.
Version	An instance of a configuration item that differs, in some way, from other instances of that item. Versions always have a unique identifier.	구성 항목의 다른 인스턴스와 어떤 면에서든 차이가 있는 인스턴스를 버전이라고 하며, 각 버전은 고유 식별자를 가진다.
Workspace	A private work area where software can be modified without affecting other developers who may be using or modifying that software.	다른 개발자에게 영향을 주지 않고 소프트웨어를 자유롭게 수정할 수 있는 개인 작업 공간이다.

 

 

 

[2] Version management  버전 관리

Version management 버전 관리

• Version management (VM) is the process of keeping track of different versions of software components or configuration items and the systems in which these components are used. 버전 관리는 소프트웨어 컴포넌트나 구성 항목의 여러 버전과 해당 버전이 사용되는 시스템을 추적하는 과정이다.
• It also involves ensuring that changes made by different developers to these versions do not interfere with each other. 또한 서로 다른 개발자가 수행한 변경이 서로 충돌하지 않도록 관리하는 것도 포함된다.
• Therefore version management can be thought of as the process of managing codelines and baselines. 따라서 버전 관리는 코드라인과 베이스라인을 관리하는 과정으로 이해할 수 있다.

 

Codelines and baselines 코드라인과 베이스라인 

• A codeline is a sequence of versions of source code with later versions in the sequence derived from earlier versions. 코드라인은 이전 버전으로부터 파생된 일련의 소스 코드 버전들이다.
• Codelines normally apply to components of systems so that there are different versions of each component. 코드라인은 보통 시스템의 컴포넌트에 적용되며, 각 컴포넌트에 대해 여러 버전이 존재할 수 있다.
• A baseline is a definition of a specific system. 베이스라인은 특정 시스템 버전을 정의한 것이다.
  • The baseline therefore specifies the component versions that are included in the system plus a specification of the libraries used, configuration files, etc. 따라서 베이스라인은 시스템에 포함된 컴포넌트 버전과 사용된 라이브러리, 설정 파일 등을 명시한다.

 

Baselines 베이스라인

• Baselines may be specified using a configuration language, which allows you to define what components are included in a version of a particular system. 베이스라인은 어떤 컴포넌트가 특정 시스템 버전에 포함되는지를 구성 언어로 정의할 수 있다.
• Baselines are important because you often have to recreate a specific version of a complete system. 베이스라인은 특정 시스템 버전을 재현해야 할 경우가 많기 때문에 중요하다.
  • For example, a product line may be instantiated so that there are individual system versions for different customers. You may have to recreate the version delivered to a specific customer if, for example, that customer reports bugs in their system that have to be repaired. 예를 들어, 고객별로 각각 다른 시스템 버전이 존재하는 제품 라인의 경우, 특정 고객이 버그를 보고하면 해당 버전을 재현해야 할 수 있다.

 

Version control systems 버전 관리 시스템

• Version control (VC) systems identify, store and control access to the different versions of components. There are two types of modern version control system 버전 관리 시스템은 컴포넌트의 여러 버전을 식별하고 저장하며 접근을 제어한다. 현대적인 버전 관리 시스템에는 두 가지 유형이 있다.
  • Centralized systems, where there is a single master repository that maintains all versions of the software components that are being developed. Subversion is a widely used example of a centralized VC system. 중앙집중형 시스템: 하나의 마스터 저장소가 모든 컴포넌트 버전을 관리함. 예: Subversion
  • Distributed systems, where multiple versions of the component repository exist at the same time. Git is a widely-used example of a distributed VC system. 분산형 시스템: 여러 버전의 저장소가 동시에 존재할 수 있음. 예: Git

 

Key features of version control systems 버전 관리 시스템의 핵심 기능

• Version and release identification 버전 및 릴리스 식별
• Change history recording 변경 이력 기록
• Support for independent development 독립적인 개발 지원
• Project support 프로젝트 단위 관리 지원
• Storage management 저장소 관리

 

Public repository and private workspaces 공개 저장소와 개인 작업 공간

• To support independent development without interference, version control systems use the concept of a project repository and a private workspace. 충돌 없는 독립 개발을 위해, 버전 관리 시스템은 프로젝트 저장소와 개인 작업 공간의 개념을 사용한다.
• The project repository maintains the ‘master’ version of all components. It is used to create baselines for system building. 프로젝트 저장소는 모든 컴포넌트의 마스터 버전을 저장하며, 시스템 빌드를 위한 베이스라인 생성을 위해 사용된다.
• When modifying components, developers copy (check-out) these from the repository into their workspace and work on these copies. 개발자는 컴포넌트를 저장소에서 복사(check-out)하여 개인 작업 공간에서 수정한다.
• When they have finished their changes, the changed components are returned (checked-in) to the repository. 변경이 완료되면 수정된 컴포넌트를 저장소에 다시 반영(check-in)한다.

 

Centralized version control 중앙집중형 버전 관리

• Developers check out components or directories of components from the project repository into their private workspace and work on these copies in their private workspace. 개발자는 저장소에서 컴포넌트(또는 디렉토리)를 개인 작업 공간으로 복사한 후 작업한다.
• When their changes are complete, they check-in the components back to the repository. 변경이 완료되면 이를 저장소에 반영(check-in)한다.
• If several people are working on a component at the same time, each check it out from the repository. If a component has been checked out, the VC system warns other users wanting to check out that component that it has been checked out by someone else. 동일한 컴포넌트를 여러 사람이 동시에 수정하려고 하면, 시스템은 해당 컴포넌트가 이미 누군가에 의해 체크아웃되었음을 경고한다.

 

Repository Check-in/Check-out 저장소 체크인/체크아웃 

 

Distributed version control 분산형 버전 관리

• A ‘master’ repository is created on a server that maintains the code produced by the development team. 개발팀이 만든 코드를 저장하는 마스터 저장소가 서버에 생성된다.
• Instead of checking out the files that they need, a developer creates a clone of the project repository that is downloaded and installed on their computer. 필요한 파일을 체크아웃하는 대신, 개발자는 전체 저장소를 복제(clone)하여 자신의 컴퓨터에 설치한다.
• Developers work on the files required and maintain the new versions on their private repository on their own computer. 개발자는 필요한 파일을 수정하고, 수정본을 자신의 개인 저장소에 유지한다.
• When changes are done, they ‘commit’ these changes and update their private server repository. They may then ‘push’ these changes to the project repository. 변경이 완료되면, 로컬 저장소에 커밋하고 이후 프로젝트 저장소에 푸시한다.

Repository cloning 저장소 복제 

 

Benefits of distributed version control 분산 버전 관리의 장점

• It provides a backup mechanism for the repository. 저장소의 백업 수단을 제공한다.
  • If the repository is corrupted, work can continue and the project repository can be restored from local copies. 저장소가 손상되더라도, 로컬 복사본에서 복구 가능하며 작업을 계속할 수 있다.
• It allows for off-line working so that developers can commit changes if they do not have a network connection. 네트워크 연결이 없어도 오프라인에서 커밋 작업을 수행할 수 있다.
• Project support is the default way of working. 프로젝트 중심 작업 방식이 기본이다.
  • Developers can compile and test the entire system on their local machines and test the changes that they have made. 개발자는 전체 시스템을 로컬에서 컴파일하고 테스트할 수 있다.

 

Open source development 오픈소스 개발

• Distributed version control is essential for open source development. 분산 버전 관리는 오픈소스 개발에 필수적이다.
  • Several people may be working simultaneously on the same system without any central coordination. 중앙 통제 없이 여러 명이 동시에 같은 시스템을 개발할 수 있다.
• As well as a private repository on their own computer, developers also maintain a public server repository to which they push new versions of components that they have changed. 개발자는 로컬 저장소 외에 변경 사항을 푸시하는 퍼블릭 저장소도 유지한다.
  • It is then up to the open-source system ‘manager’ to decide when to pull these changes into the definitive system. 변경 사항을 공식 시스템에 반영할지는 오픈소스 관리자의 판단에 달려 있다.

 

Branching and merging 브랜치와 병합

• Rather than a linear sequence of versions that reflect changes to the component over time, there may be several independent sequences. 시간이 지남에 따라 선형적으로 변경되는 것 외에도, 서로 독립적인 변경 흐름(브랜치)이 존재할 수 있다.
  • This is normal in system development, where different developers work independently on different versions of the source code and so change it in different ways. 이는 개발자들이 서로 다른 기능을 독립적으로 개발하는 일반적인 상황이다.
• At some stage, it may be necessary to merge codeline branches to create a new version of a component that includes all changes that have been made. 특정 시점에 모든 변경을 통합하여 새로운 버전을 만들기 위해 브랜치를 병합해야 할 수 있다.
  • If the changes made involve different parts of the code, the component versions may be merged automatically by combining the deltas that apply to the code. 서로 다른 부분을 수정한 경우, 델타 정보를 기반으로 자동 병합이 가능하다.

 

Branching and merging 브랜치 및 병합 

 

Storage management 저장소 관리

• When version control systems were first developed, storage management was one of their most important functions. 버전 관리 시스템이 처음 등장했을 때, 저장소 관리는 핵심 기능 중 하나였다.
• Disk space was expensive and it was important to minimize the disk space used by the different copies of components. 디스크 공간이 비쌌기 때문에, 각 버전을 모두 저장하지 않고 공간을 절약하는 것이 중요했다.
• Instead of keeping a complete copy of each version, the system stores a list of differences (deltas) between one version and another. 각 버전 전체를 저장하는 대신, 버전 간 차이(델타)만 저장하였다.
  • By applying these to a master version (usually the most recent version), a target version can be recreated. 이를 마스터 버전에 적용하면 원하는 버전을 재구성할 수 있었다.

 

Storage management using deltas 델타 기반 저장소 관리 

Storage management in Git Git에서의 저장소 관리

• As disk storage is now relatively cheap, Git uses an alternative, faster approach. 디스크 저장 비용이 저렴해진 지금, Git은 더 빠른 다른 방식을 사용한다.
• Git does not use deltas but applies a standard compression algorithm to stored files and their associated meta-information. Git은 델타를 사용하지 않고, 파일과 메타데이터에 압축 알고리즘을 적용한다.
• It does not store duplicate copies of files. Retrieving a file simply involves decompressing it, with no need to apply a chain of operations. 동일한 파일은 중복 저장되지 않으며, 압축 해제를 통해 바로 파일을 불러올 수 있다.
• Git also uses the notion of packfiles where several smaller files are combined into an indexed single file. Git은 여러 파일을 하나의 인덱스된 큰 파일(packfile)로 묶는 방식을 사용한다.

 

 

 

[3] System building 시스템 빌드

System building 시스템 빌드

• System building is the process of creating a complete, executable system by compiling and linking the system components, external libraries, configuration files, etc. 시스템 빌드는 시스템 컴포넌트, 외부 라이브러리, 설정 파일 등을 컴파일하고 연결하여 완전한 실행 가능한 시스템을 만드는 과정이다.
• System building tools and version management tools must communicate as the build process involves checking out component versions from the repository managed by the version management system. 빌드 과정에서 버전 관리 시스템에서 컴포넌트를 체크아웃해야 하므로, 빌드 도구와 버전 관리 도구는 상호 연동되어야 한다.
• The configuration description used to identify a baseline is also used by the system building tool. 베이스라인을 식별하는 데 사용되는 구성 설명은 시스템 빌드 도구에서도 사용된다.

 

System building 시스템 빌드 

 

Build system functionality 빌드 시스템 기능

• Build script generation 빌드 스크립트 생성
• Version management system integration 버전 관리 시스템 통합
• Minimal re-compilation 최소한의 재컴파일
• Executable system creation 실행 가능한 시스템 생성
• Test automation 테스트 자동화
• Reporting 리포트 기능
• Documentation generation 문서 생성

https://github.com/apache/flink/blob/master/pom.xml (예시 링크: 아파치 Flink의 Maven 설정 파일)

 

 

Build platforms 빌드 플랫폼

• The development system, which includes development tools such as compilers, source code editors, etc. 개발 시스템: 컴파일러, 소스코드 편집기 등 개발 도구가 포함된 플랫폼
  • Developers check out code from the version management system into a private workspace before making changes to the system. 개발자는 변경 전 코드를 버전 관리 시스템에서 개인 작업 공간으로 체크아웃한다.
• The build server, which is used to build definitive, executable versions of the system. 빌드 서버: 최종 실행 가능한 시스템을 빌드하기 위한 서버
  • Developers check-in code to the version management system before it is built. The system build may rely on external libraries that are not included in the version management system. 빌드 전에 코드를 버전 관리 시스템에 체크인하며, 빌드는 버전 관리 시스템에 포함되지 않은 외부 라이브러리에 의존할 수 있다.
• The target environment, which is the platform on which the system executes. 타깃 환경: 실제로 시스템이 실행되는 플랫폼
  • For real-time and embedded systems, the target environment is often smaller and simpler than the development environment (e.g. a cell phone) 실시간/임베디드 시스템의 경우, 타깃 환경은 개발 환경보다 작고 단순한 경우가 많다 (예: 휴대전화)

 

Development, build, and target platforms 개발, 빌드, 타깃 플랫폼 

 

Agile building 애자일 빌드

• Check out the mainline system from the version management system into the developer’s private workspace. 메인라인 시스템을 버전 관리 시스템에서 개발자의 개인 작업 공간으로 체크아웃한다.
• Build the system and run automated tests to ensure that the built system passes all tests. If not, the build is broken and you should inform whoever checked in the last baseline system. They are responsible for repairing the problem. 시스템을 빌드하고 자동 테스트를 실행하여 모든 테스트를 통과하는지 확인한다. 실패 시, 마지막 베이스라인을 체크인한 사람에게 알리고, 그들이 문제를 해결해야 한다.
• Make the changes to the system components. 시스템 컴포넌트에 필요한 변경을 수행한다.
• Build the system in the private workspace and rerun system tests. If the tests fail, continue editing. 개인 작업 공간에서 시스템을 빌드하고 테스트를 재실행한다. 실패 시, 계속 수정한다.

 

Agile building 애자일 빌드

• Once the system has passed its tests, check it into the build system but do not commit it as a new system baseline. 테스트를 통과하면 시스템을 빌드 시스템에 체크인하되, 아직 새 베이스라인으로 커밋하지는 않는다.
• Build the system on the build server and run the tests. You need to do this in case others have modified components since you checked out the system. If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace. 빌드 서버에서 시스템을 빌드하고 테스트를 실행한다. 다른 사람이 시스템을 수정했을 수 있으므로 이 확인이 필요하다. 실패한 컴포넌트를 체크아웃하여 개인 작업 공간에서 수정한다.
• If the system passes its tests on the build system, then commit the changes you have made as a new baseline in the system mainline. 빌드 시스템에서 테스트를 통과하면, 해당 변경을 시스템 메인라인의 새로운 베이스라인으로 커밋한다.

 

Continuous integration 지속적 통합 (CI)

 

Pros and cons of continuous integration 지속적 통합의 장단점

• Pros 장점
  • The advantage of continuous integration is that it allows problems caused by the interactions between different developers to be discovered and repaired as soon as possible. CI의 장점은 여러 개발자 간 상호작용에서 발생하는 문제를 빠르게 발견하고 해결할 수 있다는 것이다.
  • The most recent system in the mainline is the definitive working system. 메인라인의 최신 시스템이 기준이 되는 '작동 가능한' 시스템이다.
• Cons 단점
  • If the system is very large, it may take a long time to build and test, especially if integration with other application systems is involved. 시스템이 매우 클 경우, 빌드와 테스트에 많은 시간이 걸릴 수 있다. 특히 다른 애플리케이션과 통합될 경우 그렇다.
  • If the development platform is different from the target platform, it may not be possible to run system tests in the developer’s private workspace. 개발 환경과 타깃 환경이 다를 경우, 개발자의 작업 공간에서 시스템 테스트를 수행하기 어려울 수 있다.

 

Daily building (nightly build) 일일 빌드 (야간 빌드)

• The development organization sets a delivery time (say 2 p.m.) for system components. 개발 조직은 시스템 컴포넌트 제출 마감 시간(예: 오후 2시)을 정한다.
  • If developers have new versions of the components that they are writing, they must deliver them by that time. 개발자는 자신이 작성한 컴포넌트의 새 버전을 마감 시간까지 제출해야 한다.
  • A new version of the system is built from these components by compiling and linking them to form a complete system. 이러한 컴포넌트를 컴파일하고 연결하여 전체 시스템의 새 버전을 빌드한다.
  • This system is then delivered to the testing team, which carries out a set of predefined system tests 해당 시스템은 테스트 팀에 전달되어 사전에 정의된 시스템 테스트를 수행한다.
  • Faults that are discovered during system testing are documented and returned to the system developers. They repair these faults in a subsequent version of the component. 발견된 결함은 문서화되어 개발자에게 전달되며, 이후 버전에서 해당 결함이 수정된다.

 

Minimizing recompilation 재컴파일 최소화

• Tools to support system building are usually designed to minimize the amount of compilation that is required. 시스템 빌드를 지원하는 도구들은 보통 컴파일량을 최소화하도록 설계된다.
• They do this by checking if a compiled version of a component is available. If so, there is no need to recompile that component. 컴포넌트의 컴파일된 버전이 존재하면, 이를 다시 컴파일하지 않는다.
• A unique signature identifies each source and object code version and is changed when the source code is edited. 각 소스 및 오브젝트 코드 버전은 고유한 서명을 가지고 있으며, 소스 코드가 수정되면 서명도 변경된다.
• By comparing the signatures on the source and object code files, it is possible to decide if the source code was used to generate the object code component. 소스 코드와 오브젝트 코드의 서명을 비교함으로써, 해당 오브젝트가 최신 소스를 기반으로 생성되었는지를 판단할 수 있다.

 

File identification 파일 식별 방식

• Modification timestamps 수정 시각 (타임스탬프)
  • The signature on the source code file is the time and date when that file was modified. If the source code file of a component has been modified after the related object code file, then the system assumes that recompilation to create a new object code file is necessary. 소스 코드 파일의 서명은 수정된 시각이다. 소스가 오브젝트보다 나중에 수정되었다면 재컴파일이 필요하다고 판단한다.
• Source code checksums 소스 코드 체크섬
  • The signature on the source code file is a checksum calculated from data in the file. A checksum function calculates a unique number using the source text as input. If you change the source code (even by 1 character), this will generate a different checksum. You can therefore be confident that source code files with different checksums are actually different. 소스 코드의 체크섬은 파일 내용으로부터 계산된 고유 값이다. 단 1자만 수정해도 다른 체크섬이 생성되므로, 체크섬이 다르면 내용이 다르다는 것을 확신할 수 있다.

 

Linking source and object code 소스 및 객체 코드 연결

 

Timestamps vs checksums 타임스탬프 vs 체크섬

• Timestamps 타임스탬프
  • Because source and object files are linked by name rather than an explicit source file signature, it is not usually possible to build different versions of a source code component into the same directory at the same time, as these would generate object files with the same name. 소스와 오브젝트가 이름으로 연결되기 때문에, 동일한 디렉토리에 서로 다른 버전의 오브젝트 파일을 동시에 빌드할 수 없다.
• Checksums 체크섬
  • When you recompile a component, it does not overwrite the object code, as would normally be the case when the timestamp is used. Rather, it generates a new object code file and tags it with the source code signature. Parallel compilation is possible and different versions of a component may be compiled at the same time. 컴포넌트를 리컴파일할 때, 기존 오브젝트를 덮어쓰지 않고 새로운 오브젝트를 생성하고 소스 코드 서명을 태그로 붙인다. 이를 통해 병렬 컴파일이 가능하고, 서로 다른 버전도 동시에 빌드할 수 있다.

 

 

 

[4] Change management 변경 관리

Change management 변경 관리

• Organizational needs and requirements change during the lifetime of a system, bugs have to be repaired and systems have to adapt to changes in their environment. 시스템 수명 동안 조직의 요구와 요구사항은 변경되며, 버그를 수정하고 환경 변화에 적응해야 한다.
• Change management is intended to ensure that system evolution is a managed process and that priority is given to the most urgent and cost-effective changes. 변경 관리는 시스템 진화가 통제된 방식으로 이루어지도록 하며, 긴급하고 비용 효율적인 변경에 우선순위를 두는 것을 목표로 한다.
• The change management process is concerned with (1) analyzing the costs and benefits of proposed changes, (2) approving those changes that are worthwhile and tracking which components in the system have been changed. 변경 관리 프로세스는 (1) 변경 제안의 비용 및 이점 분석, (2) 가치 있는 변경 승인, (3) 변경된 컴포넌트 추적에 초점을 맞춘다.

 

The change management process 변경 관리 절차

• CR: Change request 변경 요청
• CCB: Change control board 변경 관리 위원회

 

A partially completed change request form (a) 변경 요청서 일부 작성 예시 (a)

Change Request Form변경 요청서

Project: SICSA/AppProcessing  Number: 23/02 프로젝트: SICSA/AppProcessing  번호: 23/02

Change requester: I. Sommerville  Date: 20/07/12 요청자: I. Sommerville  날짜: 20/07/12

Requested change: The status of applicants (rejected, accepted, etc.) should be shown visually in the displayed list of applicants. 요청 변경사항: 지원자 리스트에서 상태(불합격, 합격 등)를 시각적으로 표시해야 함.

Change analyzer: R. Looek  Analysis date: 25/07/12 변경 분석자: R. Looek  분석 날짜: 25/07/12

Components affected: ApplicantListDisplay, StatusUpdater 영향받는 컴포넌트: ApplicantListDisplay, StatusUpdater

Associated components: StudentDatabase 관련 컴포넌트: StudentDatabase

A partially completed change request form (b) 변경 요청서 일부 작성 예시 (b)

Change Request Form변경 요청서

Change assessment: Relatively simple to implement by changing the display color according to status. A table must be added to relate status to colors. No changes to associated components are required. 변경 평가: 상태에 따라 표시 색상을 변경하면 비교적 쉽게 구현 가능. 상태-색상 매핑 테이블 추가 필요. 관련 컴포넌트는 변경 불필요.

Change priority: Medium 변경 우선순위: 중간

Change implementation:변경 구현: (미작성)

Estimated effort: 2 hours 예상 소요 시간: 2시간

Date to SGA app. team: 28/07/12 CCB decision date: 30/07/12 SGA 앱 팀 전달일: 28/07/12 CCB 결정일:30/07/12

Decision: Accept change. Change to be implemented in Release 1.2 결정: 변경 승인. 릴리스 1.2에 반영 예정.

Change implementor:  Date of change:변경 담당자:  변경 일자: (미작성)

Date submitted to QA: QA decision:QA 전달일: QA 결정: (미작성)

Date submitted to CM:CM 전달일: (미작성)

Comments:비고: (미작성)

 

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 제품 릴리스 주기

 

Derivation history (in the source code) 소스 코드 내 파생 이력

// SICSA project (XEP 6087)
//
// APP-SYSTEM/AUTH/RBAC/USER_ROLE
//
// Object: currentRole
// Author: R. Looek
// Creation date: 13/11/2012
//
// © St Andrews University 2012
//
// Modification history
// Version  Modifier   Date        Change          Reason
// 1.0      J. Jones   11/11/2009  Add header      Submitted to CM
// 1.1      R. Looek   13/11/2012  New field       Change req. R07/02

 

Change management and agile methods/OSS 애자일 방법 및 오픈소스 개발에서의 변경 관리

• In some agile methods, customers are directly involved in change management. 일부 애자일 방법에서는 고객이 변경 관리에 직접 참여한다.
• They propose a change to the requirements and work with the team to assess its impact and decide whether the change should take priority over the features planned for the next increment of the system. 고객은 요구사항 변경을 제안하고, 팀과 함께 영향도를 평가하며 다음 이터레이션의 기능보다 우선순위가 높은지를 판단한다.
• Changes to improve the software are decided by the programmers working on the system. 소프트웨어 개선을 위한 변경은 시스템 개발자가 자체적으로 결정한다.
• Refactoring, where the software is continually improved, is not seen as an overhead but as a necessary part of the development process. 지속적인 개선을 위한 리팩토링은 추가 비용이 아닌 필수 개발 과정으로 간주된다.

 

 

 

[5] Release management 릴리스 관리

Release management 릴리스 관리

• A system release is a version of a software system that is distributed to customers. 시스템 릴리스는 고객에게 배포되는 소프트웨어 시스템의 특정 버전이다.
• For mass market software, it is usually possible to identify two types of release: major releases which deliver significant new functionality, and minor releases, which repair bugs and fix customer problems that have been reported. 대중 시장 소프트웨어의 경우, 새로운 기능을 포함하는 주요 릴리스와 버그 수정 등 문제 해결 중심의 소규모 릴리스로 구분된다.
• For custom software or software product lines, releases of the system may have to be produced for each customer and individual customers may be running several different releases of the system at the same time. 맞춤형 소프트웨어나 제품군의 경우, 고객마다 별도 릴리스를 제공해야 하며, 고객이 동시에 여러 릴리스를 사용할 수도 있다.

 

Release components 릴리스 구성 요소

• As well as the executable code of the system, a release may also include: 릴리스에는 실행 파일 외에도 다음이 포함될 수 있다:
  • configuration files defining how the release should be configured for particular installations; 특정 환경에 맞는 설정 정보를 담은 구성 파일
  • data files, such as files of error messages, that are needed for successful system operation; 에러 메시지 등 시스템 실행에 필요한 데이터 파일
  • an installation program that is used to help install the system on target hardware; 타깃 하드웨어에 설치를 돕는 설치 프로그램
  • electronic and paper documentation describing the system; 시스템 설명을 위한 전자/인쇄 문서
  • packaging and associated publicity that have been designed for that release. 릴리스 전용으로 제작된 포장물 및 마케팅 자료

 

Factors influencing system release planning 시스템 릴리스 계획에 영향을 주는 요소

Factor	Description
Competition	For mass-market software, a new system release may be necessary because a competing product has introduced new features and market share may be lost if these are not provided to existing customers.	경쟁 제품이 새로운 기능을 출시하면 시장 점유율을 잃지 않기 위해 새로운 릴리스가 필요할 수 있다.
Marketing requirements	The marketing department of an organization may have made a commitment for releases to be available at a particular date.	마케팅 부서가 특정 날짜에 릴리스를 출시하겠다고 약속한 경우, 릴리스 일정을 맞춰야 한다.
Platform changes	You may have to create a new release of a software application when a new version of the operating system platform is released.	운영체제의 새 버전 출시로 인해 소프트웨어 릴리스를 새로 제작해야 할 수 있다.
Technical quality of the system	If serious system faults are reported which affect the way in which many customers use the system, it may be necessary to issue a fault repair release. Minor system faults may be repaired by issuing patches (usually distributed over the Internet) that can be applied to the current release of the system.	시스템 결함이 많은 고객에게 영향을 미치는 경우, 결함 수정을 위한 릴리스를 제공해야 할 수 있다. 소규모 오류는 패치 형식으로 인터넷을 통해 배포된다.

 

Software as a service 서비스형 소프트웨어 (SaaS)

• Delivering software as a service (SaaS) reduces the problems of release management. SaaS 방식은 릴리스 관리 문제를 줄여준다.
• It simplifies both release management and system installation for customers. 고객 입장에서는 릴리스 관리와 시스템 설치가 단순해진다.
• The software developer is responsible for replacing the existing release of a system with a new release and this is made available to all customers at the same time. 개발자가 기존 릴리스를 새로운 릴리스로 대체하며, 모든 고객에게 동시에 제공된다.
• Examples: Google Apps, Dropbox, ... 예: Google Apps, Dropbox 등

 

Key points 핵심 요점

• Configuration management is the management of an evolving software system. When maintaining a system, a CM team is put in place to ensure that changes are incorporated into the system in a controlled way and that records are maintained with details of the changes that have been implemented. 구성 관리는 변화하는 소프트웨어 시스템을 관리하는 것이다. 유지보수 시, CM 팀이 구성되어 변경 사항을 통제하고 이력을 기록한다.
• The main configuration management processes are concerned with version management, system building, change management, and release management. 주요 구성 관리 프로세스에는 버전 관리, 시스템 빌드, 변경 관리, 릴리스 관리가 포함된다.
• Version management involves keeping track of the different versions of software components as changes are made to them. 버전 관리는 소프트웨어 컴포넌트의 변경 내역을 추적하는 작업이다.
• System building is the process of assembling system components into an executable program to run on a target computer system. 시스템 빌드는 컴포넌트를 결합하여 타깃 시스템에서 실행 가능한 프로그램을 만드는 과정이다.
• Software should be frequently rebuilt and tested immediately after a new version has been built. This makes it easier to detect bugs and problems that have been introduced since the last build. 소프트웨어는 자주 빌드하고 바로 테스트해야 하며, 이는 최근 빌드 이후 발생한 문제를 조기에 발견하는 데 도움이 된다.
• Change management involves assessing proposals for changes from system customers and other stakeholders and deciding if it is cost-effective to implement these in a new version of a system. 변경 관리는 고객 및 이해관계자의 변경 제안을 평가하고, 새 버전에 반영할 가치가 있는지를 판단하는 과정이다.
• System releases include executable code, data files, configuration files and documentation. Release management involves making decisions on system release dates, preparing all information for distribution and documenting each system release. 시스템 릴리스에는 실행 파일, 데이터 파일, 구성 파일, 문서가 포함되며, 릴리스 관리는 출시 일정 결정, 배포 자료 준비, 릴리스 문서화 등을 포함한다.