사람을 위한 자동화: 지속적인 피드백 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 샘플 코드 영어원문  제안 및 의견 피드백

난이도 : 초급

Paul Duvall, CTO, Stelligent Incorporated

2007 년 6 월 19 일

피드백은 Continuous Integration (CI)에 있어서 필수적인 것입니다. 사실 CI 시스템의 혈액이라고 할 수 있습니다. 신속한 피드백은 신속한 대응을 하게 해주어 관심이 필요한 이벤트를 구현하게 됩니다. 이메일이나 RSS 같은 피드백 장치가 없다면 실패한 빌드는 그대로 실패한 채로 남겨지며, 이는 CI의 목적과는 처음부터 어긋나는 일입니다. 사람을 위한 자동화 시리즈에서는 CI 시스템에 적용할 수 있는 다양한 피드백 장치에 대해 설명합니다.

아직 CI를 사용해보지 않은 기술자들에게 CI를 설명할 때, 필자는 주요 장점에 초점을 맞춰 설명하곤 한다. 결함이 생기고 픽스 되는 기간이 줄어든다는 것을 강조한다. 빌드 상태에 대한 신속한 피드백을 제공하는 것이 CI 서버의 기능의 직접적인 효과라 할 수 있다. 빌드 이벤트에 대한 신속한 피드백은 CI의 중심 개념이고, 지속적인 피드백(continuous feedback) 장치는 CI 시스템을 대변하기도 한다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

빌드가 실패하면, 이것이 컴파일 에러든, 테스트 오류든, 아니면 총체적인 복잡성의 증가든, 이를 픽스하기 위해 적절한 액션을 즉각적으로 취해야 한다. 더욱 빨리 알게 될수록 문제를 픽스할 수 있는 더 많은 관련 정보들과 더 나은 기회들을 갖게 된다.

하지만 피드백은 액션이 없다면 소용없다. CI의 경우, 실패한 빌드가 모든 사람들에게 영향을 미치기 때문에 즉각적인 액션이 필요하다. 따라서, CI 서버에서 채택된 피드백 장치는 시기를 잘 맞춰야 한다. 오늘날의 CI 서버들은 이메일 피드백 장치를 제공한다. 하지만, Really Simple Syndication (RSS) 피드부터 SMS 텍스트 메시지, X10 장치들에 이르기까지 다양한 미디어를 선택할 수 있다. 이렇게 다양한 피드백 장치를 통해 사람들은 적절한 액션을 바로 취할 수 있는 것이다.

시리즈 소개 개발자로서, 사용자를 위해 프로세스를 자동화 하고 있습니다. 하지만, 정작 우리들 자신의 개발 프로세스를 자동화 할 수 있는 기회를 간과하고 있습니다. 따라서, 사람을 위한 자동화 시리즈에서는 소프트웨어 개발 프로세스를 자동화 하는 방법을 연구하고, 자동화를 적용할 시기와 방법을 설명합니다.

Execution a la e-mail

이메일은 단순하고 유용한 피드백 수단이라고 할 수 있다. 필자가 알고 있는 모든 CI 서버는 일정한 유형의 이메일 피드백 장치를 제공한다. 사실, 대부분의 CI 서버들은 원하는 빌드 이벤트에 따라 누가 어떤 메시지를 받는지를 설정하는 기능이 있다. 예를 들어, 기술 리더가 빌드 상태와 관계 없이 이메일을 받지만, 프로젝트 매니저는 빌드가 실패했을 때에만 이메일을 받는다. 게다가 개발자 또는 CM 시스템에 대한 코드를 검사하는(그리고 CI 빌드를 실행하는) 개발자들은 빌드의 상태를 나타내는 이메일을 받는다.

Listing 1은 CruiseControl 메인 설정 파일(config.xml)의 예제이다. 빌드의 성공과 실패에 대해 프로젝트의 빌드 마스터("build master")에게 HTML 포맷으로 된 이메일을 보내도록 설정되어 있다.

<publishers>
  <htmlemail
    mailhost="localhost" 
    defaultsuffix="localhost"
    username="bfranklin"
    password="G0Fly@Kite"
    returnname="Buildmaster"
    returnaddress="buildmaster@localhost"
    subjectprefix="[CC]"
    xsldir="webapps/cruisecontrol/xsl"
    css="webapps/cruisecontrol/css/cruisecontrol.css">
    <always address="buildmaster@localhost"/>
  </htmlemail>
<publishers>

또한, CruiseControl의 이메일 태스크의 defaultsuffix 애트리뷰트를 사용하여 개발자에게 이메일을 보낼 수 있다.

그림 1은 Listing 1의 설정에 기반하여 사용자게 받게 될 이메일 예제이다.

이메일은 CI를 사용하는 프로젝트에 있어서 사실상 표준 피드백 장치이지만, 팀 멤버들이 너무 많은 이메일이 답지된다면 이러한 메일들을 무시하게 될 것이고, 이는 피드백 장치의 목표를 처음부터 좌절시키는 행위가 된다. 코드 베이스에 생긴 가장 최근의 변경 사항을 수행했던 개발자에게만 이메일을 보낸다거나 매일 빌드 상태 이메일을 받는 것을 개의치 않는 프로젝트 리더에게만 이메일을 보내도록 CI 시스템을 설정하는 것이 더욱 생산적이라는 것을 깨달았다.

Continuous Integration이란 무엇인가? Continuous Integration (CI)은 팀이 피드백을 받고, 개발 사이클에서 오류를 탐지하여 픽스할 때를 기다리지 않고 지속적으로(continual basis) 향상 시키는 방식이라고 할 수 있다. (CruiseControl 같은) 툴은 백그라운드에서 실행되어 버전 관리 저장소로 폴링(poll)하여 변경 사항을 찾는다. 변경 사항이 발생하면, 이 툴은 Ant를 통해서 사전 정의된 빌드 스크립트를 실행한다. Continuous Inspection은 Continuous Integration 방식에서 활용되고 있다.

구원자, RSS

RSS는 소극적이기도 하고 적극적이기도 한 피드백 폼이다. 이메일 메시지의 양이 줄어든다는 점에서 매력적인 피드백 장치이라고 할 수 있다. RSS 피드는 (표준에 순응하는) XML 파일로서 특정 이벤트에 기반하여 업데이트 된다. RSS 리더기(reader)는 변경 사항을 골라내고 새로운 콘텐트를 가리키는 수동적인(passive) 메시지를 만들어 낸다. 따라서, 여러분이 많은 이메일을 받고 싶지 않다면 이러한 방식을 사용해 보는 것도 좋을 것 같다.

CI 시스템 내에서, RSS 피드는 최신 빌드 상태에 기반하여 업데이트 될 수 있다. 예를 들어, 그림 2는 빌드 이벤트와 관련하여 생성된 CruiseControl RSS XML 예제이다.

이 피드에 대한 간단한 RSS 리더기를 지목하고 새로운 빌드 이벤트가 발생하면 RSS 피드가 업데이트 되고, 여러분은 이에 대한 공지를 받는다. 그림 3은 RSS 리더기에 디스플레이 된 RSS 피드 모습이다.

위로

SMS 사용하기

자신의 컴퓨터에서 멀리 떨어져 있는 상태에서 빌드가 실패한다면 어떻게 하겠는가? 성공적인 통합 빌드가 여러분 프로젝트의 최고의 가치라고 믿는다면, 언제 어디에서라도 빌드 상태에 대해 알아야 한다. 지속적으로 빌드 상태를 파악할 수 있는 한 가지 방법은 짧은 텍스트 메시지를 모바일 폰으로 보내는 Short Message Service (SMS)를 사용하는 것이다.

다행히도, 이메일을 보내는데 사용되는 같은 메커니즘이 SMS 텍스트 메시지를 보내는데도 사용될 수 있다. 예를 들어, Listing 2는 CruiseControl 이메일 태스크를 사용하여 SMS 메시지를 보내는 예제이다.

<publishers>
  <email mailhost="localhost" 
    returnaddress="buildmaster@localhost"
    returnname="Buildmaster"
    reportsuccess="fixes"
    subjectprefix="brewery"
    buildresultsurl="">
  <failure address="7035551212@vtext.com"/>
  </email>
</publishers>

너무나 많은 피드백 장치? CI를 사용할 때, 실패한 빌드는 많이 발생할 것이고, 통합 빌드가 성공하기 전까지는 다음 태스크로 이동할 수 없다. 따라서, 컴퓨터를 자주 사용하지 않은 사람들에게는 SMS, 빌드의 상태를 한눈에 알 수 있도록 해주는 X10 장치 같이 다양한 목적에 맞게 메커니즘을 선택하는 것이 좋다. 하나의 프로젝트에 필자가 이곳에서 설명한 모든 메커니즘을 다 사용하는 것은 비효율적이다. 자신의 프로젝트에 맞는 것 하나를 선택하는 것이 최상의 방법이다.

Listing 2에서 빌드가 실패했을 때에만 텍스트 메시지를 받는 방식으로 이메일 태스크를 설정했다. 이는 SMS 메시지를 줄일 수 있는 효과적인 방법이다. 더욱이 e-mail 태스크의 reportsuccess="fixes" 애트리뷰트는 빌드가 픽스되었을 때 후속 텍스트 메시지를 받게 된다는 것을 나타낸다.

그림 4는 빌드가 실패했을 때 CruiseControl 서버가 보낸 메시지 예제 모습이다.

SMS를 사용하여 텍스트 메시지를 보내는 것은 급박한 빌드 상태 메시지에 대한 효과적인 피드백 폼이 될 수 있다. 일반적으로, 빌드가 발생할 때마다 텍스트 메시지를 보내는 것은 좋지 않다. (특히, 유료 메시지인 경우). 다시 한번 말하지만, 너무나 많은 정보는 피드백의 효과를 줄이는 "소음"이 될 수 있다. 현명하게 선택하라.

위로

X10 사용하기

이메일도 좋고, 여러분이 사무실 밖에 나와있을 때에는 SMS가 편리하지만, 빌드의 상태를 한눈에 파악할 수 있는 것이 필요하다면? 다행히도, X10 장치도 CI 시스템과 연결되어 피드백 폼의 역할을 한다. X10 장치를 사용하여 X10 프로토콜을 통해 조작될 수 있는 특별한 하드웨어를 사용하여 대부분의 전기 장치를 제어할 수 있다. 빛(light) 같은 일상 생활 장치들이 빌드 실패에 대한 공지를 보낼 때 사용될 수 있다는 것을 의미한다.

예를 들어, Listing 3은 X10 장치를 CruiseControl의 퍼블리셔 메커니즘에 연결하는데 필요한 코드 예제이다. 이 예제에서는 빌드가 실패할 때 빨간 경고등을 켜게 되어있다. 이 조명은 X10 컨트롤러와 연결된다. (여러 상용 "X10 kits" 장치들도 있다.) CruiseControl에는 Java™ COMM API가 있어, CruiseControl의 config.xml을 사용하여 장치와 통신할 수 있고 켜고 글 수 있다. X10 컨트롤러는 빌드 머신 상의 통신 포트에 연결된다. port 애트리뷰트는 여러분이 사용하고 있는 통신 포트를 나타낸다. houseCode와 deviceCode 애트리뷰트는 장치용 X10 컨트롤러에 설정한 글자와 숫자를 가리킨다. onWhenBroken 애트리뷰트는 빌드가 실패할 때 장치가 켜진다는 것을 나타내고 있다. (빌드 성공 시 꺼진다.) 마지막으로, interfaceModel 애트리뷰트는 X10 컴퓨터 인터페이스를 가리킨다. 기본은 CM11A이다.

<publishers>
  <x10 port="COM1" houseCode="A"  
  deviceCode="3" onWhenBroken="true" interfaceModel="CM17A"/> 
</publishers>

퍼블리셔를 사용할 때, 그림 5에서 보이는 것과 같은 장치는 빌드가 실패할 때 켜진다.

LavaLamps, 사이렌 등 다양한 X10 장치들이 있다. 이러한 장치들을 사용하면 빌드 상태를 확실히 알 수 있다.

위로

모니터와 IM

피드백을 즉각적으로 받고 싶다면 클라이언트 모니터와 인스턴트 메시징을 봐야 한다. 클라이언트 모니터는 언제나 백그라운드에서 실행되는 애플리케이션이고 최신 빌드 상태를 빌드 서버에 주기적으로 알려준다. 물론, 누구나 인스턴트 메시징에 대해 알고 있고, AIM부터 Yahoo와 MSN에 이르기까지, 대중적인 플랫폼 호스트를 이러한 용도에 사용할 수 있다.

모니터를 이용한 상태 감시

CruiseControl.NET (.NET 플랫폼용 Continuous Integration 서버)은 CruiseControl.NET과 전통적인 Java built CruiseControl에서 작동하고 Windows 태스크바에서 실행되는(Windows 머신에서만 작동함) CCTray라고 하는 모니터링 메커니즘을 제공한다. CCTray의 작동 예제는 그림 6을 참조하라.

비 Windows 머신과 Apache Continuum 같은 기타 CI 서버에서 Nag라고 하는 클라이언트 모니터를 사용할 수 있다.

IM을 이용한 즉각적인 피드백

인스턴트 메시지(IM)을 사용하여 프로젝트 멤버들에게 빌드의 상태를 공지할 수 있다. 모니터를 사용하는 것과 마찬가지로 이것은 피드백을 신속하게 받는 또 다른 방법이다.

Apache Continuum 같은 CI 서버들은 빌드 상태와 관련한 IM을 보내는 단순한 방식을 갖고 있다. 예를 들어, 그림 7은 Continuum로부터 나온 실패한 빌드 메시지를 보여주고 있다. 이는 Jabber를 사용하여 Google Talk 인스턴트 메시지 클라이언트로 보내진다. CruiseControl 역시 메시지를 보내는 Jabber 퍼블리셔가 있다.

모니터와 IM은 빌드 상태 피드백을 보내는 가장 빠른 방법들이고, 개발 팀들이 이러한 메커니즘을 적극 사용하고 있는 것 같다. 이것이 또 다른 방식과 결합한다면, 프로젝트 멤버들이 자신들의 책상에 없을 때에도 공지를 받을 수 있고(이메일 또는 SMS), 이는 매우 효과적인 피드백 형태라고 볼 수 있다.

위로

피드백 장치

지금까지 설명했지만, CI 환경에서 사용할 수 있는 다양한 유형의 피드백 장치들이 있다. 필자가 이 글에서 설명하지 않았던 다른 많은 피드백 장치들(Ambient Orb, 웹 브라우저 플러그인, 사운드, 위젯)도 있다. 표 1에서는 이 글에서 설명한 피드백 장치를 요약해 놓았다. 이 글에서 설명하지 않은 것들도 있다.

다양한 피드백 장치들을 조화롭게 사용하는 것이 가장 효과적이다. 자신에게 잘 맞는 것을 함께 사용하는 것이 좋다.

위로

맺음말!

빌드 피드백의 목적은 신속한 액션을 취해서 팀들이 실패한 빌드를 픽스할 수 있도록 하는 것이다. 일반적으로, 이러한 피드백 장치들을 결합해서 사용해야 한다. 예를 들어, 모든 빌드 이벤트에는 이메일을, 빌드 실패(그리고 후속 조치)에는 SMS를, 시각적 공지에는 X10 장치를 사용한다. 이러한 장치의 사용이 성숙해 질수록 다양성을 추가할 수 있고 사람들은 빌드 상태에 대해 보다 관심을 갖게 된다. 창의성을 키우고 이를 즐기기 바란다!

위로

다운로드 하십시오

	다운로드 방식에 대한 정보

참고자료

• 사람을 위한 자동화 (Paul Duvall, 한국 developerWorks): 시리즈 완전정복.
  
  
• "Bubble, Bubble, Build's In Trouble": Mike Clark(Pragmatic Project Automation의 저자)가 CruiseControl용 X10 장치 구성법을 설명한다.
  
  
• "Jabber" (Gerhard Poul, developerWorks, 2002년 5월)
  
  
• "eXtreme Feedback for Software Development" (Alberto Savoia, DeveloperTesting, 2004년 4월): Continuous Feedback Mechanisms의 기타 예제들과 eXtreme Feeback Devices.
  
  
• "Pragmatic Automation": Mike Clark(Pragmatic Project Automation의 저자).
  
  
• "Continuous Integration" (Martin Fowler, martinfowler.com, 2006년 5월).
  
  
• "Configuring Continuum for CI" (Testearly.com): Continuum의 기본 설정과 구성.
  
  
• Ambient Orb Ant task example (Testearly.com): Ambient Orb Ant 태스크 사용 예제.
  
  
• 자바 존: 다양한 자바 프로그래밍 관련 리소스 제공.
  
  

• CruiseControl: Continuous Integration용 오픈 소스 서버.
  
  
• 4-Pack Firecracker Automation System: X10 장치용 인터페이스 설정.
  
  
• Nag: Continuous Integration 모니터.
  
  
• Yahoo! Widgets: 데스크탑으로 피드백을 보내는 CruiseControl 위젯.
  
  
• Ambient Orb Ant task: 빌드 상태에 따라 Ambient Orb 색깔을 바꾸는 오픈 소스 Ant 태스크.
  
  

• 자바 포럼

필자소개

		Paul Duvall은 Stelligent Incorporated의 CTO이다.UML™ 2 Toolkit Toolkit을 공동 집필했으며 곧 출간될 Addison-Wesley Signature Series, Continuous Integration: Improving Software Quality and Reducing Risk의 공동 저자이다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로