»
S
I
D
E
B
A
R
«
지속적 통합(Continuous Integration) 구성 사례
Jun 7th, 2011 by Wegra Lee

이번엔 지속적 통합 사례를 하나 정리해보겠다. (지속적 통합의 개념 설명은 이곳에..)

Components and Basic Workflows

이번에 구성해본 지속적 통합(CI) 환경의 구성 요소는 다음과 같다.

  • CI (Continuous Integration) 툴: IBM Rational Team Concert (RTC)
  • 소스 관리: IBM Rational Team Concert
  • 빌드 스크립트: Apache Ant
  • (참조) Apache Maven

비록 RTC라는 상용 툴을 사용하고는 있지만, 이 글에서 다루는 대부분의 내용은 개념적인 것이라, 다른 툴(예: Hudson, TeamCity, CruiseControl)을 사용할 때도 그대로 적용/응용할 수 있다.

전체 시스템을 그림으로 나타내면 대략 다음과 같다.

ci

RTC 서버의 다양한 기능 중, 여기에서는 소스 관리와 빌드 관리, 그리고 웹 UI 정도이다. 거시적인 작업 흐름은 다음과 같다.

  1. 개발자가 변경 내용(change-set)을 소스 저장소에 전달한다.
  2. RTC 서버의 빌드 모듈이 이를 인식해 적당한 빌드 엔진에 할당한다.
  3. 빌드 엔진은 소스 저장소로부터 빌드에 필요한 데이터를 내려 받아 Ant 빌드 스크립트를 수행한다.
  4. Ant 빌드 스크립트는 빌드를 수행하고 산출물을 개발 서버 및 API 서버에 배포한다.
  5. 빌드 엔진은 빌드 결과 및 과정은 빌드 서버에 알리고, 서버는 개발자 PC에 푸시한다.

개발자나 프로젝트 관련자들은 이런 모든 과정/결과를 언제든 전용 Eclipse UI나 Web UI를 통해 확인할 수 있다.

또한, 어떤 빌드 엔진을 사용할 지, 어떤 스크립트를 사용한 지 등은 모두 configuration 가능하다.

Project Directory Layout

여러 팀, 다양한 과제에 걸쳐 일을 효율적으로 진행하려면 프로젝트 구성부터 일관적으로 유지하는 것이 좋다.

Ant는 비록 산업 표준 빌드 툴이지만, 프로젝트 구성에 대한 표준 규약은 제공하지 않는다. 때문에 담당자 취향만큼이나 다양한 구성이 존재하며, 그 구성을 정하고 관리하는데에만 상당한 고뇌와 노력이 소요된다. 그리고 재활용도 쉽지 않다. 바로 이 문제를 타파하고자 나온 오픈소스 프로젝트로 Maven이란 것이 존재한다. Maven 개발자들은 프로젝트의 구성에 관련된 모범 사례(best practice)들을 집대성하고자 하였다. 무분별한 컨피규레이션 허용보다는 잘 정의된 모범 사례를 따른는 것을 원칙으로 삼은 것이다(Convention over Configuration). 물론 그 결과가 이상적으로 완벽하진 않지만, 상당수의 프로젝트에 적용하는데 큰 무리가 없을 것이다.

어쨌든, 본 예제에서는 Ant를 사용하지만 Maven의 이상과 결과를 상당부분 따르고 참조할 것이다. 물론 Ant이기 때문에 언제든 어렵지 않게 수정 가능하다.

그래서 내가 구성한 기본 구성은 다음과 같다.

  • src/main/java – 제품 소스 코드
  • src/main/resources – 제품에 포함될 리소스
  • src/main/config – 제품 설정 정보
  • src/main/webapp – 웹 애플리케이션 소스
  • src/test/java – 테스트 소스 코드
  • src/test/resources – 테스트에 필요한 리소스
  • lib/main – 제품 수행에 필요한 라이브러리
  • lib/test – 테스트에 필요한 라이브러리 (junit, mokito  등)
  • tools – 팀내 공용 툴 (예: FindBugs, CheckStyle, Code Pro Analytix 등)
  • build.xml – Ant 빌드 스크립트
  • build.properties – Ant 빌드 스크립트용 커스텀 프로퍼티 파일
  • build-jazz.xml – RTC/Jazz용 빌드 스크립트(build.xml을 확장함)
  • LICENSE.txt – 제품 라이선스 정보
  • README.txt – readme 파일

참조함 Maven의 표준 디렉터리 구성과 크게 다르지 않다. 간소화를 위해, 크게 필요 없다고 생각되는 filters, assembly, site, NOTICE.txt 를 제거하였고, lib과 tools가 추가되었다.

lib이 추가된 이유는 Maven이 종속성 자동 관리 기능이 포함된데 비해 Ant는 직접 필요할 라이브러리를 관리해야 하기 때문이며, tools 는 개발팀 내 함께 쓰는 유용한 도구와 그 설정 정보를 공유하기 위함이다.

빌드 스크립트는 총 3개의 파일로 구성된다. build.xml 은 메인 빌드 스크립트이며, build.properties에는 그 중 사용자 정의 속성을 담아, 상황에 맞게 설정하여 빌드할 수 있게 하였다. 마지막의 build-jazz.xml 은 build.xml을 확장(import)하여 RTC/Jazz에 종속된 기능을 추가로 수행하기 위해 추가하였다. 즉, build-jazz.xml를 제외한 두 파일은 RTC/Jazz와 완전히 독립적이어서 어떤 환경에서건 그대로 재활용할 수 있다.

스크립트의 속 내용은 조금 후에 살펴보기로 하고, 빌드 과정에서 생성되는 디렉터리 레이아웃에 대해서 먼저 살펴보자.

  • target/classes – 제품 소스를 컴파일한 클래스 파일들 & 리소스
  • target/test-classes – 테스트 소스를 컴파일한 클래스 파일들 & 리소스
  • target/reports/unit-test – 단위 테스트 결과 리포트 (XML 포맷)
  • target/reports/unit-test/html – 단위 테스트 결과 리포트 (HTML 포맷)
  • target/reports/integration-test – 통합 테스트 결과 리포트 (XML 포맷)
  • target/reports/integration-test/html – 통합 테스트 결과 리포트 (HTML 포맷)
  • target/reports/findbugs – FindBugs 수행 결과 보고서
  • target/reports/checkstyle – CheckStyle 수행 결과 보고서
  • target – 빌드 산출물 루트 겸, package 된 제품 바이너리 등 최종 산출물

특별한 설명은 필요 없으리라 본다. 그렇다면 이제 Ant 빌드 스크립트의 내용과 빌드 단계에 대해 알아보기로 하자.

Ant Build Script and Build Lifecycle

Ant 빌드 스크립트는 빌드 타깃(target)과 타깃간 종속성(선행 타깃 정의)과 타깃에서 실행해야할 실제 작업을 정의한다. 빌드 라이프사이클 역시 Maven의 그것을 기반으로 간소화한 후 약간 보강하였다. 다음은 build.xml에 정의된 타깃들을 라이프사이클에 따라 설명한 것이다.

  1. compile – 제품 소스 코드를 컴파일한다.
  2. test-compile – 테스트 코드를 컴파일한다.
  3. unit-test – 단위 테스트를 수행한다.
  4. package – 제품 컴파일 결과를 배포 형태로 패키징한다.
  5. integration-test – 통합 테스트를 수행한다.
  6. code-analysis – 정적 코드 분석을 수행한다. (FindBugs, CheckStyle)
  7. deploy – 패키징한 결과를 개발 서버 및 API 서버로 배포한다.

몇 가지만 살펴보겠다.

먼저, code-analysis가 Maven에 없는 새로 추가된 단계이다. 이 단계에서는 FindBugs, CheckStyle 등의 정적 코드 분석 툴을 이용하여 제품 소스 코드의 잠재적 결함과 코딩 규약 부합 여부를 검사한다. code-analysis 단계 외에는, 실패 시 다음 단계를 계속 진행할 수 없다.

unit-test 단계에서는 수행시간이 짧은 단위 테스트들을 실행한다. 통합 테스트 케이스와 시간이 오래 걸리는 테스트 등은 뒷쪽의 integration-test 단계에서 수행시킨다.

마지막 deploy 단계에서는 완성된 바이너리를 개발 서버로, 최신 API 문서를 API 서버로 배포한다.

변경 가능한 사용자 속성으로는 다음과 같은 것들이 있다.

  • product.name  - 제품명
  • product.version – 제품 버전
  • main.class – 실행 클래스명: jar 파일의 Manifest 파일에 추가됨
  • compile.deprecation – javac 컴파일 옵션
  • compile.debug – javac 컴파일 옵션
  • compile.optimize – javac 컴파일 옵션
  • compile.source – javac 컴파일 옵션
  • compile.target – javac 컴파일 옵션
  • proxy.host – 프락시 주소 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • proxy.port – 프락시 포트 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • deploy.binary.host – 패키징된 바이너리를 배포할 호스트 주소
  • deploy.binary.user – 호스트 로그인 계정
  • deploy.binary.passwd – 호스트 로그인 패스워드
  • deploy.binary.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.binary.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로
  • deploy.api.host – 최신 API를 배포할 호스트 주소
  • deploy.api.user – 호스트 로그인 계정
  • deploy.api.passwd – 호스트 로그인 패스워드
  • deploy.api.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.api.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로 (웹 서버 혹은 파일 서버)

보는 바와 같이 소스 코드 디렉터리 구조, 산출물 파일 이름과 같은 정보는 따로 설정할 수 없도록 제안하고 있다. 이유는 초반에 언급한 Maven의 설계 원칙(Convention over Configuration)을 좀 더 강요하기 위함이다.

물론 build.xml의 내용을 보면 관련 정보를 속성으로 제공하여, 꼭 필요한 경우 쉽게 변경할 수 있다.

마지막으로 build-jazz.xml 파일을 살펴보자.

이 파일은 build.xml 을 확장하여 RTC/Jazz 빌드 서버에서 사용할 특화 타깃을 정의하고 있다. RTC/Jazz 빌드 기능에 특화된 만큼, 이 스크립트를 개발자 IDE에서 실행하려 하면 필요한 파일이 없다면서 에러를 발생시킬 것이다. 물론 몇 가지 설치/설정으로 가능케할 수 있지만, 별다른 이점은 없으니 Jazz 빌드 서버에 맡기기로 하자.

기본적으로는 다음의 네 가지 타깃이 제공된다.

  • package-jazz – build.xml의 package 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 단위 테스트 보고서와 패키징된 바이너리가 이에 포함된다.
  • integration-test-jazz – build.xml의 integration-test 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 통합 테스트 결과가 추가된다.
  • code-analysis-jazz – build.xml의 code-analysis 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 정적 코드 분석 보고서가 차가된다.
  • deploy-jazz – 최종 단계인 deploy까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다.

특별히 위와 같은 네 단계만 정의한 이유는 잠시 후 Build Definitions 절에서 확인할 수 있다. 그 전에 정적 코드 분석(static code analysis) 단계에서 무엇을 하는지 살짝 알아보고 가기로 하자.

Static Code Analysis

앞서 살펴본바와 같이, unit-test와 package 단계 사이에 code-analysis 라는 단계가 추가되었다. 이는 Maven에도 정의되어 있지 않은 단계이다. 이 단계에서는 제품의 소스 코드를 분석하여 잠재적인 결함과, 코딩 규약 준수 여부를 확인한다.

쉽게 활용할 수 있는 오픈 소스 툴들로는 FindBugs와 CheckStyle, PMD 등이 있다. (기능면에서 CodePro Analytix가 가장 마음에 드나, 아쉽게도 Ant용 task를 제공하지 않아 여기서는 제외하였다.)

FindBugs는 버그 패턴 위주로 거의 100% 적중률로 문제를 분석해주며, CheckStyle과 PMD는 그 외에도 코딩 규약, 유사 코드 검색 등 다양한 기능을 제공한다. CheckStyle과 PMD 는 기능면에서 상당히 겹치기 때무에 둘 다 사용할 필요는 없다. 나는 PMD를 더 선호하였지만, 최근에 업그레이드가 이루어지지 않고 있어 CheckStyle로 선회하였다.

참고로, 이들 툴을 지속적 통합 프로세스의 일부로 등록해놓는 것은 좋은 생각이긴 하지만 IDE에 통합하여 개발자들이 수시로 확인해보는 것에 비할 바가 못된다. 다행히 CodePro Analytix를 포함하여 위의 모든 툴들은 Eclipse 플러그인을 제공하고 있다.

관련하여 Java 코딩 규약 관리 방법 역시 참고가 될 것이다.

Build Definitions

빌드 정의(Build Definition)는 빌드에 필요한 각종 정보와 수행 조건 등을 담는다. 예를 들어, 빌드에 사용할 파일(build-jazz.xml)명, 타깃, 빌드 스케줄 등이 그것으로, 프로젝트 특성에 맞는 다양한 전략을 수립할 수 있다. 상세 내용은 본 글의 주제와 크게 관련 없으니  지나치도록 하겠다.

어쨌든 Jazz의 빌드 서버는 이 정의를 바탕으로 빌드 엔진에 빌드를 요청한다. 아래의 그림은 내가 구축하기 원하는 빌드 전략이다.

schedule

그리고 위의 전략을 구현하기 위해 다음과 같은 네 가지의 빌드 정의를 작성하였다.

  1. Continuous: 변경 사항에 대한 빠른 피드백을 목적으로, 컴파일/단위 테스트/패키징 성공 여부까지 확인한다.
    1. 빌드 주기: 매 5분
    2. 빌드 타깃: package-jazz
  2. Integration: 더 많은 시간이 소요되며 다양한 테스트를 수행하는 통합 테스트까지 수행한다.
    1. 빌드 주기: 매 1시간
    2. 빌드 타깃: integration-test-jazz
  3. Nightly: 일별 snapshot을 만들어, 매일 아침 baseline을 생성한다.
    1. 빌드 주기: 월~토요일 3:00 AM
    2. 빌드 타깃: code-analysis-jazz
  4. Weekly: 주간 변경 내용을 종합 검증하여 baseline을 생성하고, 개발 서버에 배포한다.
    1. 빌드 주기: 매주 일요일 3:00 AM
    2. 빌드 타깃: deploy-jazz

Jazz 빌드 서버는 위의 네 가지 빌드 정의에 기반해, 자동으로 빌드/테스트/배포를 수행하며, 그 결과를 개발자에게 알려주게 된다.

Summary

이상으로 빌드 시스템의 거시적인 구성부터 빌드 단계 정의, 빌드 정의를 통한 지속적 빌드 전략 수립까지 구성해 보았다.

다소 이론적인 면에 집중하여 설명하였지만, 상세 내용으로 들어가면 내용이 너무 길고 장황해지니 양해 바란다.

(관련 Ant 빌드 스크립트는 약간 다듬어서 추후 업데이트하겠음)

Applying Rational Team Concert (적용 일지)
Mar 15th, 2010 by Wegra Lee

새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].

최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.

그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.

  • MBO 관리
    • 그룹장의 MBO 에서 각 사원의 세부 task 까지 한 눈에 확인 가능.
    • 자신이 하고 있는 일이 팀의 어떤 목표와 관련되어 있는지 항시 인지할 수 있다.
  • 주간 보고 (Weekly Meeting)
    • Scrum 의 Sprint 주기를 1주로 하면 현행 주간 보고 시스템과 차이가 최소화된다.
    • 현 시스템을 대체하는 것으로 시작해 진입 장벽을 낮추고, 차차 개선시킨다.
    • 현 주간 보고 방식에 비해 context-awareness 가 월등히 높다.
  • 일일 작업 관리 (개발자 관점)
    • 개발자 관점에서 매일매일 자신의 task 를 효율적으로 관리하는 방법을 보여준다.
  • 일일 작업 관리 (리더 관점)
    • 리더 관점에서 팀의 업무 진행 상황을 빠르게 파악하여, 부하 분산, 우선 순위 조정, 이슈의 빠른 해결 등을 도와주는 방법을 보여준다.
  • 실시간 리포팅 (Work Load, Progress, Risk, Open Issues and Defects, ..)
    • 팀원과 리더뿐 아니라  모든 stake holder 들이 별도의 보고 요청 없이 실시간으로 과제의 진행사항을 파악할 수 있는 방법을 다룬다.
  • Review & Planning & Retrospective
    • RTC 활용으로 정보 공유가 원활해지므로, weekly meeting 을 현행 주단위 업무 보고 성격에서 스크럼 형태의 효율적 회의로 변화시킨다.
    • 이 과정에서 회고 (retrospective) 의 중요성을 강조한다.
  • 요구사항부터 구체적 기능 태스크, 구현, 빌드, 검증까지..
    • 태스크와 그 구현에 따른 코드 변경, 빌드, 테스트, 결함 등록, 수정 완료 에 이르는 과정을 데모를 통해 보여준다.

기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.


References

  1. IBM Rational Team Concert (jazz.net)
  2. Choose Right Tools for Efficient Collaboration (wegra.org)
Google Wave and RTC/Jazz
Oct 4th, 2009 by Wegra Lee

RTC/Jazz 를 사용하면서 아쉬웠던 것 몇 가지를 뽑자면, 어설픈 통합 메신저와 텍스트 위주의 빈약한 편집 기능이었다.

Lotus Sametime 등 별도 외부 메신저를 쓸 수 없는 사람들을 고려해서 자체 메신저를 좀 더 보강해준다면 더 없이 좋을 터인데.. 그쪽은 아직 우선순위가 높지 않은 듯 하다.. 한창 3.0 계획중이니 요구사항을 올려봐야겠다.

편집 역시 Wiki 정도의 풍부한 표현력을 보여준다면 한층 호응도를 높일 수 있을 것이다. Project Plan 등에서 이미 Wiki 를 사용하고 있어서 이를 work item 편집에도 반영해달라는 요청이 몇 번 있었는데, 이러저런 이유로 당시엔 거절했었다.

아무튼.. Google Wave 소개 동영상을 보고 있자니 RTC 의 단점들을 보완해줄 훌륭한 기술들이 확실해 보인다. 문제는 다른 회사이고 아직은 서로 자신들의 일에 집중하느라 벌써부터 협업을 바라기에는 무리이지 싶다.

IBM Rational 도 소셜 개발이라는 측면을 전혀 고려하지 않는 것은 아니다. RTC 3.0 계획에 이미 OpenSocial 연동 등이 item 으로 잡혀 있고, 지난 8월 25일에 있었던 “Working smarter:Enriching the Jazz environment with social software” (mp3, transcript)라는 텔레컨퍼런스에서도 관련 주제로 이야기가 오갔다. IBM 에선 당연하게도 자사 제품인 Lotus Connections 를 1차 대상으로 삼고 있다.

Google Wave 가 어찌될 진 모르겠지만.. Connections 는 아무래도 상용 제품이다보니 RTC/Jazz 와 잘 융합된다해도, 나와같은 사람은 그 혜택을 얼마나 누릴 수 있을지 짐작하기 쉽지 않다. 또한, Connections 는 Blog, Wiki, Profile 등 기존 유명 소셜 기능들을 잘 묶어놓았다는 느낌 정도이지만, Wave 는 혁신을 함께 수반한 훨씬 멋진 제품이 될 것 같다.

결론은.. 오픈 프로젝트를 하는 사람들이 참 부럽다. 좋은 툴들은 부담없이 사용해볼 수 있고, 접목할 수 있으니.. 나처럼 손가락만 빨고 있을 필요는 없지 않은가. ^^

Rational Team Concert 2.0.0.1
Sep 23rd, 2009 by Wegra Lee

드디어 RTC 2.0.0.1 이 릴리스되었다.

버전 넘버로만 봐서는 아주 작은 변화이지만, 여타 소프트웨어의 0.0.0.1 변화와는 차원이 다른 진보를 보여준다(New and Noteworthy). 기능적인 변화들도 물론 훌륭하지만, 그 중 내 눈에 가장 들어오는 것은 바로 라이선스 정책의 변화이다.

기업에 이를 적용하려 시도할 때 가장 큰 걸림돌이 바로 라이선스 비용이었다. 심지어 이것 때문에 툴이 얼마나 유용한가 테스트(trial)도 안해볼 정도로 보수적이다. 아래는 이번 릴리스에서 완전 공짜 버전인 Express-C 를 사용할 경우의 라이선스이다.

  1. Completely FREE
  2. Includes 10 free Developer licenses
  3. Contributers can do everything except for Source Control and Build.
  4. The number of Contributer licenses is unlimited.
  5. Provides full support for advanced DB options like DB2, SQL Server, Oracle 10g.

위 조건이면 소규모 개발팀에서는 프로젝트에 필요한 거의 모든 솔루션이 RTC 하나에 다 묶여 있다는 의미이다. Contributer 라이선스가 무제한이기 때문에, 이를 인터넷에 오픈하면 그대로 고객/개발자간 소통의 장이 된다. 심지어 대규모 개발팀에게도 직접적인 개발을 제외한 기능들이 다 포함되게 된다. 물론 공짜로 말이다.

현 우리 팀에도 다시 한 번 홍보를 해볼 생각이다. 워낙 보수적이고 발등에 떨어진 일 처리에만 급급해서 정말 도입되리란 기대는 많이 않지만 ‘아쉽지~’ 라는 생각은 해볼 수 있게 될 듯.. ^^ 우리 팀에 적용되면 다음과 같은 일들을 처리할 수 있다.

  • 개발툴(Eclipse/VS)과 통합된 환경 제공
    • IDE를 안쓰는 사람들은 Web Interface
  • Project Planning
  • Resource management
  • Work Item, Issue management
  • Defect Tracking
  • Continuous Integration
  • Reporting
  • (마음만 먹으면) 고객 대응 사이트

물론 위에 나열한 모든 항목들 각각이 지금 우리 팀에서 사용하고 있는 것보다 훨씬 효율적이고, 서로 유기적으로 연동되어 있다.

Ref: Rational Team Concert 2.0.0.1 released!

WolfPoker: planning poker for the Jazz
Sep 22nd, 2009 by Wegra Lee

WolfPoker 라는 RTC/Jazz 용 Planning Poker 플러그인을 소개해본다.

아직 개발 단계이고, 또 1.x 대 버전만 지원하고 있어서 직접 테스트는 해보지 않았지만 재미있을 듯 하다. 직접 마주 앉아 게임을 진행하는 것이 의사소통면에서 훨씬 빠르고 효율적이므로, 위 플러그인은 아무래도 개발자들이 물리적으로 떨어져 있는 상황이 아니면 크게 활용되진 않을 것 같다. ^^

  • Create planning poker sessions ahead of time for your team.
  • Add or remove Jazz Work Items to a given session for voting.
  • The session is coordinated by a single person, but any member of the session can vote and see each other’s votes.
  • Team members can come and go without disrupting the session.
Heterogeneous development with Rational Team Concert
Sep 9th, 2009 by Wegra Lee

서로 다른 개발 환경을 사용하는 프로젝트에서 Jazz/RTC 로 협업 과정을 보여주는 데모이다. 총 3편으로 구성되어 있고.. 어렵진 않지만, 이해를 돕기 위해 약간 설명해보면 이렇다. (영어에 거부감이 없다면 여기의 설명을 읽는 것이 훨씬 이해가 빠를 것이다. ^^)

등장 인물
Build Master – 전체 통합 빌드를 관장한다. RTC 는 전용 클라이언트 없이 Web 인터페이스만으로 사용한다.
Cindy Sharp – 클라이언트 개발자로 C# (Cindy # ^^) 을 사용한다. 개발/RTC 환경은 Visual Studio 2008 + RTC Plugin for Visual Studio 을 이다.
Jerry Java – 서버 개발자로, Java 를 사용한다. 개발환경은 RTC Eclipse 클라이언트이다.

시나리오
빌드 마스터가 최신 빌드에서 문제를 발견하고 단말 개발자인 Cindy 에게 결함을 할당한다. Cindy는 결함 재현을 위해 해당 빌드로부터 workspace 를 생성하고 분석 후, 원인이 서버에 있다고 판단하여 Jerry 에게 재할당한다. Jerry 는 결함해결하고, 빌드 마스터/Cindy 와 함께 검증 후 결함을 close 한다.

Rational Team Concert™ ROI calculator
Aug 27th, 2009 by Wegra Lee

IBM 에서 재미난 사이트를 오픈했다. Rational Team Concert eKit 이라고.. 그 중 ROI Calculator 라는 것이 있길래 재미삼아 우리 과제를 한 번 시뮬레이션 해봤다.

과제 규모를 넓게 보고 입력값은 아래처럼 정했다.

RTC ROI Calculator Input Data

그리고 이것이 그 결과다.

RTC ROI Calculator Result

9개월이면 투자비를 뽑을 수 있고, 첫 해에 약 백만 달러, 3년이면 천만 달러의 이득을 얻는단다. 수백명의 인건비를 생각해보면 예상보다 결코 큰 액수가 아니라 실망스러운데.. 아무래도 너무 허황된 꿈을 제시하지는 않으려고 나름 신경쓴게 아닐까 싶기도. ^^ 그래도 절대치로 봤을 때는 역시 무시하기 어려운 수치인 것 같다.

어차피 재미로 해본 것이고, 운영을 얼마나 잘 하느냐에 따라 천차만별일 것이니 큰 의미는 두지 않는다.

Ref #1: Rational Team Concert eKit
Ref #2: RTC ROI Calculator

Little about Jazz and Rational Team Concert
Aug 21st, 2009 by Wegra Lee

감명깊게 사용중인 Jazz/RTC 에 대해 한글 번역해본 글들이다. Planning, task management, source control, continuous build, issue tracking, IDE 등 소프트웨어 개발 프로젝트 전반에 걸쳐 요구되는 대부분의 기능을 한 대 묶어 놓은 혁신적인 툴이다. 개인 개발자를 넘어, 팀 생산성을 극대화시킬 수 있다. 도입을 고려하거나 초보 사용자들에게 큰 도움이 되길 기대해본다.

Here are some articles, translated into Korean, about the Jazz and Rational Team Concert. Visit the jazz.net for more details.

  • RTC versus Jira/SVN/CruiseControl (Click Here)
  • Using the My Work view in Rational Team Concert 2.0 (Click Here)
  • Progress Bars, Load Bars, and the importance of estimating your work in Rational Team Concert 2.0 (Click Here)

번역물은 아니지만 이 글도 RTC 의 작지만 강력한 장점을 잘 보여준다.

»  Substance: WordPress   »  Style: Ahren Ahimsa