소스를 실행 시스템으로 전환하는 과정은 컴파일, 파일 삭제, 데이타베이스 스키마 로딩등의 작업을 포함하는 복잡한 프로세스가 되기도 한다. 하지만 이 소프트웨어 개발 과정 중 이 부문의 많은 타스크들은 자동화 할 수 있으며, 반드시 자동화해야 한다. 사람들에게 생소한 명령어를 치게 하거나, 대화창을 클릭하게하는 것은 시간낭비이며, 많은 실수를 유발시킨다.
자동화된 빌드 환경은 시스템의 일반적으로 갖추어야 할 요건이다. 유닉스 분야에서는 이미 십여년 동안 make를 사용해 오고 있다. 자바커뮤니티는 Ant를 내놓았다. .NET 커뮤니티는 Nant를 사용하다가, 이제는 MSBuild를 이용한다. 단일 명령으로 이러한 스크립트를 실행시켜 여러분들의 시스템을 빌드하고 런치할 수 있도록 해야 한다.
쉽게 저지르는 실수 중에 하나가 모든 것을 자동화된 빌드에 포함시키지 않는 것이다. 빌드는 저장소 밖에 있는 데이터베이스 스키마를 갖고 와서, 실행 환경에서 그것을 작동시킬 수 있어야 한다. 아까 얘기했던 내 경험상 원칙을 좀 보완하겠다. 초기화 된 머신에서 누구나 소스를 저장소 밖으로 반출하고, 단일 명령을 때려 그 머신에서 구동되는 시스템을 만들 수 있어야 한다.
빌드 스크립트들은 다양한 형태로 사용되며, 종종 플랫폼이나 커뮤니티에 특화되기도 하지만 그럴 필요 없다. 우리는 많은 자바프로젝트에서 Ant를 사용했지만 몇몇 프로젝트는 Ruby(Ruby Rake시스템은 매우 괜찮은 빌드 스크립트툴이다.)를 사용했다. 또한 Ant를 이용하여 초기 MS COM프로젝트를 효과적으로 수행하기도 했다.
큰 규모의 빌드는 종종 시간이 소요되기도 하는데, 작은 변경만 발생했을 때 모든 스텝을 수행하고 싶지는 않을 것이다. 따라서 좋은 빌드 툴은 작업 진행 중에 변경된 부분을 파악할 수 있도록 분석을 한다. 가장 일반적인 방법은 소스코드와 오브젝트 파일의 날짜를 확인하여 소스코드의 날짜가 최신일 때만 컴파일을 수행하는 것이다. 의존성(Dependency)은 까다로운 문제다. 하나의 오브젝트 파일이 변경이 되었을 때 해당 오브젝트 의존성을 가진 것들이 재빌드될 필요성이 있을 수 있다. 이러한 부분을 컴파일러가 해결할 수 도 있으며, 못할 수 도 있다.
개발자의 요구에 의해, 서로 다른 유형의 것들을 빌드해야 하는 경우도 있을 수 있다. 테스트 코드와 더불어 또는 테스트 코드가 없는 상태에서 빌드할 수도 있으며 심지어 서로 다른 테스트 셋을 갖고 작업을 할 수도 있다. 어떤 컴포넌트들은 stand-alone으로 빌드될 수도 있다. 빌드 스크립트는 여러 다양한 유형별로 선택적인 타겟을 선별 빌드 할 수 있어야 한다.
많은 이들이 IDE를 사용하며, 대부분의 IDE들은 몇몇 종류의 빌드관리 프로세스를 내장하고 있다. 하지만 이러한 것들은 IDE 전용이며, 종종 손상되기 싶다. 게다가 그것들은 IDE작업을 필요로 한다. 개별 개발 환경에서는 IDE 사용자들이 프로젝트 파일을 설정하고 IDE의 내장기능을 사용하는 것도 괜찮다. 하지만 서버에서 사용 가능한 빌드나 다른 스크립트에서 구동가능한 마스터 빌드를 보유해야 하는 것은 필수불가결하다. 그래서 우리는 자바 프로젝트에서 개발자들이 IDE를 이용한 빌드 작업 수행을 허용하지만, 마스터 빌드는 개발 서버에서 구동할 수 있도록 Ant를 사용한다.
본 포스트는 Martin Fowler 선생께서 쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)
