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