RTC User Training (3.0).ppt

• RTC User Training (3.0).ppt

RTC를 이용한 형상관리(SCM) 및 변경관리(WI)에 대한 사용자 교육 자료입니다.

일반적인 SCM 모형은 아래와 같습니다.
 


개발자 간의 작업 공유는 (1) 일반적인 경우 (2) (3) 특수한 경우 로 나누어 볼 수 있습니다.
 


training 내용은 아래와 같습니다.

Installing & launching RTC
Team invitation & joining
Work Item
- creating work items
- changing the state of work item
- associating a work item with change set
- querying work items
Plan
- plan with work items
Source Control
- source control working model & pending changes view
- sharing a project
- creating workspace & downloading sources
- check in & deliver
- refresh & accept
- resolving conflicts
- snapshot & baseline
Summary

RTC를 이용한 작업항목 유형 만들기 (3.0).ppt

• RTC를 이용한 작업항목 유형 만들기 (3.0).ppt

RTC를 이용해서 필요한 작업항목 유형을 만들 수 있는 데, 간단한 예제를 통해 워밍업을 해 볼 수 있는 자료입니다.

전반적인 작업 항목 유형 편집은 프로젝트 영역 편집기를 통해서 이뤄집니다. 아래는 일부 화면입니다.

RTC를 이용한 Visual Studio 개발 (3.0).ppt

• RTC를 이용한 Visual Studio 개발 (3.0).ppt
• SquawkVS.zip

RTC를 이용한 Visual Studio 개발시 사용할 수 있는 방법을 간단히 정리한 자료입니다.

• Project 개발 환경 Set Up
• Project 개발 소스 Import
• Project 개발 환경 초대
• Project 개발
• Project 빌드
• Project 버그 Tracking

플로우 다이어그램으로 스트림과 저장소 작업공간의 관계를 나타낸 그림입니다.
 

RTC를 이용한 병렬 개발 방법 (3.0).ppt

• RTC를 이용한 병렬 개발 방법 (3.0).ppt

병렬 개발 (멀티 스트림 개발) 방법에 대해 간단히 따라해 볼 수 있는 자료입니다.

<플로우 다이어그램의 예>


<병렬개발 환경>

RTCv2_Plan_구성.ppt

• RTCv2_Plan_구성.ppt

RTC를 이용해 Plan을 작성시 구성에 필요한 부분을 정리한 ppt 자료 입니다.

RTC_소스관리_usecase.ppt

• RTC_소스관리_usecase.ppt

RTC를 이용한 소스 관리시

- 로컬 작업 공간
- 저장소 작업 공간
- 스트림

그리고

- 체인지셋 및
- 베이스라인

에 대한 개념을 설명한 자료입니다.

그리고 여러가지 팁을 정리한 자료입니다.

작업항목 Working Copy

https://jazz.net/wiki/bin/view/Main/WorkItemWebItemProxyDesign

Work Item web UI uses a working copy to:

• manage synchronization among views
• handle special cases for attributes
• handle client communication

The goals of the working copy design are:

• Make sure all versions of a work item or attribute shown are the same
• Maintain the "isChanged" state across views
• Encapsulate work item specific changes to the working copy and out of the views
• Enable enhancements of work item management (e.g., polling and merging) without changing the view code

The working copy lets multiple views show the same work item data such that all views are kept in sync. The basic flow is:

1. View 1 creates a working copy as in instance of WorkItemProxy using the WorkItemProxyFactory which uses the Cache.
2. View 1 fetches the latest version of the work item via WorkItemProxy.
3. View 2 gets a copy of the working copy from the WorkItemProxyFactory. View 2 registers attribute listeners to get called back when the attributes change.
4. View 3 gets registers as a subscriber to WORK_ITEM_CHANGED broadcasts.
5. View 1 changes an attribute using setValue. View 2 is notified of that that the attribute has changed. View 3 is notified the the WORK_ITEM_CHANGED.

CLM 설치 - 서버 구성 토폴로지

http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=/com.ibm.jazz.install.doc/topics/c_topology_overview.html

단일 서버 CLM 평가 토폴로지 예제
이 토폴로지 예제는 Tomcat 및 Derby를 포함하는 단일 서버 CLM(Collaborative Lifecycle Management)용 Rational® 솔루션 평가 토폴로지용입니다.




WAS 서버, DB2 서버 토폴로지





완전히 분산된 CLM 엔터프라이즈 토폴로지 예제
이 예제는 IBM WebSphere® Application Server 및 엔터프라이즈 데이터베이스 관리 시스템(예: IBM DB2®, z/OS®용 DB2 및 i용 DB2)을 포함하는 CLM(Collaborative Lifecycle Management)용 Rational® 솔루션 엔터프라이즈 토폴로지의 완전히 분배된 배치용입니다.

SCM - 소스 변경 충돌 해결

요약

병렬 개발은 Jazz에선 늘상 있습니다. 우리는 여러분이 작성한 변경 사항을, 당신 팀과 공유할지 말지에 관계없이, 추적하고 버전관리할 수 있는 SCM의 기능에서 혜택을 받길 원합니다. 그런 이유로, 사용자는 개인 전용 저장소 작업공간을 갖습니다. 때때론 당신이 작성한 변경사항을 전달하기까지 두어시간만 걸릴 수도 있고, 하루가 될수도 있고, 더 길어질 수도 있습니다. 게다가, 소스제어 멀티 스트림 개발에 나와 있듯이, Jazz에서는 병렬 개발을 위해 스트림을 사용하는 것이 편리합니다. 이 자료는 충돌이 일어나는 일상에서 동료와 가까이 지내기 위한 가이드였음 합니다. 

---

목차

1. 충돌 소개
2. 충돌 인지
3. 잠재적 충돌
4. 충돌 제스처
5. 충돌 유형
6. 충돌 표현
7. 충돌 해결
1. 예 - Bill과 Markus가 같은 파일을 수정할 때
2. 예 - Markus가 이름 변경한 파일을 Bill이 수정할 때
3. 예 - Markus가 삭제한 폴더에 Bill이 파일을 추가할 때
4. 예 - Bill과 Markus가 같은 파일의 특성을 다르게 설정할 때
5. 예 - Bill이 아직 모르는 컨텐츠 유형의 파일을 자동해결할 때
6. 예 - Bill과 Markus가 같은 이름의 파일을 생성할 때 ('evil twin')
7. 예 - Bill과 Markus가 충돌하는 심볼릭링크를 만들 때
8. 결론

http://jazz.net/library/article/39

SCM - 외래 코드 관리

스트림 셋업

추천하는 셋업은 사용할 제3자(벤더) 코드 콤포넌트에 대한 스트림을 하나 생성하는 겁니다. 만약 같은 벤더로 부터 여러 서브시스템을 받게 되고, 각 서브시스템별로 릴리즈가 된다면 각각의 콤포넌트로 구성해야 합니다. 생성된 스트림은 제3자 코드의 원래 버전을 추적하기 위한 용도입니다. 릴리즈가 새로 도착하면, 이 스트림으로 전달할겁니다. 편의상 "벤더 스트림"이라 부르겠습니다.

우리가 개발 중인 애플리케이션 또한 별개 콤포넌트에 넣고 별개 스트림을 갖고 있습니다. 이 스트림에는 제3자 콤포넌트가 추가되어 있습니다. 제3자 코드에 대한 추가적인 수정 사항은 이 스트림에 전달할 겁니다.  다시말해, 이 스트림에는 제3자 릴리즈와 애플 개발에 필요한 추가한 변경 세트가 들어 있습니다. 편의상 "벤더 스트림"과 구별하기 위해 "개발 스트림"이라 부르겠습니다.

다음 예제에서는, JUnit 팀이 JUnit의 결과를 복잡한 report로 보여주는 기능을 추가할려고 합니다. 이를 위해 제3자로 부터 Sweet Reporter 기능을 도입해 활용할려고 합니다. 스트림 셋업은 다음과 같습니다.

http://jazz.net/library/article/214

SCM - 스트림 디자인 (병렬 개발)

작업 유형별로 간추린 내용입니다.

1. Going alone

예제는 한 사람으로 이뤄진 팀으로 부터 시작합니다. Markus는 JUnit라는 테스팅 프레임웍를 개발하고 있습니다. 그는 이클립스 작업공간에 두 개의 프로젝트를 갖고 있습니다. 첫번째는JUnit 프로젝트(core library와 utilities)이고, 두번째는 JUnit Examples 프로젝트(examples들)입니다. Markus는 지금 자신의 작업을 Jazz에 저장하기 위해서 스트림이 필요하진 않습니다.

저장소에 작업을 백업하고 변경를 추적하기 위해서 Markus가 필요한 모든 것은 저장소 작업공간입니다.

스트림없이 저장소 작업공간을 사용

http://jazz.net/library/article/40

SCM - 읽기 쓰기 권한 유형

http://jazz.net/library/article/215
Controlling access to source control in Rational Team Control

유형별 장단점 위주로 간추린 내용입니다.

읽기 제한 시나리오:

• 프로젝트 영역 모든 부분에 대한 읽기 제한
  프로젝트가 최고 기말사항 사항으로 선택된 사용자들만이 존재여부를 알고 있습니다.
  
  시나리오 : Bill, Jason, Markus는 새로운 가히 혁명적인 JUnit 프로젝트를 추진하기로 결정합니다. 하지만 아직 대중의 비판을 받기에는 아직 준비되어 있지 않습니다. 그래서 자신들만이 해당 프로젝트의 프로세스, 빌드, 작업 항목 및 소스 제어를 관리할 수 있도록 합니다. 이를 위해 프로젝트 영역에서 읽기 엑세스를 빼기로 합니다.
  
  장점 : 
      * 간단한 솔루션임.
      * 프로젝트 영역의 멤버가 아닐 경우 해당 프로젝트 영역 내의 모든 것들을 볼 수가 없음.
  단점 :
      * 큰 규모의 팀인 경우에는 소스에 대한 읽기 제한을 너무 단순화 시키게 됨.
  

SCM - 콤포넌트 디자인 예제

RTC 개발팀 자체가 콤포넌트 기반으로 RTC를 이용해서 SCM을 하고 있는 데.. 여기에 잘 정리된 자료가 있어서 갈무리 합니다.
아래는 Enterprise Extensions 개발팀이 RTC SCM를 이용한 콤포넌트 기반 개발 프로세스를 적용하기 위해 정리한 개발 가이드 문서입니다.

출처 : https://jazz.net/wiki/bin/view/Main/DevelopmentProcess

개발 절차 권고안

개요

먼저 Enterprise Extensions 팀을 여러개의 기능별 팀으로 나눕니다. 

• 각 팀은 (잘 정의된) 콤포넌트를 소유하고 관리합니다.
• 각 팀은 적어도 하나의 팀 스트림을 관리합니다. (여러개의 스트림을 관리할 수도 있습니다.)
• 각 팀의 팀원은 본인이 팀 스트림으로 전달하는 코드가 에러없이 컴파일 및 빌드되도록 책임집니다.
• 개발자는 다른 콤포넌트에서 필요로 하는 (깨는) API 변경시 또는 새로운 API 도입시 다른 팀과 협력해야 할 책임이 있습니다.
• 각 팀의 팀 리더 (또는 대리인) 는 팀 스트림의 관리에 책임을 집니다. 
• 각 팀의 팀 리더는 언제 통합 스트림으로 코드를 전달할 지 결정하고, 주기적으로 통합 스트림으로 부터 새로운 코드를 수용해야 합니다.
• 각 팀의 팀 리더는 통합 스트림이 깨지지 않도록 해야 합니다. 통합 빌드는 절대로 깨지면 안됩니다.
• 릴리즈 엔지니어링 팀은 이러한 작업들에 대한 기술적인 지원을 제공합니다.
• 릴리즈 엔지니어는 빌드 구조의 유지 관리 및 패키징 변경을 책임집니다.

스트림 구성

각각의 팀 스트림은 각 팀에서 소유하고 있는 콤포넌트를 빌드하기 위해 필요한 (의존적인) 콤포넌트를 포함합니다. 

팀 스트림에 포함된 콤포넌트는 세 가지로 분류할 수 있습니다:

• 각 팀에서 소유하고 관리하는 콤포넌트
  개발자는 해당 콤포넌트를 수정하고 팀 스트림으로 전달합니다.
• 빌드에 필요한 (의존적인) 콤포넌트
  소스는 항상 통합 스트림으로 부터 수용해야 합니다. (절대로 타 팀의 스트림으로 부터 코드를 수용하면 안됩니다.)
  절대로 여러분의 팀 스트림을 통해 해당 콤포넌트를 변경하면 안됩니다.
• 릴리즈 엔지니어링 콤포넌트
  해당 콤포넌트에 변경을 할 때는 팀 리더에게 알리고 팀 리더가 변경사항을 통합 스트림으로 전달하도록 합니다.

팀과 스트림

각 팀은 개발 branch마다 (적어도) 하나의 스트림과 해당 continuous build를 소유합니다.

<예>

팀	팀 스트림 & continuous build *	소유중인 콤포넌트	팀 리더
Context Aware Search	Context Aware Search	Context Aware Search	Moti Nisenson
Deployment	Deployment	Deployment	Kushal Munir or Kevin Doyle
Enterprise Build	Enterprise Build	Enterprise Build, Enterprise Build JMO	Robin Yehle or Hung Lam
Enterprise Client	Enterprise Client	ISPF Client Daemon	Xavier Houis
Enterprise SCM	Enterprise SCM	Enterprise SCM	Jean-Yves Rigolet
Promotion	Promotion	Promotion	Robin Yehle or Hung Lam
* 3.0.0.x 및 3.Next 개발 branch 마다 하나씩

이상적으론, 각각의 팀은 통합 스트림으로 전달할 권리를 갖는 사람을 적어도 두명이상 가지고 있어야 합니다. 그렇지 않을 경우, 빌드가 깨지면, 릴리즈 엔지니어링 팀은, 해당 팀에서 원하지 않겠지만, 깨진 변경을 뒤로 돌리는 작업을 수행할 수 밖에 없습니다.

각 팀의 팀 스트림은 통합 스트림과 플로우하게 됩니다. 

릴리즈 엔지니어링 팀도 팀 스트림을 갖고 있으며 zOS Integration 스트림에는 다음과 같은 콤포넌트를 포함하고 있습니다:

• ISPF Client. Enterprise Client 팀에서 소유하고 관리함.
• Build zComponents. Enterprise Build 팀에서 소유하고 관리함.
• Deployment zComponents. Deployment 팀에서 소유하고 관리함.
• Promotion zComponents. Promotion 팀에서 소유하고 관리함.

빌드 제약때문에 zOS Integration 빌드에서는 continuous build를 하지 않습니다. 변경사항은 직접 zOS Integration 스트림에 전달되므로 개발자는 다음 사항을 주의해야 합니다.

개발자가 전달시 빌드가 깨지지 않도록 합니다. 즉 zOS Integration 스트림으로 전달시 빌드 요청을 즉시해야 합니다. 그리고 가급적 빨리 깨진 빌드를 수정해야 합니다.

개발자 작업 절차

여기에 기술된 내용을 꼭 따라야 하는 것은 아니지만, 빌드가 깨지고 이로 인해 작업이 지연되는 것을 방지할 수 있습니다. RTC는 Personal Build와 저장소 작업공간 등과 같이 빌드가 깨지지 않도록 회피할 수 있는 도구들을 제공합니다. Continuous Build가 종종 깨지겠지만, 대부분의 빌드 실패를 쉽게 방지할 수 있는 도구들 입니다.

스트림 구조가 많이 바뀌더라도 개발자의 책임과 작업 절차는 본질적으로 바뀌지 않아야 합니다. 개발 절차는 아래와 같습니다:

1. 코드를 작성하고 디버그합니다.
2. 팀의 Continuous Build에 대한 Personal Build를 개발자 작업공간을 이용해서 실행합니다. 이 저장소 작업공간은 팀 스트림과 플로우해야 합니다.
3. 빌드가 깨끗하면, 팀 스트림으로 전달합니다.

Personal Build가 절대적으로 필요한 건 아니지만, 시간과 좌절로 부터 구원을 제공합니다. Continuous Build는 상대적으로 크지 않고 대부분 30분 이내로 실행합니다. 그래서 큰 부담이 되지 않습니다.

협업 관련 개념

대부분 알고 계시겠지만 같은 용어를 사용하도록 할 가치가 있습니다.

RTC의 보류 중인 변경사항 보기는 저장소 작업 공간들과 플로우 대상들 간의 협업을 집중할 수 있는 방식을 제공합니다. 플로우 대상은 스트림 또는 다른 저장소 작업공간일 수 있습니다..

플로우는 협업을 위해 변경사항을 수용하거나 전달하는 종점을 말합니다. 플로우로 부터 변경사항을 수용할 땐 플로우 소스로 간주보며, 플로우로 변경사항을 전달할 땐 플로우 대상으로 간주합니다.

요점은 이러한 새로운 환경을 통해서 협력자들에게 보다 많은 주의를 기울이게 만들어 준다는 겁니다. 일반적인 규칙은 개발자들은 그들의 팀 스트림과만 협업을 해야한다는 겁니다. 때때로 보다 복잡한 협업이 필요하겠지만 그런 경우는 예외적이어야 합니다.

빌드를 깰수 있는 API 변경 작업 절차

빌드를 깰수 있는 API를 변경할 때는 매우 조심해야 합니다. API에 의존적인 관계를 잘 알고 있어야 함에도 불구하고 잘 알 수 없다는 사실이 일을 어렵게 합니다. 다른 사람이 의존한다는 걸 잘 알지 못하기에 쉽게 다른 사람의 코드를 깨버릴 수 있습니다.

또한 안정적인 public API를 제공하는 데 주의를 많이 기울이지 못하고 있고, 그리고 다른 콤포넌트의 내부 패키지를 사용하고도 있습니다. 때문에 전체적으로 public API 설계에 더 많은 주의를 기울이면 개발이 좀더 수월해 지게 됩니다.

API 변경은 자주 일어나면 안됩니다. 만약 API를 변경할 때는, 당사자는 제품 전반에 변경사항이 올바로 적용되고 빌드가 깨지지 않도록 책임을 져야합니다. 여러가지 방법이 있을 수 있는 데, 여기서는 RTC SCM팀에서 사용해 오고 있는 안정적인 절차를 기술하고자 합니다.

1. API를 변경할 예정이라면 평상시처럼 작업공간을 생성합니다. 그리고 플로우 대상을 통합스트림으로 변경하고 API 변경으로 인해 깨질 수 있는 콤포넌트들을 수용합니다.
   이 작업을 통해 의존관계에 있는 코드를 모두 이클립스 작업공간에 두게됩니다. 이로 인해 API 변경으로 인해 깨지는 것을 보다 원할하게 발견하고 수정할 수 있게 됩니다. 주의: 이렇게 수용한 콤포넌트들을 팀스트림으로 전달하지 않도록 주의합니다
2. API를 변경합니다. 다른 콤포넌트에서 컴파일 에러가 발생하면, 에러를 수정을 하고 API 채택용 체인지셋을 준비해 둡니다.
3. 각 (콤포넌트) 팀별로 API 채택용 작업항목을  생성합니다. 일반적으로 타스크 유형으로 작성하며 "채택"을 제목에 포함시킵니다. 그리고 API 변경용 작업항목의 자식관계로 링크합니다.
4. API 채택용 체인지셋을 해당 작업항목과 연계시킵니다.(그리고 complete 처리를 합니다).
5. API 채택용 작업항목에 해당 팀리더를 가입시킵니다. 그리고 작업항목을 해당 콤포넌트 소유 팀에 할당합니다.
6. 해당 팀리더, 릴리즈 엔지니어와 변경사항 전달 시기를 정합니다. 주의: 마일스톤(릴리즈) 주간은 이런 변경 처리를 하기에 썩좋은 시기가 아닙니다. 
7. 채택용 작업항목에 대한 반대의견을 주시하고 해당 팀과 작업하여 문제를 해결합니다. 당신 팀리더와 작업하여 함께 전달될 수 있도록 합니다.
8. 통합스트림으로 전달할 준비가되면, 당신 팀리더와 함께 작업하여 API 변경사항과 채택용 작업항목 상의 변경사항을 함께 통합스트림으로 전달하도록 합니다. 주의: 이렇게 되면, 각 팀이 소유한 콤포넌트에 변경사항은 통합스트림에 존재하지만 각 팀스트림에는 들어있지 않습니다. 이것은 예상된 일입니다.
9. 각 팀은 팀스트림을 통합스트림의 최신내용으로 갱신시 채택용 변경사항을 수용하게 됩니다.

당신의 public API에 대한 변경 작업으로 깨진 콤포넌트를 당신이 수정하는 일은 공정하고 기대되는 활동입니다. 계약을 깬 당사자로서 뒤처리를 마무리할 수 있습니다. 다행을 위해 이런 일은 자주 일어나지 않아야 합니다.

만약 당신이 채택용 변경사항을 준비하지 못했다면 다른 팀에서는 당신을 불러서 변경작업을 요청할 권리가 있습니다. API 채택이 제대로 되었는 지 확신없이 API 변경사항을 전달하면, 당신이 빌드를 깨게 되고, 고참 개발자들로 부터 질책을 받게 될겁니다.

새로운 API 제공시 협업 절차

각 팀별로 해당 팀스트림에서 작업하는 까닭에 새로운 API 채택시 협업이 보다 까다롭습니다. 협업이 잘 되지 못하면 통합빌드가 보다 자주 깨지게 됩니다. 자주 발생하는 문제는 새로운 API를 개발한 팀이 통합스트림으로 전달하기 전에 다른 팀에서 먼저 해당 API를 사용한 코드를 전달하는 겁니다. 

이러한 상황이 절대로 발생하면 안됩니다. 여러분의 팀스트림과만 협업한다는 기본 규칙만 따른다면 안전합니다. 통합스트림으로 전달된 새로운 API가 필요하다면, 당신 팀리더에게 요청해 팀스트림을 통합스트림의 최신내용으로 갱신하도록 합니다. 이를 통해 새로운 API가 들어오면 안전하게 사용할 수 있습니다.

이는 조금 더딘 작업이 될 수 있습니다. 만약 새로운 API 채용이 긴박하다면, 팀리더는 보다 자주 팀스트림을 통합스트림의 최신내용으로 갱신하는 업무가 가중됩니다. 이는 빌드를 깨지 않도록 하기 위해 불가피한 일입니다.

현실에 대한 고려

위와 같은 새로운 API 채용 권고안은 이론적으로 잘 작동하지만 몇몇 상황에서는 귀찮을 수 있습니다.

팀 규모가 작은 경우, 개발자들은 여러팀에 속해 있습니다. 예를 들어 개발자가 UI 관련 작업항목을 처리 중인데, 해당 작업항목이 Enterprise Build 스트림과 Promotion 스트림에 서로 의존적인 변경을 필요로 합니다. 이런 상황에서 Enterprise Build 스트림에서 모든 변경작업을 처리할 유혹을 심하게 받습니다 - 왜냐면 두개 콤포넌트가 해당 스트림에 모두 들어 있으니까요. 그렇게 하지 마십시요 - 콤포넌트 소유권이 없는 팀스트림으로 코드를 전달하면서 자주 빌드가 깨지고 있고 그런 일이 계속 발생하게 됩니다.

보류 중인 변경사항 보기를 통해 여러 협업을 추적할 수 있다는 걸 기억하십시요. 

만약 Enterprise Build와 Promotion을 동시에 개발하고자 하는 경우:

1. Enterprise Build 스트림과 플로우하는 저장소 작업공간을 만듭니다. 스트림으로 부터 필요한 콤포넌트/프로젝트들만 로드합니다.
2. Promotion 스트림과 플로우하는 저장소 작업공간을 만듭니다. 스트림으로 부터 필요한 콤포넌트/프로젝트들만 로드합니다.
3. 결과적으로 이클립스 작업공간엔 변경에 필요한 프로젝트들이 있게 됩니다. 변경 작업을 하면 각각의 저장소 작업공간에 체인지셋이 만들어지는 것을 추적합니다. 여느 때처럼 개발합니다.
4. 이제 Enterprise Build 콤포넌트에 새로운 API를 만들고 Promotion 콤포넌트에서 사용할 예정입니다. 먼저 새 코드가 제대로 빌드되는 지 알아보기 위해 continuous.enterprise.build.jcb에 대한 Personal Build를 실행합니다. 성공적으로 끝나면 Enterprise Build에 대한 변경사항만을 전달합니다. 
5. Enterprise Build 팀리더에게 변경사항을 통합스트림으로 전달하도록 요청합니다.
6. Promotion 팀리더에게 Promotion 스트림을 통합스트림의 최신내용으로 갱신하도록 요청합니다.
7. 2단계에서 생성한 Promotion 저장소 작업공간을 Promotion 스트림의 최신내용으로 갱신합니다. 이를 통해 Enterprise Build의 새로운 API를 답게됩니다.
8. continuous.promotion.jcb의 Personal Build를 Promotion 저장소작업공간을 대상으로 실행합니다. 성공적으로 끝나면 변경사항을 Promotion 스트림으로 전달합니다.

이 절차는 번거롭게 보이지만, 실제로 개발을 많이 지체시키지 않습니다. 왜냐면 실제 개발작업을 함께 할수 있고 대기시간은 전달시에만 발생합니다. 팀리더들이 5단계 및 6단계를 빨리 처리한다면 지체되지 않습니다. 반면에 빌드가 깨짐으로 인해, 모든 사람들이 지체되는 것을 방지할 수 있습니다. 

이 방식은 여러 개발자가 비슷한 변경작업 협업시에도 적용할 수 있습니다. 개발자 한명이 변경작업하는 대신에, 예를 들어 두명의 개발자가 이 작업항목을 처리한다고 가정해 봅시다. 한명의 개발자는 Enterprise Build 콤포넌트에 변경작업을 하고 여느때처럼 스트림으로 전달합니다. 그리고 팀리더에게 통합스트림으로 전달하도록 요청합니다. 

Promotion에서 변경 작업을 해야 하는 개발자는 기다릴 필요없이 Enterprise Build 스트림에서 로드할 저장소 작업공간을 가지면 됩니다 - 스트림에 새로 작성된 API가 들어있고 이를 활용해 코드를 작성합니다. 다만 통합스트림을 거쳐 Promotion 스트림으로 들어올 때까지 전달할 수 없다는 겁니다.

여러개의 작업공간을 이용해 협업하는 것은 플로우 대상을 다른 스트림으로 바꿔서 변경사항을 수용하는 것과는 많이 다르다는 것을 명심하세요. 새로운 API 변경사항이 통합스트림을 거쳐 Promotion 스트림으로 들어오기 전에 continuous.promotion.jcb에 대한 Persnal Build를 Promotion 저장소 작업공간에 대해 실행하면, 빌드는 실패하게 됩니다.

Promotion 작업공간에는 필요한 콤포넌트를 모두 포함하고 있기에 여기서 모든 변경작업을 처리했다고 가정해 봅시다. 개발하고 디버그하고 여느때처럼 Promotion 스트림으로 전달합니다. 하지만 팀리더는 규정대로 Promotion 콤포넌트에 대한 변경사항만 통합스트림으로 전달하지만 Enterprise Build 콤포넌트에 대한 변경사항은 알아차리지 못합니다. 결과적으로 통합스트림은 깨지게 됩니다. 쉽게 피할 수 있는 것처럼 보이지만 자주 발생하고 있습니다.

팀 리더 작업 절차

팀리더는 팀스트림을 관리할 책임을 집니다. 즉, 주기적으로 팀 소유의 콤포넌트 변경사항을 통합스트림으로 전달해야 하고, 팀스트림을 주기적으로 통합스트림의 최신 내용으로 갱신하기 위해 타 콤포넌트들의 변경사항을 수용해야 합니다. 

팀리더는 변경사항 수용으로 인한 개발 혼란을 고려해 갱신 주기를 조절해야 합니다. 격일 주기를 권고합니다. 마일스톤 주간에는 매일하는 것이 낫습니다. 주기가 너무 길면, 많은 충돌 해결이 필요해 집니다.

통합스트림 따라잡기

1. 팀스트림 기반으로 저장소 작업공간을 만듭니다. 팀스트림의 최신내용으로 갱신합니다.
2. 저장소 작업공간의 플로우 대상을 통합스트림으로 변경합니다.
3. 팀소유가 아닌 콤포넌트들에 대한 모든 변경사항을 수용합니다.
   주의: 팀소유가 아닌 콤포넌트들에 전달할 수 있는 변경사항들이 있을 수 있습니다. 의도한게 아니라면 통합스트림의 내용으로 바꾸기를 합니다.
4. 통합스트림에 팀소유의 콤포넌트에 대한 수용할 수 있는 변경사항들이 있는 경우에는 왜 있는지 조사가 필요합니다. 팀스트림에서 버리기를 한 것일수도 있고, 다른 팀스트림에서 개발자가 (잘못) 전달한 것일 수도 있습니다. 또는 API 채택과정에서 만들어진 것일 수도 있습니다. 변경사항에 대한 소스를 이해하고 나면, 어떻게 처리할 지 결정할 수 있습니다.
5. 팀의 Continuous Build에 대한 Persnal Build를 이 저장소작업공간에 대해 실행합니다. 빌드가 성공하면, 저장소 작업공간의 플로우 대상을 팀스트림으로 변경하고 변경사항을 전달합니다. 3단계에서 바꾸기 한 콤포넌트를 전달해야 한다는 것을 기억하세요. 
   주의: Persnal Build가 반드시 필요하진 않지만 종종 손상을 면할수 있으니, 시간이 있다면 수행하시기 바랍니다.

통합스트림 따라잡기시 주의하세요. 팀스트림에 무엇을 넣어야 하고 넣지 말아야 할지 모르고 있다면, 스트림을 엉망으로 만들 수 있습니다. 아래 Enterprise Build 저장소 작업공간을 보면, 통합 스트림 따라잡기를 위해 플로우 대상이 통합스트림으로 변경되어 있습니다. ?

빨간 네모로 표시된 콤포넌트는 Enterprise Build 스트림에 이미 포함된 콤포넌트이므로 따라잡기를 위해 변경사항 수용을 자유롭게 할수 있습니다.

하지만 검정 네모에 들어 있는 콤포넌트들은 (+)가 표시되어 있는 새로운 콤포넌트들로 통합스트림에는 있지만 Enterprise Build 스트림에는 현재 없는 것들입니다. 이들 콤포넌트들에 대한 새로운 의존성이 있다는 것을 알지 못한다면 새 콤포넌트들은 수용하면 안됩니다.

이러한 걱정거리를 피할수 있는 방법은 필요한 콤포넌트별로 통합스트림을 플로우 대상으로 지정하는 것으로써 실수로 새로운 콤포넌트를 팀스트림으로 가져오는 경우를 많이 줄일 수 있습니다.

통합스트림으로 전달

통합스트림 따라잡기에 사용했던 같은 저장소 작업공간을 이용해 팀 변경사항을 통합스트리으로 전달합니다.

1. 통합스트림으로 전달할 것들을 결정합니다. 팀스트림에 있는 것들을 모두 전달하지 않을 때는, 저장소 작업공간에서 변경사항을 수용하거나 버리기를 할수 있습니다. 저장소 작업공간에서 전달할 변경사항만을 갖도록 합니다.
2. 팀스트림 Continuous Build의 Persnal Build를 저장소 작업공간에 대해 실행합니다. 빌드가 성공했는 지 확인합니다.
3. 팀 소유 콤포넌트들에 대한 베이스라인을 만듭니다.
4. 통합스트림과 플로우하는 저장소 작업공간을 만듭니다. 팀스트림 저장소작업공간에서 통합스트림 저장소작업공간으로 베이스라인을 전달합니다.
5. 통합스트림 Continuous Build의 Persnal Build를 통합스트림 저장소 작업공간에 대해 실행합니다. 빌드가 성공했는 지 확인합니다.
6. 빌드가 성공하면 통합스트림으로 변경사항을 전달합니다.
7. 팀스트림으로 베이스라인을 전달합니다. 베이스라인은 비어 있지만 (변경사항은 이미 팀스트림에 있기때문에) 통합스트림으로 무엇을 전달했는 지 알수 있는 방법을 제공합니다.

베이스라인

베이스라인은 저장소 객체로서 특정 저장소 작업공간 또는 스트림의 콤포넌트의 변경할 수 없는 형상 기록을 제공합니다. 베이스라인은 고정되어 있는 참조 포인트로써, 콤포넌트를 이전의 형상기록으로 되돌릴 때 유용하고 또는 스트림과 저장소 작업공간을 새로운 개발을 시작할 지점으로 베이스라인에 기록된 형상으로 초기화할 때 유용합니다.

베이스라인은 체인지셋으로 구성되어 있으며, 베이스라인을 전달하거나 수용하면 베이스라인에 포함된 체인지셋을 실효적으로 전달하거나 수용하게 됩니다.

개발자로서 플로우 대상을 변경할 경우 자주 베이스라인을 볼수 있습니다. 아래 이미지 보도록 하죠:

위는 Enterprise Build 작업공간으로 통합스트림과 플로우하고 있습니다. Build 콤포넌트에 수용할 수 있는 베이스라인(4194)이 있습니다. 이 베이스라인을 작업공간으로 수용하면 베이스라인에 연계된 모든 체인지셋을 수용하는 겁니다. 이 베이스라인은 아마도 팀리더가 통합스트림으로 전달할 때 만들어 졌을겁니다.

베이스라인은 편리합니다. 필요할 경우 콤포넌트를 알고 있는 상태로 쉽게 되돌릴 수 있습니다.

Enterprise Build 콤포넌트에 수용할 수 있는 베이스라인(212)이 있습니다. 당신은 Enterprise Build 작업공간에서 작업하고 있기에 조금 이상해 보입니다. 몇몇 상황에서 발생할 수 있기에 크게 걱정할 필요는 없습니다. 베이스라인이 비어 있다는 걸 알수있고, 아마도 해당 베이스라인과 연계된 변경사항은 스트림에 이미 들어있다는 것을 뜻하므로 안전하게 별탈없이 베이스라인을 수용할 수 있습니다.

Java 캐스트 vs 어댑터

 http://www.eclipsezone.com/articles/what-is-iadaptable/

List list = new ArrayList();
list.add("data");       // this is OK, list is valid
list.ensureCapacity(4); // this is not, ensureCapacity() is ArrayList only 
/* You can even test for this dynamically at runtime using list instanceof ArrayList. */

Cast 사용시	Adapter 사용시
Object o = new ArrayList(); List list = (List)o;	IAdaptable adaptable = new ArrayList(); List list = (List)adaptable.getAdapter(java.util.List.class);

- 아래 예처럼 HashMap를 List로 바꿀 수 있음

IAdaptable adaptable = new HashMap();
List list = (List)adaptable.getAdapter(java.util.List.class);

- 대신 IAdaptable 인터페이스 구현이 필요함

public class HashMap implements IAdaptable {
  public Object getAdapter(Class clazz) {
    if (clazz == java.util.List.class) {
      List list = new ArrayList(this.size());
      list.addAll(this.values());
      return list;
    }
    return null;
  }
  // ...
}

- UI와 딸린 데이터간에 Adapter를 사용할 수 있음

Java 멤버 필드 변수 초기화

There are several kinds of variables:

• Member variables in a class?these are called fields.
• Variables in a method or block of code?these are called local variables.
• Variables in method declarations?these are called parameters.

Initializing Fields

As you have seen, you can often provide an initial value for a field in its declaration:

public class BedAndBreakfast {

    public static int capacity = 10;  //initialize to 10

    private boolean full = false;  //initialize to false

}

This works well when the initialization value is available and the initialization can be put on one line. However, this form of initialization has limitations because of its simplicity. If initialization requires some logic (for example, error handling or afor loop to fill a complex array), simple assignment is inadequate. Instance variables can be initialized in constructors, where error handling or other logic can be used. To provide the same capability for class variables, the Java programming language includes static initialization blocks.

---

Note: It is not necessary to declare fields at the beginning of the class definition, although this is the most common practice. It is only necessary that they be declared and initialized before they are used.

---

Static Initialization Blocks

A static initialization block is a normal block of code enclosed in braces, { }, and preceded by the static keyword. Here is an example:

static {

    // whatever code is needed for initialization goes here

}

출처 : http://download.oracle.com/javase/tutorial/java/javaOO/variables.html

Java 중첩클래스 내부클래스

Summary of Nested Classes

A class defined within another class is called a nested class. Like other members of a class, a nested class can be declared static or not. A nonstatic nested class is called an inner class. An instance of an inner class can exist only within an instance of its enclosing class and has access to its enclosing class's members even if they are declared private.The following table shows the types of nested classes:

Types of Nested Classes

Type	Scope	Inner
static nested class	member	no
inner [non-static] class	member	yes
local class	local	yes
anonymous class	only the point where it is defined	yes

http://download.oracle.com/javase/tutorial/java/javaOO/summarynested.html

JFace 개발 샘플

JFace를 위해 buildpath 설정

org.eclipse.jface
org.eclipse.core.commands
org.eclipse.equinox.common
org.eclipse.swt 

http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/SampleListViewer.htm

SWT Widget Sample Screen shots

SWT Widgets

Below are screenshots and links to documentation for many of the widgets included in SWT. For a complete list of classes including those that don't screenshot well, see the SWT Javadoc.

 http://www.eclipse.org/swt/widgets/

SWT Part 4 - How to use ToolBars and SashForms

In the previous three installments of this series, I introduced you to Eclipse, the Eclipse Standard Widget Toolkit (SWT), and the JFace GUI tool kits used to construct Eclipse and standalone rich GUIs. I also introduced many of the basic GUI controls, container types, and layout managers. I then I showed you how you can combine these controls into simple working applications. I also detailed how you can provide those applications with a menu system. Finally, I demonstrated how you can follow best practice by creating a library of methods and classes to ease GUI development.
Here, we complete our survey of the various widgets in the org.eclipse.swt.widgets and org.eclipse.swt.custom packages (unless otherwise noted, the controls I discuss are in the widgets package). For background, it is assumed you have read at least the first installment of this series, "How to create a simple SWT application."

Introduction

I will discuss several GUI controls in the following sections. These controls are demonstrated by a single application program called BarApp. As in earlier installments, BarApp is an extension of the BasicApplication class where the control creation methods exist. Several screenshots of this application will be used to show the features of the different controls.
Figure 1 below shows all the controls we will discuss, including several ToolBars and a CoolBar. At the extreme left are three bordered Composites (containing a Label) -- each of which is inside a pane of a SashForm. This SashForm is itself inside a bordered Composite in a larger SashForm. Near the middle left is a vertical ToolBar with the Open Tracker button at the top. On the top right are four horizontal ToolBars (inside two CBanners) -- of which only two can be seen; the first two use text labels, the second two use images (the same one). All of the ToolBars and CBanners are inside a single Composite in the outer SashForm. This structure can best be seen by the control hierarchy shown in Listing 1.


Figure 1. BarApp example
 http://www.ibm.com/developerworks/opensource/library/os-jface4/index.html

SWT Part 3 - How to use TabFolder, Canvas, and StyledText

In the previous two installments of A gentle introduction to SWT and JFace, I introduced you to Eclipse, the Eclipse Standard Widget Toolkit (SWT) and the JFace GUI tool kits used to construct Eclipse and stand-alone rich GUIs. I also introduced the several basic GUI controls and container types. Then I showed how to combine these controls into simple working applications. I detailed how to provide those applications with a menu system. Finally, I demonstrated how you can follow best practice by creating a library of methods and classes to ease GUI development.
Here, I continue my survey of the various widgets in the org.eclipse.swt.custom and org.eclipse.swt.widgets packages. Unless otherwise noted, the controls I discuss are in the widgets package.

TableTree

In the previous installment, "How to use combo, list, table, and tree controls," I described the Tree and Table controls. SWT supports a hybrid version of these controls, in the custom package, called TableTree. In Eclipse V3.1, the Tree control was enhanced to be a functional replacement for TableTree, and TableTree was deprecated. Figure 1 shows an example Tree in tabular format (TableTree emulation mode). As you can see, each item in the tree is divided into columns. As the creation of both tables and trees were shown previously, and creating a tabular Tree is basically a combination of these two tasks, I will not repeat them here. The Tree sample included with this article demonstrates the creation of a tabular Tree. The code for creating a TableTree is very similar to the code I include for Tree, so if you need support for older versions of Eclipse, you can use the TableTree control.

Figure 1. Tabular Tree Example

The rest of this article will demonstrate the use of many new SWT controls. I will do this in the context of a single application called TabFolder1App.

---

Back to top

 http://www.ibm.com/developerworks/opensource/library/os-jface3/index.html

SWT Part 2 - How to use combo, list, table, and tree controls

Programmers use the Standard Widget Toolkit (SWT) and JFace libraries to develop graphical user interfaces (GUIs) for the Eclipse environment, and to develop stand-alone GUI native applications.

In the first installment of this series, "How to create a simple SWT application," I introduced you to Eclipse, the Eclipse SWT, and the JFace GUI tool kits to construct Eclipse and stand-alone rich GUIs. I also introduced the basic label, text, and button GUI controls, and the composite, group, and shell container types. Finally, I showed you how to combine these controls into a simple working application.

Here, you will learn how to add menus to your application, use some list input controls, and use the more advanced table and tree container controls. I also will demonstrate some best practices by employing service methods to easily build GUIs. Finally, I will show you how to extract reusable function into a base application class.

Except where noted, all the widgets and controls discussed are in the org.eclipse.swt.widgets package.

Menus

All but the most primitive GUI applications require menus. Menus add to any GUI's usability. Menus are dynamically presented selection lists that correspond to functions available for use (often called commands) or GUI states. As you would expect, you create menus with the menu widget. Menus can contain other menus or menuItems, which can contain menus (that is, a hierarchy of menus). MenuItems represent the commands you can perform or the GUI state you selected. Menus can be associated with the application's (that is, shell) menu bar or they can be pop-up menus that float over the application window.

You must define menus as one of three mutually exclusive styles:

1. BAR acts as the menu bar for the shell
2. DROP_DOWN drops down from the menu bar or a menu item
3. POP_UP pops up from the shell, but is contextual to a specific control

Menus support some additional optional styles:

• NO_RADIO_GROUP does not act as a radio group; use it when the menu contains RADIO-style items
• LEFT_TO_RIGHT or RIGHT_TO_LEFT selects the text direction

You must define menuItems as one of five mutually exclusive styles:

1. CHECK can be persistently selected (that is, checked)
2. CASCADE contains a menu that should drop down
3. PUSH acts like a button that causes an immediate action
4. RADIO acts like a CHECK where only one of the items with this type can be selected
5. SEPARATOR acts as a separator (often a bar) between groups of items; this item has no function

Creating a menu system is fairly complex. Listing 1 shows a code sample that creates an operable menu system.

 http://www.ibm.com/developerworks/library/os-jface2/index.html

SWT Part 1 - How to create a simple SWT application

The Standard Widget Toolkit (SWT) and JFace libraries are used to develop graphical user interfaces (GUIs) for the Eclipse environment, and also to develop stand-alone GUI native applications. In this article, I introduce some of the basic SWT (the name for the basic GUI object) types and show how to combine them to create a working application.

About Eclipse, SWT, and JFace

As noted on the Eclipse Web site, Eclipse is a kind of universal tool platform. It's an open, extensible IDE for anything and nothing in particular, and provides tool developers with flexibility and control over their software technologies.

Eclipse provides a base for developers to produce rich GUI-driven tools and applications. Fundamental to this capability are the Eclipse GUI libraries SWT and JFace.

SWT is a library that creates a Java view of the native host operating system GUI controls. It is host implementation-dependent. This means SWT-based applications have several key characteristics:

1. They look, act, and perform like "native" applications.
2. The widgets provided reflect the widgets (the components and controls) provided on the host operating system.
3. Any special behavior of the host GUI libraries is reflected in SWT GUIs.

These goals make SWT different from Java technology's Swing, which was designed to hide operating system differences.

The SWT library reflects the basic widgets of the host operating system. In many circumstances, this approach is too low-level. The JFace library helps by adding many services to SWT applications. JFace does not hide SWT; it just extends it. As you will see later in this series, one of its most important extensions is to isolate the application's data model from the GUI that displays and changes it.

 http://www.ibm.com/developerworks/opensource/library/os-jface1/index.html

Eclipse SWT 도움말 및 샘플

이클립스에서 제공하는 SWT 라이브러리를 사용하실 경우...

이클립스 SWT 홈 : http://www.eclipse.org/swt/
- 코드 샘플 (SWT snippets) : http://www.eclipse.org/swt/snippets/

SWT org.eclipse.swt.widgets 라이브러리 도움말 사이트 (Tree 뷰를 통합 접근 방법)
- http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/widgets/package-tree.html

그외 코드 샘플 사이트
- http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/CatalogSWT-JFace-Eclipse.htm

참고> java.util 라이브러리 도움말 사이트
Java 6 - http://download.oracle.com/javase/6/docs/api/java/util/package-tree.html
Java 5 - http://download.oracle.com/javase/1.5.0/docs/api/java/util/package-tree.html

참고> 샘플 코드 사용시

RTC 클라이언트 zip이 풀려 있는 경우
샘플 코드 테스트용 프로젝트의 Java Build Path에 Add External Jars를 추가해 줍니다.
위치는 \jazz\client\eclipse\plugins\org.eclipse.swt.win32.win32.x86_3.5.2.v3557f.jar

결함 등록 및 처리 과정 일반

등록/검증 과정(Verification Process)

Activity: This is the actual activity that was being performed at the time the defect was discovered. For example, during function test phase, you might decide to do a code inspection. The phase would be function test but the activity is code inspection.

Trigger: The environment or condition that had to exist for the defect to surface. What is needed to reproduce the defect? During Review and Inspection activities, choose the selection which best describes what you were thinking about when you discovered the defect. For other defects, match the description with the environment or condition which was the catalyst for the failure.

Impact: For in-process defects, select the impact which you judge the defect would have had upon the customer if it had escaped to the field. For field reported defects, select the impact the failure had on the customer.

문제 등록 관련 섹션 (Opener Section - Verification Process)
문제점 발견 활동 (Defect Removal Activities)	문제 발생 환경/조건 (Triggers)	문제가 고객에게 끼칠 영향 (Impact)
Design Review Code Inspection Unit Test Function Test System Test	Design Conformance Logic/ Flow Backward Compatibility Lateral Compatibility Concurrency Internal Document Language Dependency Side Effect Rare Situations Simple Path Complex Path Coverage Variation Sequencing Interaction Workload/Stress Recovery/Exception Startup/Restart Hardware Configuration Software Configuration Blocked Test (previously Normal Mode)	Installability Serviceability Standards Integrity/Security Migration Reliability Performance Documentation Requirements Maintenance Usability Accessibility Capability

 http://www.research.ibm.com/softeng/ODC/DETODC.HTM