Configuration Management

신현일

관련 자료

The Goal of Today's Presentation

● 형상관리 6 Core Concepts 이해

● 자동화의 중요성 이해

"컴퓨터가 더 잘 하는 건 컴퓨터에게 맡겨야 한다."

(Traditional) 형상 관리 주요 활동

형상 식별 형상관리 대상이 되는 작업산출물을 선정

형상 항목- 소스코드, 바이너리, 문서, 설정 파일 등

변경 관리 S/W 생명 주기 내에서의 변경 관리

형상 상태 기록 효과적인 S/W 형상 관리를 위한 기록 및 보고

형상감사 형상항목의 무결성을 유지되어 있는지 감사를 통해 확인하고 이슈를 찾아내는 것

unclear definitionstatus accounting?how to implement?

Six Core CM Practices

Core CM Practices Making a cake

1 Source Code Management all the correct ingredients on hand

2 Build Engineering mixing batter and baking the cake itself

3 Environment Configuration the shelf ready to show off the great cake

4 Change Control decide when the cake is baked and ready to be taken from the oven and sent to the happy person who will enjoy the cake

5 Release Engineering putting the cake into the nice box

6 Deployment putting the cake on the truck to be delivered to consumers

Familiar to developers

How to Implement

Configuration Identification

by naming the components, streams, and subdirectories (folders) in source code management tool

Build engineering- embed version IDs in binary configuration items- build tools, like Maven, help organize source code in a logical and sensible way

Release management- name release package in a clear and consistent way

Status Accouting

tracking the status of a configuration item throughout its lifecycle

source code management tools are integrated with requirements and defect tracking system==> can trace the evolution of a component from its requirement to its deployment

Configuration Audit

know exactly which version of the code is running in production (or QA)

소프트웨어 개발은 복잡할지 몰라도, 소프트웨어의 전달은 버튼 하나만 누르면 되는 일이 되어야 합니다.

지속적인 통합, P.13

1. Source Code Management

● Goal○ source code can never be lost.○ complete traceability (who changed)

● Principles○ code is baselined, marking a specific milestone○ managing variants should be easy○ merge○ tracking of all changes

Baseline and Time Machine

● virtual time machine○ back to a specific point in time

● Baseline (tag, snapshot)○ 코드가 안정된 시점에서 코드들의 버전○ immutable (should be locked)○ special tag (PRODUCTION): the current release

Reserved Versus Unreserved Checkouts

● Reserved○ 체크아웃 된 파일을 lock

● Unsereved○ no lock○ merge 필요

● 어떤 도구들은 누가 수정하고 있는지에 대한 정보를 제공함

Sandboxes (Workspaces)

● 개인적인 공간, check in 가능● Subversion

○ branching 이용

Variant Management (Branching)

● Branch가 필요한 이유○ 특정 환경(Windows, Linux, Mac 등)에 맞는 코드○ release 된 버전에 대한 bugfix○ 개인 공간 사용

Copybranches Versus Deltas

● Copybranch○ duplicate copy of every piece

● sub-branch ○ 변경된 파일(deltas)만 관리○ Subversion: Cheap Copies

How to Handle Bugfixes

Merging

머지 방법

● 2 way merge○ 두 개의 파일을 서로 비교하면서 하나로 합치는 방법: branch, trunk-2

○ 100% 수동

● 3 way merge○ 3 개의 파일: trunk-1,

branch, trunk-2

○ 파일의 충돌만 없다면 자동으로도 merge 가능

추가 자료- http://blog.naver.com/PostView.nhn?blogId=manaslu85&logNo=122326912- http://allofsoftware.net/entry/Merge-Tool%EB%A8%B8%EC%A7%80%ED%88%B4-%EB%B9%84%EA%B5%90

2 Way Merge

3 Way Megre

SVN Merge

KDiff3 - Conflict 처리 SVN과 연동됨

소스코드 Conflict소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge 해 준다. 하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 자동으로 사용자가 직접 Merge를 해야 하고 이 때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코관리시스템을 잘못 사용하고 있는 예가 된다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

3-way 머지 툴을 이용하면 쉽게 Merge할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

http://allofsoftware.net/entry/%EB%88%84%EA%B0%80-%EB%82%B4-%EC%86%8C%EC%8A%A4%EC%BD%94%EB%93%9C%EB%A5%BC-%EB%82%A0%EB%A0%A4-%EB%B2%84%EB%A0%B8%EB%82%98

소스코드관리 Tools

● Subversion● CVS● Git (최근 인기를 얻고 있음)

2. Build Engineering

● 소스코드로부터 바이너리(실행파일)을 생성

● Goal○ compile/link source code into a binary executable

in the shortest possible time.

● Principles○ understood and repeatable○ fast and reliable○ every CI is identifiable○ the cause of broken builds is quickly and easily

identified

Version IDs or Branding Executables

● 빌드 프로세스에서 생성된 산출물의 버전이 식별되어야 함

● About Box in GUI

● Documentation, release notes, tutorials include version identification of source code

TortoiseSVN About

Immutable Version IDS

● 실행파일에 버전을 삽입

● 실행파일로부터 버전을 알아낼 수 있는 방법이 있어야 함

● 실행파일의 버전으로부터 해당 소스코드의 버전을 쉽게 추적 가능해야 함

Stamping in a Version Label or Tag

● 실행파일에 소스코드관리 도구에 저장된 label 또는 Revision을 삽입

Use Subversion Revision Numbers in your Visual Studio Projects

http://www.codeproject.com/Articles/27874/Use-Subversion-Revision-Numbers-in-your-Visual-Stu

Managing Compile Dependencies

● 빌드 스크립트에 필요한 환경변수를 모두 포함

● 빌드 스크립트 실행 시 dependencies (환경변수 등)이 올바르게 세팅되었는지를 검사

● 예) 빌드 스크립트 - 환경변수 체크○ 빌드 스크립트 실행 시 에러 발생

■ please add "set MT8205_C51PATH=" in autoexec.bat

The Independent Build

● 릴리스 버전 만들 때 full build 사용○ 실수 방지를 위해

● 개발자가 아닌 별도의 팀 또는 CI (Continuous Integration)에서 릴리스 버전 생성

● Many regulatory frameworks require separation of duties

마법의 컴퓨터

● 아주 특이한 마법의 하드웨어로 구성되어 있어서 회사의 소프트웨어 애플리케이션을 빌드할 수 있는 유일한 컴퓨터

● 빌드를 하고 있는 머신을 직접 의존할 때 발생○ 개발자 머신의 절대 경로 사용○ 개발자 머신에만 설치된 라이브러리 사용

지속적인 통합, 폴 M. 듀발, 스티븐 M. 마티야스, 앤드류 글로버, P.84

Build Tools

● GNU make for C/C++● Ant, Maven for Java

○ Maven: focuses on convention over configuration● MS Build for .NET (e.g., C#)

● Applications should never be built and deployed to production (or QA) from within an IDE (Integrated Development Environment).○ not repeatable○ Handled implicitly by IDE ==> make build process

difficult to understand

빌드 스크립트 개선 - "Bob-Proofing" Your Build

1. Test-Driven Builds● 빌드 스크립트에 빌드에 필요한 정보가 올바른지를 검사하는 코드가 필요

● early notification if the build broken

2. Trust, But Verify● 빌드 결과물이 올바른지 테스트

3. The Cockpit of a Plane● the cockpit of a plane: 실수 가능성이 최소화된 plane● prevent mistakes and proactively detect problems

The Cockpit of a Plane - Tips

● Design the build so that each step is easy to understand and follow

● Anticipate what might go wrong

● Build in tests to verify that the build is successful

● Use dashboards and reports to communicate build status

Build Engineer

필요한 기술● S/W 개발 백그라운드● Perl, Python, shell script, xml● application architecture/technologies

○ C#, .NET, J2EE SOA● build tools

개발자와의 협력

3. Environment Configuration

● Identifying, modifying, and managing the interface dependencies required for the system

● IT organization에 주로 필요함○ 네트웍, Database 등

● 제품 개발 조직에는 less focus: 모든 소프트웨어가 제품에 포함되기 때문에

왜 필요한가?

● Common Mistakes○ 테스트 할 때 production database 가 사용된다.

○ 개발에서는 포트가 모두 open 되어 있으나 production에서는 그렇지 않다.

○ port 가 갑자기 close 된다.○ Test가 목적이었는데 실수로 real

transaction 이 실행된다.

Goal of Environment Configuration Control

● always to point to the correct runtime resources○ 예, To get QA database for testing and keep the

production database safe and secure● interface change 관리● 개발에서 QA, production 까지 개발된 시스템이 잘 전달될 수 있도록 관리

● 적절한 테스트 환경 제공○ multiple environments를 다룰 수 있는 flexibility

==> rapid deployment and test

Principles of Environment Configuration

● Environment configuration dependencies are identified and well understood.

● Environments can be interrogated for their current status (for example, ports open).

● Code should be built once with environment configuration changed prior to deployment.

● Environment configuration should be changed in a controlled and predictable way.

● Environment configurations should be documented and understood by all parties.

How To

● Eliminate hard coding of all dependencies as soon as possible

● Centralize the information in one centralized repository○ CMDB (Configuration Management Database): 모든 환경 정보를 관리하는 DB

○ build process 중 CMDB를 참조하여 실제 값을 알아내서 subsitution 수행

○ release packaing 에서도 마찬가지

How To

● Establish procedure to drop and re-create a test environment from scratch○ database 초기화

● virtualization, virtual machine, SaaS, cloud computing○ 특히, large environment가 잠시 필요할 때

4. Change Control

● Goals○ manage all changes to the production environments○ control which releases are promoted to QA and

production

● extremely detailed process <-> light process○ 사안에 맞게 적절한 프로세스를 구축해야 함

Seven Types of Change Control

● Priori○ 코드 변경 여부를 결정

● Gatekeeping○ 출시 여부 결정, patch

● Configuration Control○ environment configuration 변경

● Change Advisory Board● Emergency Change Control

○ Immediate change 처리● Process Engineering● Senior Management Oversight

5. Release Management

● Release Management○ Packing ○ 빌드가 완료된 후 실제 제품에 탑재를 준비하는 과정

(실제 탑재는 Deployment)

● 소스코드 관리, build engineering 을 포함하는 의미로 사용되기도 한다.

Goal of Release Management

● To create and maintain a repeatable process for packing a release

● To identify and verify every component of the release

Principles

● Release should be readily identifiable with and immutable version ID.

● Release should be packaged with all the dependencies included.

● Release packaging should be automated and designed to avoid human error.

● Release management should be fast and reliable to facilitate iterative development.

● There should be a mechanism to conduct an audit of a release package to verify all of its configuration items.

● release management dashboard

How To

● Create a reliable way to identify all configuration items○ can be traced back to the source code○ 소스코드 뿐만 아니라 binary, 문서 등도 포함○ 모든 CI에 대해 version ID 부여가 어려우므로 risk 분석을 통해 중요한 것들부터 관리

● Automate packaging

How To

● Release 자체에 version ID가 embed 되어야 함○ 문서에 record 만으로는 부족함 (변경 가능성)○ Release package로부터 embedded and immutable

version ID를 retrieve 할 수 있는 방법이 제공되어야 함

● production 환경에서 package가 올바른 버전인지를 알 수 있어야 함○ production 환경에서 unexpected change를 발견

Release Map

● 프로그램 외에○ developer release notes○ product documentation○ what is included in the release

● list = releases map (bill of materials)

Immutable ID

● cannot be overwritten

● embed ID into binary executable at build time

● release package and all CI contain version ID.

How To

● Avoiding human error○ 자동화 되지 않으면 항상 에러 가능성이 있다.

● 기술 습득○ WAR, EAR, JAR○ Ant, Maven, Make

How To

● Communicate the status of release○ 릴리스에 대한 visibility를 제공해야 한다.○ boradcast

● Configuration Control○ new release 가 필요한 경우가 파악되어야 함

Advanced

● Using cryptography to sign your code○ to verify the integrity of a downloaded package or

patch to the software○ A utility is provided for verification to users

● OS Support 이용○ Linux RPM, YUM utilities to update patches

6. Deployment

● package release를 target environment에 설치

● rollback

● Operation team으로 이관됨○ should be easy

● Deployment should be a "nonevent".

Goals of Deployment

● Promote a release into production without any possible problem occurring

● deployment 도중 문제가 발생하면 쉽게 rollback 될 수 있어야 함

● Can know what is in production, and immediately whether any unauthorized changes have been made

Principles of Deployment

● reliable and as simple as possible● traceable with an audit log of all changes● only authorized personnel should be involved● a separation of duties between developers and team

that deploys the release● any unauthorized changes should be detected

immediately● checking versions of a release in production

How To

● 대부분 필요한 작업을 build, release 에서 한다.

● Release is preconfigured for production and copied to a specific location (depot) on each machine.

(preconfigured )Example in Unix - softlink

Everything is scripted

● can exactly what I did at every steps of the process

● 에러/실수를 찾아내기 위해서는 그 과정이 반드시 기록되어 있어야 한다.

● 실수를 두 번 반복하지 않는다

How To

● Auditing Release○ can verify that CIs in production are exactly the

correct versions that should be there

● Don't Forget the Smoke Test○ Execute at least one transaction to verify that the

release was successfully completed○ Confirm that the expected changes were

successfully deployed

How To

● Communications Planning○ Announcement on when the release is going to be

promoted○ Include the results of the smoke test, the location

of the release notes

● Deployment Should Be Delegated○ Operations team can deploy and fall back as

necessary○ The actual deployment to production in a mission-

critical IT environment should be controlled and managed by the operations team

Trust But Verify

● Continuously verify that ○ the production (or QA) environments have the

correct baselines deployed ○ all interface controls are established correctly.

● Verify that no changes have taken place

지속적인 배포

● 작동하는 소프트웨어를 언제 어느 곳에서든 릴리즈 하기

● 저장소 안의 자산에 꼬리표 붙이기 (tagging)● 깨끗한 환경 만들기● 각 빌드에 꼬리표 붙이기 (바이너리 버전)● 테스트를 모두 돌리기● 빌드 피드백 보고서 만들기● 릴리즈를 롤백할 수 있는 능력 확보하기

Conclusion

1. Source Code Management

2. Build Engineering

3. Environment Configuration

4. Change Control

5. Release Engineering

6. Deployment

자동화

Human 실수 방지

END