3. The Goal of Today's Presentation
● 형상관리 6 Core Concepts 이해
● 자동화의 중요성 이해
"컴퓨터가 더 잘 하는 건 컴퓨터에
게 맡겨야 한다."
4. (Traditional) 형상 관리 주요 활동
형상 식별
형상관리 대상이 되는 작업산출물을 선정
형상 항목
- 소스코드, 바이너리, 문서, 설정 파일 등
변경 관리
S/W 생명 주기 내에서의 변경 관리
형상 상태 기록 효과적인 S/W 형상 관리를 위한 기록 및 보고
형상감사
형상항목의 무결성을 유지되어 있는지 감사를 통해
확인하고 이슈를 찾아내는 것
unclear definition
status accounting?
how to implement?
5. Six Core CM Practices
Familiar to developers
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
6. 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)
7. 소프트웨어 개발은 복잡할지 몰라도, 소프트웨어의 전달
은 버튼 하나만 누르면 되는 일이 되어야 합니다.
지속적인 통합, P.13
8. 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
9. 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
16. 머지 방법
● 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
21. 소스코드 Conflict
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
소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.
소스코드관리시스에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge 해 준다. 하지만 개발자들
이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 자동으로 사용자가 직접 Merge
를 해야 하고 이 때 이용하는 것이 Merge Tool이다.
많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당
자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코관리시스템을 잘못 사용하고 있는 예가 된다. 이
런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.
3-way 머지 툴을 이용하면 쉽게 Merge할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 좋다.
같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게또는 일어나지 않게 소스코드를 작성할 수 있다.
근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄
일 수 있다.
변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또
한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.
소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.
그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.
Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하
게 할 수 있어야 한다.
23. 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
24. Version IDs or Branding Executables
● 빌드 프로세스에서 생성된 산출물의 버전이
식별되어야 함
● About Box in GUI
● Documentation, release notes, tutorials
include version identification of source
code
26. Immutable Version IDS
● 실행파일에 버전을 삽입
● 실행파일로부터 버전을 알아낼 수 있는 방법
이 있어야 함
● 실행파일의 버전으로부터 해당 소스코드의
버전을 쉽게 추적 가능해야 함
27. 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-SubversionRevision-Numbers-in-your-Visual-Stu
28. Managing Compile Dependencies
● 빌드 스크립트에 필요한 환경변수를 모두 포
함
● 빌드 스크립트 실행 시 dependencies (환경
변수 등)이 올바르게 세팅되었는지를 검사
● 예) 빌드 스크립트 - 환경변수 체크
○ 빌드 스크립트 실행 시 에러 발생
■ please add "set MT8205_C51PATH=" in autoexec.
bat
29. The Independent Build
● 릴리스 버전 만들 때 full build 사용
○ 실수 방지를 위해
● 개발자가 아닌 별도의 팀 또는 CI
(Continuous Integration)에서 릴리스 버전 생
성
● Many regulatory frameworks require
separation of duties
30. 지속적인 통합, 폴 M. 듀발, 스티븐 M. 마티야스, 앤
드류 글로버, P.84
마법의 컴퓨터
● 아주 특이한 마법의 하드웨어로 구성되어 있
어서 회사의 소프트웨어 애플리케이션을 빌
드할 수 있는 유일한 컴퓨터
● 빌드를 하고 있는 머신을 직접 의존할 때 발
생
○ 개발자 머신의 절대 경로 사용
○ 개발자 머신에만 설치된 라이브러리 사용
31. 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
32. 빌드 스크립트 개선 "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
33. 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
34. Build Engineer
필요한 기술
● S/W 개발 백그라운드
● Perl, Python, shell script, xml
● application architecture/technologies
○ C#, .NET, J2EE SOA
● build tools
개발자와의 협력
35. 3. Environment Configuration
● Identifying, modifying, and managing the interface
dependencies required for the system
● IT organization에 주로 필요함
●
○ 네트웍, Database 등
제품 개발 조직에는 less focus: 모든 소프트웨어가 제품
에 포함되기 때문에
36. 왜 필요한가?
● Common Mistakes
○ 테스트 할 때 production database 가 사용
된다.
○ 개발에서는 포트가 모두 open 되어 있으나
production에서는 그렇지 않다.
○ port 가 갑자기 close 된다.
○ Test가 목적이었는데 실수로 real
transaction 이 실행된다.
37. 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
38. 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.
39. 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 에서도 마찬가지
40. How To
● Establish procedure to drop and re-create a
test environment from scratch
○ database 초기화
● virtualization, virtual machine, SaaS, cloud
computing
○ 특히, large environment가 잠시 필요할 때
41. 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
○ 사안에 맞게 적절한 프로세스를 구축해야 함
42. 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
43. 5. Release Management
● Release Management
○ Packing
○ 빌드가 완료된 후 실제 제품에 탑재를 준비하는 과정
(실제 탑재는 Deployment)
● 소스코드 관리, build engineering 을 포함하
는 의미로 사용되기도 한다.
44. Goal of Release Management
● To create and maintain a repeatable
process for packing a release
● To identify and verify every component of
the release
45. 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
46. 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
47. How To
● Release 자체에 version ID가 embed 되어야
함
○ 문서에 record 만으로는 부족함 (변경 가능성)
○ Release package로부터 embedded and immutable
version ID를 retrieve 할 수 있는 방법이 제공되어야
함
● production 환경에서 package가 올바른 버전
인지를 알 수 있어야 함
○ production 환경에서 unexpected change를 발견
48. Release Map
● 프로그램 외에
○ developer release notes
○ product documentation
○ what is included in the release
● list = releases map (bill of materials)
49. Immutable ID
● cannot be overwritten
● embed ID into binary executable at build
time
● release package and all CI contain version
ID.
50. How To
● Avoiding human error
○ 자동화 되지 않으면 항상 에러 가능성이 있다.
● 기술 습득
○ WAR, EAR, JAR
○ Ant, Maven, Make
51. How To
● Communicate the status of release
○ 릴리스에 대한 visibility를 제공해야 한다.
○ boradcast
● Configuration Control
○ new release 가 필요한 경우가 파악되어야 함
52. 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
53. 6. Deployment
● package release를 target environment에 설
치
● rollback
● Operation team으로 이관됨
○ should be easy
● Deployment should be a "nonevent".
54. 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
55. 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
56. How To
● 대부분 필요한 작업을 build, release 에서 한
다.
● Release is preconfigured for production and
copied to a specific location (depot) on
each machine.
58. Everything is scripted
● can exactly what I did at every steps of the
process
● 에러/실수를 찾아내기 위해서는 그 과정이
반드시 기록되어 있어야 한다.
● 실수를 두 번 반복하지 않는다
59. 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
60. 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 missioncritical IT environment should be controlled and
managed by the operations team
61. 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
62. 지속적인 배포
● 작동하는 소프트웨어를 언제 어느 곳에서든
릴리즈 하기
● 저장소 안의 자산에 꼬리표 붙이기 (tagging)
● 깨끗한 환경 만들기
● 각 빌드에 꼬리표 붙이기 (바이너리 버전)
● 테스트를 모두 돌리기
● 빌드 피드백 보고서 만들기
● 릴리즈를 롤백할 수 있는 능력 확보하기
63. Conclusion
1. Source Code Management
자동화
2. Build Engineering
3. Environment Configuration
4. Change Control
5. Release Engineering
6. Deployment
Human 실
수 방지
