1. Going alone
예제는 한 사람으로 이뤄진 팀으로 부터 시작합니다. Markus는 JUnit라는 테스팅 프레임웍를 개발하고 있습니다. 그는 이클립스 작업공간에 두 개의 프로젝트를 갖고 있습니다. 첫번째는JUnit 프로젝트(core library와 utilities)이고, 두번째는 JUnit Examples 프로젝트(examples들)입니다. Markus는 지금 자신의 작업을 Jazz에 저장하기 위해서 스트림이 필요하진 않습니다.저장소에 작업을 백업하고 변경를 추적하기 위해서 Markus가 필요한 모든 것은 저장소 작업공간입니다.
스트림없이 저장소 작업공간을 사용
- 패키지 탐색기에서 JUnit, JUnit Examples 프로젝트를 공유합니다 : 팀 > 프로젝트 공유...
- 공유 마법사 첫번째 페이지에서, Jazz Source Control를 선택하고 다음을 누릅니다.
- 두번째 페이지에서, 이름 지정된 새 저장소 작업공간 작성을 선택하고 이름을 입력합니다. 곧바로 완료를 눌러서 다음 단계들을 건너 뜁니다. 저장소 작업공간 하나와 콤포넌트 하나가 생성됩니다.
변경사항을 플로우하지 않는 저장소 작업공간
Markus는 로컬 이클립스 작업공간에서 파일을 변경해서, 보류 중인 변경사항 보기에 해결되지 않은 변경사항을 만듭니다. 버전들을 서버에 저장할려고 할 때, 보류 중인 변경사항을 프로젝트 공유 변경 세트에 체크인할 수 있습니다. 한 묶음의 변경 작업들을 완료한 후에는 보류 중인 변경사항 보기에서 해당 변경 세트를 완료할 수 있습니다 ? 완료 후에는 새로운 변경 사항들은 새로운 변경 세트에 추가됩니다. 저장소 작업공간에 쌓이는 변경 세트들은 여타 SCM 시스템에서 체크인할 때와 매우 유사합니다만, 째즈에서는 변경세트에 무엇을 담을지 제어할 수 있습니다. 저장소 작업공간에 축적된 완료된 변경 세트들은 히스토리 보기와 변경 탐색기를 통해 변경 내역들을 탐색할 수 있습니다.
1.1 Baselines
개발을 어느 정도 진행한 다음, 이에 만족한 Markus는 변경 작업의 현 상태를 베이스라인으로 기억해 놓으려고 합니다. 저장소 작업공간 상에서 베이스라인 작성이 가능합니다. 보류 중인 변경 사항 보기에서 콤포넌트를 선택하고, 새로 작성 > 기준선...을 실행합니다. 저장소 작업공간이나 스트림에 있는 컴포넌트는 항상 현재 기준선이 있어서, 해당 저장소 작업공간이나 스트림에 있는 컴포넌트의 최신 베이스라인을 알 수 있습니다.
베이스라인 히스토리 보기
1.2 Going back
작업을 하다보면, 빌드를 재현하거나 이전의 좋은 상태로 되돌아 갈 수 있으면 유용합니다. 예전으로 돌아가기전에 저장소 작업공간에서 스트림으로 전달하지 않은 것들이 어떤 것들이 있는 지 먼저 고려해야 합니다. 당장 필요하지 않는 몇개의 변경 세트를 가지고 있다면, 보류 중인 변경사항 보기나 히스토리 보기에서 해당 변경 세트를 일시중단할 수 있습니다. 변경 작업이 많았다면, BROKEN 베이스라인을 만들고 나서 보류 중인 변경사항 보기에서 콤포넌트 JUnit를 선택하고 바꿀 대상 > 기준선...을 통해서 GOOD 베이스라인으로 변경합니다.
베이스라인 작성 때의 파일이나 폴더를 탐색하는 것도 가능합니다. 히스토리 보기에서, 베이스라인을 선택하고, 저장소 파일 표시를 실행합니다. 저장소 파일 탐색기가 열리면, 베이스라인에 있는 파일의 상태를 탐색할 수 있습니다. 특정 파일의 상태를 알아 보고 싶다면, 해당 파일을 선택하고 로드를 통해 로컬 이클립스 작업공간으로 파일 내용을 가져옵니다.
베이스라인에 있는 파일 탐색
2. Growing Up
단독으로 작업하는 내용을 봤습니다만, Jazz는 모두 팀에 관한 것으로 JUnit 팀을 확장해 보도록 합니다. Markus는 JUnit Examples 프로젝트(example들)을 개선하기 위해 Jason 투입합니다. 그리고 example들은 주 애플리케이션과 제공하지 않기로 결정하고, example들에 작업할 팀이 독립적으로 작업하도록 돕기위해 example들을 별도의 콤포넌트로 분리합니다. 결과적으로, Markus는 플로우 구조를 아래와 같이 변경합니다.
스트림 추가
새로운 구조를 만들기 위해 가장 먼저 할 일은 새로운 콤포넌트를 만들고, 여기로 JUnit Examples 프로젝트를 옮기는 것입니다. 새로운 컴포넌트는 저장소 작업공간 편집기에서 이뤄집니다. 보류 중인 변경사항 보기에서 저장소 작업공간을 선택하고 열기를 실행합니다. 편집기가 열리면, 콤포넌트 섹션에서 새로 작성...을 클릭하고 새 콤포넌트 이름 Examples을 입력하고 편집기 우측 상단의 저장 버튼을 누릅니다.
Junit Examples 프로젝트를 Examples 콤포넌트로 옮기기 위해서는, JUnit Examples 프로젝트를 선택하고 팀 > 저장소에서 이동...을 실행합니다.
다음에는 스트림 구조를 작성합니다. 간단히 저장소 작업공간으로 부터 스트림을 작성할 수 있습니다 ? 팀 아티팩트 탐색기에서 저장소 작업공간을 선택하고 새로 작성 > 스트림...을 실행합니다.
2.1 The First Customer
외부 고객과 코드를 공유해야 할 때가 되면, Markus나 Jason은 스냅샷을 통해 고객에게 전달된 상태를 기록해 둘 수 있습니다. 스냅샷을 작성할 때는, 보류 중인 변경사항 보기에서 저장소 작업공간을 선택하고 새로 작성 > 스냅샷...을 실행하여 JUnit 0.1를 만듭니다.
고객으로 부터 몇가지 버그 수정을 요청받을 땐, 간단히 또 하나의 스트림을 버그 수정 추적용으로 만들어서 동시에 양쪽 스트림에서 작업할 수 있습니다. 핵심 포인트는 보류 중인 변경사항 보기에서 플로우 대상 변경...을 실행해서 플로우 대상을 원하는 스트림 또는 저장소 작업공간으로 바꾼 후, 바뀐 대상과 변경사항을 주거나 받을 수 있다는 겁니다. 동일 작업공간상에서 모든 플로우를 진행할 수 있기에 병렬 개발이 매우 간편합니다.
버그 수정 스트림
2.2 Automated Builds
이젠 고객에게 바이너리를 패키징해서 전달해야 하는 데, 이를 자동화된 빌드를 활용해서 패키징하거나 단위 테스트 등을 하는 것이 좋습니다. 빌드를 수행하기 위해, 간단히 빌드용 저장소 작업공간을 작성합니다. 그리곤 스트림으로 부터 빌드용 저장소 작업공간으로 변경사항 수신하도록 플로우를 구성합니다.
빌드용 저장소 작업공간 추가
째즈에 맞게 구성할 수 있는 전형적인 Ant 스크립트 샘플입니다. 빌드를 수행할 땐, 먼저 마지막 빌드 이후 작성된 모든 변경 세트를 수신하고 빌드용 저장소 작업공간에 대해 스냅샷을 생성합니다:
<teamAccept repositoryAddress="${repositoryAddress}"
userId="${userId}"
password="${password}"
workspaceName="JUnit Build"
buildResultUUID="${buildResultUUID}"
snapshotName="test"
verbose="true" /><!-- 저장소 작업공간의 파일을 빌드 머신의 파일시스템 상으로 로드함 -->
<teamFetch repositoryAddress="${repositoryAddress}"
userId="${userId}"
password="${password}"
workspaceName="JUnit Build"
buildResultUUID="${buildResultUUID}"
destination="${java.io.tmpdir}/toolkittest"
verbose="true" />
빌드과정에서 생성된 스냅샷은 빌드 결과로 부터 추적할 수 있습니다. 빌드를 재현할려면, 빌드 결과를 열고 스냅샷 링크를 클릭해서 스냅샷 편집기에서 저장소 작업공간을 생성합니다. 또는 보류 중인 변경사항 보기에서 바꿀 대상 > 스냅샷...을 실행하여 저장소 작업공간을 스냅샷으로 바꿀 수 있습니다.
2.3 Adding Integration Levels
팀이 커지고 더 많은 사람이 더 많은 작업을 함에 따라, 콤포넌트는 급변하고 통합 비용이 많아 집니다. 좋은 방법 중 하나는 스트림 구조를 추가해서, 팀원 일부는 다른 사람들 보다 더 자주 작업을 공유하도록 하는 겁니다.
Markus는 JUnit Integration 스트림을 작성하고, 다른 스트림에서 작업 중인 하위 팀들이 일정한 주기로 변경 사항을 통합 스트림으로 전달하도록 합니다. 그리고 JUnit 스트림에서 Examples 콤포넌트를 뺍니다 ? 이제부터는 Examples 팀이 파열적인 변경사항을 반영해서 그 결과물을 JUnit Integration 스트림으로 전달합니다.
팀 분할하기
보류 중인 변경사항 보기에서 JUnit Integration으로 부터의 변경사항을 반영하고 전달할 수 있습니다. Jason은 플로우 대상을 JUnit Examples 스트림에서 JUnit Integration 스트림으로 변경하고 , 변경 사항을 조사하고, 변경사항을 수신하고 examples을 컴파일하고 테스트를 수행하는 등의 일반적인 반영 절차를 수행합니다. 이 모델의 장점은 Jason이 다른 팀원에게 영향을 끼치지 않고 새로운 변경사항을 반영할 수 있다는 겁니다. 반영 중에 문제가 발견되면, Jason은 간단히 다른 팀과 협력해서 문제를 해결할 수 있고 다른 팀원들은 그 문제로부터 격리될 수 있습니다. 반영이 완료되면, Jason은 간단히 보류 중인 변경사항 보기에서 플로우 대상을 JUnit Integration 스트림에서 JUnit Examples 스트림으로 변경하고 JUnit Examples 프로젝트에서의 반영 사항과 JUnit 프로젝트에서의 새로운 변경 사항을 전달합니다.
2.4 Backporting Changes
Markus는 프레임웍 상에서 심각한 문제를 발견하고 JUnit 스트림으로 수정 사항을 전달합니다. Bill은 Markus가 수정 사항을 JUnit 0.1 스트림으로도 전달하도록 요청합니다. JUnit 0.1 Integration용 유지 보수 릴리즈 예정이라면, 거기에도 반영해야 합니다. 변경 사항을 백포팅하기 위해, Markus는 간단히 플로우 대상 변경...을 실행해서 JUnit 0.1 스트림으로 변경하고 바꿀 대상 > JUnit 0.1의 최신 내용을 실행합니다. 이젠 유지 보수 스트림과 동기화되어 있습니다.Markus는 JUnit 스트림으로 부터 하나의 변경 세트만을 수신하기로 결정합니다. Markus가 JUnit 스트림과 작업할 땐, 많은 수신 및 전송 베이스라인을 보게됩니다. Markus는 베이스라인을 수신하지 않도록 합니다. 왜냐면 JUnit 스트림에 있는 걸 다 가져오지 않고 하나의 변경 세트만이 필요하기 때문입니다. 수신 폴더를 열어서, 해당 변경 세트를 선택하고 허용을 실행합니다.
Accepting a single change set
만약 Markus의 변경 세트가 JUnit 스트림에 독점적인 다른 변경 세트에 바탕을 두고 있지 않다면, 운좋게 별문제없이 저장소 작업공간으로 수신할 수 있습니다. 만약 JUnit 스트림과 JUnit 0.1 스트림이 상당히 갈라졌다면, Markus의 변경 세트는 간단히 허용할 수 없습니다. 오늘, Markus에게 운이 없습니다. 그래서 곧바로 변경 세트를 허용할 순 없고 대신 패치로서 작업공간에 적용할 수 있도록 제안을 받습니다.
Apply as Patch dialog
Markus는 패치로서 변경 세트를 적용하기로 결정합니다. 보류 중인 변경사항 보기에 Pending Patches 노드가 나타납니다. Markus는 백포팅할 변경 세트의 변경 사항을 비교 병합 편집기를 사용해서 한줄씩 병합할 수 있습니다. 병합한 변경 사항을 체크인해서 새로운 변경 세트를 만들고 나서, 보류 중인 변경사항 보기에서 보기에서 제거를 실행하여 해당 패치를 제거합니다. 이젠 Markus는 간단히 플로우 대상을 JUnit 0.1 스트림으로 바꾸고, 전달 기준에 맞는 지 확인 후에 변경 사항으로 전달합니다.
Pending Patches
같은 메커니즘을 유지보수 릴리즈에서 최신 릴리즈로 변경 사항을 포워드 포팅할때 사용할 수 있습니다.
댓글 없음:
댓글 쓰기