 | |
|
난이도 : 중급 Paul Duvall, CTO, Stelligent Incorporated
2008 년 1 월 08 일 Continuous Integration (CI)가 프로젝트의 위험 요소를 줄이는 데는 매우 효과적이지만, 매일 매일의 코딩에 대해서는 큰 중요성을 두고 있습니다.
사람을 위한 자동화
시리즈에서는, 자동화 전문가이자,
Continuous
Integration: Improving Software Quality and Reducing Risk
의 공동 저자인 Paul Duvall이 CI 반패턴(anti-pattern)을 설명하고, 이를 피하는 방법을 설명합니다.
잘 되는 것 보다는 특정 상황에서 잘 되지 않는 것을 알아냄으로써 더 많은 것을 배우게 되는 경우가 있다. 예를 들어, 초기에는 소프트웨어를 빠르게 릴리스 하고자 하는 마음에, 단위 테스팅을 건너 뛰었다. 그러한 노력에는 돈을 들일 가치가 없다고 생각했기 때문이었다. 다행히도(?), 테스트 되지 않은 코드를 실행했더니 잘 되지 않았다; 결국, 필자는 단위 테스트를 작성하기로 마음먹었다.
어쩌면, 업계도 대체적으로 필자의 스타일을 지지하는 것 같다. 이렇게, 특정 정황 속에서 작동하지 않는 현상을 한 단어로 반패턴(anti-patterns)이라고 한다. 반패턴은 유용한 것처럼 보이는 솔루션이지만, 결국 반대의 효과를 만들어 내기도 한다.
진짜인 것처럼 보이는 잘못된 증거
슬프게도, 숙련되지 않은 팀들이 CI를 적용한다면, 많은 반패턴들을 실수로 도입할 수 있는 많은 가능성에 노출되고, 이는 결국 많은 좌절감을 가져오게 된다. CI라는 용어 자체도 부정적으로 사용되어, 필자는 "CI가 큰 프로젝트에는 맞지 않는다." 또는 "우리의 프로젝트는 너무 독특해서, CI가 효과를 발휘하지 않는다." 같은 말을 듣게 된다. 사실, CI의 문제는 아니다. 진정한 문제는 여러분을 좌절하게 만들었던 비효율적인 적용 또는 프랙티스의 부재 때문이다.
|
시리즈 소개
개발자로서, 사용자를 위해 프로세스를 자동화 하고 있습니다. 하지만, 정작 우리들 자신의 개발 프로세스를 자동화 할 수 있는 기회를 간과하고 있습니다. 따라서,
사람을 위한 자동화
시리즈에서는 소프트웨어 개발 프로세스를 자동화 하는 방법을 연구하고, 자동화를 적용할 시기와 방법을 설명합니다. |
|
이 글에서 필자는 CI의 관점에서 여섯 가지 반패턴을 상세히 설명하겠다:
-
빈번하지 않은 체크는 통합을 지연시킨다.
-
깨진 빌드는 팀이 다른 태스크로 이동할 수 없게 한다.
-
최소한의 피드백으로는 어떤 액션도 취할 수 없다.
-
스팸 피드백을 받으면 사람들은 메시지 자체를 무시하게 된다.
-
느린 머신을 사용하면 피드백이 지연된다.
-
팽창된 빌드에 의존하면 신속한 피드백을 받을 수 없다.
여러분이 CI를 오랫동안 수행해 보았다면, 이러한 반패턴의 결과를 곧 경험하게 될 것이다. 이러한 일이 너무 빈번하게 발생한다면, CI의 많은 혜택들이 제한된다. 따라서, 이러한 반패턴의 발생과 부정적인 영향을 줄이고 싶다면, 이 글을 주의 깊게 읽어보기 바란다.
빈번하지 않은 체크로 인해 지연된 통합
제목: 빈번하지 않은 검사
반패턴: 소스 파일들이 태스킹에 필요한 변화량 때문에 오랜 기간 동안 저장소에서 체크가 된 상태가 된다.
솔루션: 더 작은 코드 청크를 자주 실행한다.
CI가 약속하는 것은 개발 중에 팀들이 코드의 상태에 대한 신속한 피드백을 받을 수 있다는 것이다. 더욱이, 이러한 잦은 소프트웨어 통합 스타일은 보다 전통적인 늦은(late) 스타일의 "빅뱅" 통합 노력에 드는 시간을 줄인다. 하지만, 효과적인 CI는 변경 사항들이 주기적으로 발생한다는 개념에서 예견된다. 코드가 오랜 간격 동안 데스크탑에서 살아있다면(저장소와는 반대됨), 다른 변경 사항들이 시스템의 다른 부분들에 발생하기 때문에 좋지 않은 일이 발생할 것이다.
|
통합과 관련한 팁
제 1의 규칙은 적어도 하루에 한번 코드에 검사하는 것이다. 필자가 사용하는 효과적인 기술은 다음과 같다. 휴식이 필요하다고 느끼면, 필자가 로컬 빌드를 실행할 수 있고, 코드를 실행할 수 있는 상태에 있는지를 먼저 확인한다. 그런 다음 휴식을 취한다. |
|
중요한 것은 빈번하게 변화를 주지 않음으로써, 통합을 지연시키게 되고, 그러한 지연이 길어질수록, 반대의 효과를 걸러내는데(예를 들어, 여러분의 코드에 영향을 끼치는 다른 사람들의 변경 사항) 더 많은 노력이 필요하다. CI를 사용하는 프로젝트에서, 필자는 개발자들에게 적어도 하루에 한번 코드를 실행할 것을 권장하고 있지만, 하루에 여러 번 코드를 체크하는 것이 최상이다.
더 작은 태스킹으로 삶을 더욱 윤택하게
많은 개발자들은 너무나 많은 파일들을 수정하느라 바쁜데 코드를 매일 검사하는 것은 어려운 일이라고 불평한다. 바로 이러한 이유 때문에 매일 소스 수정을 해야 하는 것이고, 작게 생각해야 하는 것이다. 사실, 코딩 태스크를 작은 작업 조각으로 나누어서 변경 사항이 작도록 해야 한다.
read(), write(), update(), delete()를 코딩하는 것 같은 노력으로 비즈니스에 모든 기능들을 구현하는 것보다, 먼저 read() 메소드(그리고 이에 상응하는 테스트)를 코딩한 다음, 클래스를 검사하고, 이러한 방식으로 전체 코드 베이스가 통합된다. 그런 다음, 또 다른 메소드를 구현하고, 전체 태스크를 마칠 때까지 같은 것을 반복한다. 이러한 방식으로, CI의 효과를 극대화 할 수 있으며, 코드가 어떤 누구의 코드와도 잘 작동한다는 확신을 얻게 된다.
여러분과 여러분의 팀이 많은 CI를 정확하게 수행하더라도, 팀 멤버들이 적어도 하루에 한번 소스 수정을 하지 않는다면, 여러분의 팀이 CI에서 얻을 수 있는 효과는 별로 없다. 종종, 이러한 현상은 CI가 효과적이지 않다는 결론을 이끌어내기도 하는데, 이것은 사실과 다르다.
깨진 빌드는 개발의 흐름을 늦춘다!
제목: 깨진 빌드(Broken Build)
반패턴: 빌드가 오랜 시간 동안 깨진 상태로 되어 있으며, 개발자는 코드를 검사할 수 없다.
솔루션: 개발자는 빌드 깨짐에 대해 즉각적으로 공지를 받아야 하며, 깨진 빌드를 픽스하는 것을 최우선 순위로 두어야 한다.
믿거나 말거나, 빌드를 깨진 상태에서 오랫동안 방치할수록 픽스는 더욱 어려워진다. 더 많은 파일, 더 많은 변경 사항, 결함의 고립을 어렵게 만드는 더 많은 종속물들 때문이다. 따라서, 누군가가 빌드가 깨진 것에 대해 공지를 받으면(이메일, RSS 등), 이것을 픽스하는 것을 최우선으로 두어야 한다. 그렇지 않으면, 빌드가 깨진 상태로 오래 지속될수록(팀은 빈번한 변경 사항을 수행하는 상태), 상황은 수정하기가 더욱 어려워진다.
깨진 빌드가 언제나 나쁜 것만은 아니다. 사실, 소프트웨어와 관련한 문제라면 빠르게 알 수 있다. 깨진 빌드는 빌드가 자주 깨지거나, 깨진 상태로 오랫동안 지속될 때 문제가 된다. 빌드가 깨진 상태에서 그 자리를 떠나서는 안된다.
|
절대로 깨지지 않는 빌드
일부 개발자들이 "빌드는 절대로 깨져서는 안된다!" 라고 말하는 것을 들어본 적 있다. 이것은 좋은 조언이 아니다. 파일을 잃거나 깨진 테스트 같은 일반적인 빌드 에러를 방지해야 하지만, 깨지지 않은 빌드도 여러분에게 무엇인가를 말하고 있는 것이다. 그 빌드는 모든 것을 충분히 수행하고 있는 것이 아닐 수도 있다. (단순히 컴파일과 몇 가지 단위 테스트만 하는 것일 수도 있다.) 필자는 이것을 "Continuous Ignorance"라고 칭하며, 이는 매우 자주 깨지는 빌드보다 더 나쁜 것이다. |
|
개별 빌드로 깨진 빌드를 줄인다.
깨진 빌드를 방지하는 보다 유용한 기술 중 하나는 코드를 저장소에 두기 전에 개별 빌드(private build)를 실행하는 것이다. 개별 빌드를 실행하는 단계는 다음과 같다.
- 저장소에서 코드를 검사한다.
- 코드를 로컬에서 수정한다.
- 저장소에서 업데이트를 하여 다른 개발자들의 변경 사항을 통합한다.
- 로컬 빌드를 실행한다.
- 빌드가 성공하면, 변경 사항을 저장소에 저장한다.
그림 1은 위 단계를 묘사한 것이다. 작업 흐름이 저장소에서 잦은 동기화를 어떻게 강조하는지, 그리고 주기적인 검사를 허용하고 깨진 빌드를 제한하는 방법을 주목하라. 이것이야 말로 일석이조의 효과이다.
그림 1. 개별 빌드를 실행하여 깨진 빌드를 줄이기
소스 코드를 검사하기 전에 개별 빌드를 수행함으로써(물론, 이것 역시도 자주 수행되어야 한다.), 빌드가 깨진 상태로 남아있는 전형적인 에러를 방지할 수 있고, 결국 시간과 두통을 줄이는 지름길이다.
최소한의 피드백으로 액션 지연시키기
제목: 최소한의 피드백
반패턴: 팀들은 팀 멤버들에게 빌드 상태 공지를 보내지 않고, 사람들은 빌드 실패에 대해 알지 못한다.
솔루션: 다양한 피드백 메커니즘을 사용하여 빌드 상태 정보를 연결한다.
CI 시스템을 설정할 때, 팀은 이메일을 받는 것이 스팸을 받는 것과 같다고 결정해 버린다. 따라서, 팀은 "당분간은" 어떤 공지도 받지 않을 것을 결정한다. 하지만, 빌드에서 어떤 피드백도 받지 않는다면 액션을 취할 수 없다. 사실, 피드백은 CI의 가장 중요한 측면 중 하나이다. 또한 효과적인 피드백 역시 중요하다.
빌드 상태 정보를 팀 멤버들에게 알려주는 메커니즘을 확장한다면, 시각 장치 및 음성 장치의 사용이 매우 유용하다. Ambient Orb 같은 장치들은 빌드의 상태를 실시간으로 보여주는데 효과적이다. 예를 들어, 빌드가 실패할 때 Orb는 빨간색으로 바뀌고, 빌드가 성공할 때, Orb는 녹색으로 바뀐다. 더욱이 Orb는 다른 색깔들을 변경함으로써(좋은 것에는 파란색, 나쁜 것에는 노란색), 코드 베이스의 복잡성을 증가 또는 감소시킨다.
창의적인 사고가 흐르게 하라!
Ambient Orb를 설정하는 것은 매우 쉽다. Listing 1은 Quality Lab의 오픈 소스 OrbTask를 사용함으로써, Ant 에서 Ambient Orb를 설정하는 방법이다:
Listing 1. Ambient Orb Ant 태스크 사용하기
<target name="notifyOrb" >
<taskdef classname="org.qualitylabs.ambientorb.ant.OrbTask"
name="orb" classpathref="orb.class.path"/>
<orb query="http://myambient.com:8080/java/my_devices/submitdata.jsp"
deviceId="AAA-9A9-AA9"
colorPass="green"
colorFail="red"
commentFail="Code+Duplication+Threshold+Exceeded" />
</target>
|
Listing 1에서, 태스크는 성공일 때 Orb를 녹색으로, 실패할 때 Orb를 빨간색으로 변하도록 설정된다. 그림 2는 최신 빌드 상태가 성공적이었음을 의미하는 녹색 Orb 모습이다:
그림 2. 성공적인 빌드!
여러분의 팀은 다양한 피드백 메커니즘을 사용하여, 팀 멤버들이 빌드 상태 메시지를 무시하지 않도록 할 수 있다. 더욱이, 이러한 생동감 있는 기술은 CI를 더욱 돋보이게 한다. 또한, 문제가 생겼을 때 공지하기가 쉽다.
기타 공지 메커니즘으로는 다음과 같은 것이 있다:
- RSS 피드
- CCTray (for CruiseControl) 같은 태스크바 모니터
- X10 장치 (LavaLamps)
- Jabber를 통한 인스턴트 메시지.
- 친구나 가족에게서 메시지를 받을 수 없는 사람들을 위한 SMS (Text Messages)
주의 사항: 너무 많은 정보와 너무 적은 정보 사이의 밸런스를 깨야 한다. 피드백 메커니즘은 다양해야 하며 작업 환경에 기반하여 주기적으로 바꿔야 한다. 예를 들어, 같은 장소에 있는 팀들의 경우, 소리를 재생하는 것(예를 들어, 빌드가 실패할 때 휘파람 소리)이 효과적이다. 하지만, 다른 팀들은 Ambient Orb (깊은 생각에 잠겼을 때 당황하지 않아도 된다.)를 선호한다.
스팸 피드백에 대한 냉담한 태도
제목: 스팸 피드백
반패턴: 팀 멤버들에게는 빌드 상태 이메일(성공이든 실패든)이 빠르게 범람하게 되어 메시지를 무시하는 지경에 이른다.
솔루션: 피드백을 간결하게 하여, 사람들이 관련 없는 정보를 받지 않도록 한다.
충분한 피드백을 받지 않는 반패턴과는 반대로, CI 서버가 모든 일을 수행할 때마다 언제나 피드백을 모든 사람들이 받아야 한다고 순진하게 주장하는 팀들도 있다. 너무 많은 피드백이 있다면, 여러분의 팀은 CI 피드백을 스팸으로 간주하게 될 것이다. 그리고 나서, 중요한 것이 발생할 때(예를 들어, 빌드가 실제로 깨지는 현상) 공지를 받지 못하게 된다.
정확한 타겟팅으로 스팸을 방지하기
Listing 2에서, CruiseControl 설정 파일 예제는 이메일 공지를 효과적으로 사용하는 것을 보여주고 있다. 이 경우, 기술 리더는 빌드 성공 또는 실패에 대한 이메일을 언제나 받게 되며, 프로젝트 매니저는 빌드가 실패할 때만 이메일을 받으며, 최근에 저장소에 소스 변경을 수행한 개발자들 역시도 공지를 받게 된다.
Listing 2. CruiseControl을 사용하여 이메일 공지 보내기
<project name="brewery">
...
<publishers>
<htmlemail
css="./webapps/cruisecontrol/css/cruisecontrol.css"
mailhost="localhost"
xsldir="./webapps/cruisecontrol/xsl"
returnaddress="cruisecontrol@localhost"
buildresultsurl="http://localhost:8080"
mailport="25"
defaultsuffix="@localhost" spamwhilebroken="false">
<always address="techlead@localhost"/>
<failure address="pm@localhost" reportWhenFixed="true"/>
</htmlemail>
</publishers>
...
|
피드백이 CI 시스템의 가장 중요한 측면일 경우를 생각해 보자. 비록 이것은 스팩트럼의 반대 쪽이기는 하지만, 최소한의 피드백과 스팸 피드백 사이에는 미세한 라인이 있다. 빌드가 깨질 때, 피드백은 올바른 방식으로 적임자에게 보내져야 하며, 사람들에게 합당한 정보를 제공해야 한다. 빌드가 성공하면, 최근 수정을 한 사람 또는 리더쉽 위치에 있는 사람들에게만 보내도록 한다. 언제나 모든 사람들에게 상태 메시지를 보내면 CI 프로세스의 혜택이 제한되기 마련이다.
느린 머신 때문에 피드백을 지연시키지 말라.
제목: 느린 머신
반패턴: 제한된 리소스를 가진 워크스테이션을 빌드 머신으로 사용하면, 빌드 시간이 길어진다.
솔루션: 빌드 머신은 신속한 빌드를 위해 최적의 디스크 속도, 프로세서, RAM 리소스를 갖고 있다.
수년 전에, 백만 줄 이상 되는 코드를 가진 대형 프로젝트를 수행했다. 컴파일 하는 시간도 두 시간이 넘었다. 통합을 시도하게 되면서, Configuration Management 팀이 이 프로세스를 처리하기를 기다리는 것은 점점 고통스러운 일이 되어갔다. 물론, 빌드가 종종 실패했기 때문에 최상의 케이스 시나리오는 두 시간이었으므로, 이 프로세스는 일반적으로 완성되는데 여러 날이 걸렸다. (고통스러운 일이 아닐 수 없다.) 이렇게 끔찍하게 느린 프로세스로 몇 주가 지난 후에 깨달은 것은, 검사되고 빌드의 결과로 생성되는 모든 파일들을 위한 충분한 디스크 공간이 있는 머신과, 많은 명령어들을 처리할 수 있는 속도를 가진 가장 빠른 프로세서와, 메모리 집약적인 테스트와 기타 프로세스를 실행하는 충분한 RAM을 가진 머신을 구매하면 된다는 것이다.
속도에 대한 필요를 느끼는가?
이러한 신제품을 통해서, 거대한 빌드를 두 시간에서 30분으로 줄일 수 있었다. 따라서, 최신 기계에 투자를 하면, 상당한 시간과 돈을 절약할 수 있고, 궁극적으로 소프트웨어를 보다 빠르게 통합할 수 있다. (문제도 더 빠르게 포착할 수 있다.)
통합 빌드를 수행하는 추가 워크스테이션으로 시작하는 것도 좋다. 하지만, 필자가 말하고 싶은 것은, 속도나 메모리를 늦추는 빌드 머신을 업그레이드 하라는 것이다. 빌드 속도를 높여서 절약한 시간으로 더욱 빠른 피드백을 받고, 문제를 빠르게 픽스하며, 다음 개발 태스크로 빠르게 이동할 수 있다.
팽창된 빌드가 신속한 피드백을 지연시킨다.
제목: 팽창된 빌드
반패턴: 모든 유형의 자동화된 검사 툴을 실행하거나 피드백이 지연되는 로드 테스트를 실행하기 등, 모든 것을 커밋(commit) 빌드 프로세스에 의존하기.
솔루션: 빌드 파이프라인(pipeline)이 다른 유형의 빌드를 실행하도록 한다.
일부 개발 팀들은 잊어버리기 쉬운 자동화 빌드에 추가될 수 있는 모든 프로세스에 매료된다. 컴파일 하는데 두 시간 걸렸다던 필자의 프로젝트 이야기 기억하는가? 우리가 실행 테스트를 그 빌드 프로세스의 일부로 추가했다면 어떻게 되었을까? 수 백만 라인의 코드에 대해 정적인 분석 툴을 실행하는데 과연 얼마나 걸릴까? 8 시간 빌드 프로세스가 믿을 수 없다고 여겨진다면, 다시 생각해 보라. 필자는 이러한 상황을 주기적으로 경험한다.
사람들은 더 많은 빌드 정보를 팀 멤버들에게 제공하고자 하는 마음에 팽창된 빌드로 전향하곤 한다. 바로 이것은 개발 팀에게 신속한 피드백을 주는 것 사이에 균형을 깨기도 하지만, CI 빌드 프로세스에서 유용한 정보를 제공하는 방법이 되기도 한다.
효율성을 위한 빌드 파이프라인
빌드 프로세스가 시간을 많이 허비하고, 다른 향상 기술을 구현했다고 생각하고 테스트 실행 시간을 최적화 했다면, 빌드 파이프라인(build pipeline)이라고 하는 것을 만들어야 한다. 빌드 파이프라인의 목적은 장기 실행 프로세스를 비동기식으로 실행하면서, 누군가가 코드를 검사하더라도, 피드백 받는 것이 지연되지 않도록 하는 것이다.
예를 들어, 빌드 실행에 10분 이상 걸린다면, 빌드 파이프라인은 구축되어 누군가가 코드를 저장소에 위임한 후에, 초기의 경량 빌드가 실행되도록 할 수 있다. 이러한 "커밋" 빌드는 빠른 단위 테스트를 컴파일 및 실행하는 것 같은 경량의 프로세스들로 구성된다. 이러한 초기 구현의 성공에 기반하여, 제 2의 빌드가 실행되고, 이것은 보다 장기적인 실행 테스트, 소프트웨어 검사, 애플리케이션 서버에 전개 등을 수행한다.
예를 들어, Listing 3에서, 저장소에서 변경을 검사하도록 CruiseControl을 설정했다. 변경 사항을 발견하면, CruiseControl은 위임 빌드(delegating build)를 실행하는데, 이것은 프로젝트의 메인 빌드 파일(Ant를 사용하고 있을 경우, build.xml)을 호출한다. 독특한 것은 CruiseControl이 다른 대상을 실행하는데, 이는 컴파일과 소단위 단위 테스트 같은 경량의 프로세스를 실행하는 것이다.
Listing 3. 변경 사항을 검사하는 CruiseControl 설정
<project name="brewery-commit">
...
<modificationset quietperiod="120">
<svn RepositoryLocation="http://brewery-ci.googlecode.com/svn/trunk"/>
</modificationset
...
|
Listing 4에서, CruiseControl은 brewery-commit 프로젝트에 대해 변경 사항을 검사하도록 설정된다. (이것은 저장소에 없다. 실제로, 로그 파일을 찾고 있다.) 변경 사항이 발견되면, CruiseControl은 또 다른 위임 빌드를 실행한다. 이 빌드는 같은 빌드 파일을 호출하지만, 함수 테스트, 소프트웨어 검사 같은 장기 실행 프로세스를 실행하는 다른 대상에 관한 것이다.
Listing 4. 장기 실행 빌드를 실행하는 CruiseControl 설정
<project name="brewery-secondary">
...
<modificationset quietperiod="120">
<buildstatus logdir="logs/brewery-commit" />
</modificationset>
...
|
팽창된 빌드(Bloated Build) 반패턴은 CI가 효력을 발휘하지 못하는 이유로 많이 인용된다. 하지만, 여러분도 보듯, 빌드 파이프라인을 사용한다면 문제가 없다. 효과적인 빌드 파이프라인은 "80/20" 범칙의 효과를 극대화 한다. 20 퍼센트의 빌드 시간을 소비하면 80 퍼센트의 빌드 에러가 발생한다. (파일 소실, 깨진 컴파일, 테스트 실패 등). 이러한 프로세스가 완료되고, 개발자들이 피드백을 받은 후에, 실행하는데 더 오랜 시간이 걸리는 제 2의 빌드를 실행하면, 다른 빌드 에러의 20 퍼센트 또는 상대적으로 우세한 에러가 만들어 진다.
반패턴은 픽스될 수 있다.
CI 반패턴은 팀들이 Continuous Integration을 통해 얻을 수 있는 혜택을 제한한다. 하지만, 필자가 이 글에서 설명한 기술들로 이러한 반패턴의 빈도수를 줄일 수 있다:
- 코드를 자주 실행하면 통합에 따른 복잡성을 줄일 수 있다.
- 깨진 빌드를 방지하면 소스 파일을 실행하기 전에 개별 빌드를 실행하는 것이 쉬워진다.
- 다양한 피드백 메커니즘을 사용하면 쉽게 무시되는 오래된 빌드 상태 정보를 방지할 수 있다.
- 액션을 취할 수 있는 적임자에게 피드백을 주는 것이 빌드 문제를 팀 멤버들에게 알리는 최상의 방법이다.
- 빌드 머신에 투자하면, 피드백의 속도를 높일 수 있다.
- 빌드 파이프라인을 구현하는 것이 빌드 팽창을 줄이는 한 가지 방법이다.
필자가 이 글에서 설명한 반패턴은 필자가 자주 목격하는 것들이지만, 이 외에도 여러 가지가 있다:
-
Continuous Ignorance, 최소한의 프로세스들로 구성된 빌드가 언제나 성공적인 빌드 상태로 이어진다.
-
여러분의 머신에서만 작동하는 빌드는 결점이 들어오고 픽스되는 그 시간을 지연시킬 수 있다.
-
병목 현상 커밋(Bottleneck Commit)은 깨진 빌드의 원인이 되고 팀 멤버들을 괴롭힌다.
-
가끔 중단되는 빌드를 실행하면 신속한 피드백이 지연된다.
다음 글을 기대해 주기 바란다. Continuous Integration에서 얻을 수 있는 혜택을 막는 다른 CI 반패턴을 소개하겠다.
참고자료 교육
-
Continuous Integration: 소프트웨어 품질을 향상하고, 리스크를 줄이기
(Paul Duvall et. al, Addison-Wesley Signature Series, 2007): Learn over 40 CI practices in different languages and platforms.
- "Continuous Integration을 사용하여 결점 찾기" (Andrew Glover, developerWorks, 2007)
- "Continuous Integration" (Martin Fowler, martinfowler.com)
- "지속적인 피드백 (한글)" (Paul Duvall, developerWorks, 2007년 6월): 모든 소스 코드 변화에 대해 즉각적인 피드백 받기.
- "Pipelined Continuous Integration이 좋은 생각인가?" (infoq.com, 2007년 9월)
-
사람을 위한 자동화
(Paul Duvall, developerWorks): 시리즈 모두 보기.
-
developerWorks 자바™ 존: 자바 프로그래밍 관련 다양한 기술자료.
제품 및 기술 얻기
토론
필자소개
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
