Download VCard

© 최병일 1981-‘10

'자동화'에 해당되는 글 1건

  1. 2007/11/30 빌드 자동화와 배치 빌드

빌드 자동화와 배치 빌드

작성자: yagur  Rev : 1

빌드 자동화 배치 빌드

  프로젝트의 모듈이 늘어감에 따라 의존성의 복잡도가 단순하지만은 않음을 느끼는 프로그래머가 많을 것이다. 모듈의 직교성(Orthogonality)을 살렸다 해도 모듈이기 때문에 그것을 링크하는것에 의존성이 생기는 것은 당연하다. 십여개 혹은 수십여개의 모듈간의 의존성때문에 빌드는 수작업으로 하기엔 프로그래머의 시간을 빼앗는 작업이 되어버렸다.

 팀작업시 협업 문제

  팀작업시에 작업자의 컴에서는 되는데 다른 동료의 컴퓨터에서 프로그램이 뻗어버리는 일이 발생하는 경우가 종종 볼수 있었다. 심지어 소스코드 저장소를 사용하지않을때는 컴파일 자체가 되지 않는 경우도 많이 보았다. 일일 빌드(Daily Build)혹은 주기적인 빌드를 시행하지 않는 곳에서는 모듈간의 문제점 해결에 수일에서 수주가 걸리기도 하며 업데이트 된내용이 반영이 안되거나, 반영되었다가 다시 옛것과 머지하다 업데이트 반영 내용이 사라져 버리는 경우도 흔한일이다. 동일한 저장소와 빌드 시스템이 있었다면 문제 해결에 가까워 질수 있을 것이다.

 주기적인 빌드
 
  모듈 자체를 써드파티의 것과 같이 바이너리로 개발자에게 동적라이브러리로 배포해버리는것도 좋은 방법이다. 하지만 프로그래머는 수많은 소스코드를 주고 받을수 밖에 없는데, 그것에 개발 협업 시스템(CDE)은 큰 도움이 되기도 한다. CDE에서 해당 모듈의 배포를 RSS를 통해 알수도 있어 편리하다. 무엇이 안정적이고 무엇이 실험적인 모듈인지 개발자가 알수 있다면 더 안정적인 개발을 진행할수 있다.
 소스코드 저장소와 자동화된 배치 빌드가 있다면 자주 여러사람의 작업물을 합치고 빌드해볼수 있을 것이다. 이는 잦은 테스트로 이어지기 때문에 많은 문제를 줄여줄수 있다. 빌드가 안되서 해당 개발자의 자리로 불려 다니던 최악의 경우의 횟수가 확연히 줄어들것이다.
 일일 빌드에 관한 조엘의 블로그에 유용한 포스트가 있으며, 스티브 맥코넬의 코드 컴플리트와 실용주의 프로그래머에도 좋은 관련 내용을 담고 있다.

"생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다." - 알프레드 노스 화이트헤드

 빌드의 방법

  주기적인 빌드를 하는 것으로 문제점을 줄이고 시간효율을 높히려 했으나 수많은 의존성을 가진 모듈들을 순서대로 손으로 컴파일을 진행해주어야 하는것은 귀찮은 일이고 실수할수도 있는 일이다. 그렇다면 배치 빌드(Batch Build)의 필요성을 느끼기 시작하거나 이미 하고 있는 개발자들도 많을 것이다.
 makefile이나 특정 스크립트를 이용한 자동화된 빌드 시스템이 아니라, 특정 IDE(주로 Visual Studio)에 익숙해져 있다면 배치 빌드는 매우 유용한 도구가 될것이다.
  또한 배치 빌드를 작성할때 유러가지 유형을 두면 좋다. 3가지 모듈이 A 모듈에 의존하고 있다고 가정했을때, A모듈을 변경하면 나머지 3가지 모듈역시 재컴파일 되야 하는가? A 모듈의 인터페이스가 변하지 않았다면 의존하고 있는 모듈들의 재링크는 필요하지 않다. 인터페이스가 변한상태와 변하지 않은 상태의 배치 빌드는 따로 작성해야한다.
 이렇게 작성된 배치 빌드들은 작업시에 수시로 사용될수도 있으며, 빌드 자동화를 위해 스퀘줄링 프로그램에 의해 호출될수도 있다. 프로그래머에게 매우 유용한 하고 편리하며, 시간을 절약해주는 보배인것이다.

 배치 빌드의 도구

  이 배치 빌드를 Window에선 batch파일을 작성해서 사용할수도 있지만 스크립트의 선택 역시 고민되는 부분이다. 외부 프로그램을 실행해야 하고 손쉬운 조건비교와 문자열 조합기능, 또한 플랫폼을 옮길 경우 사용할수 있는지 여부등을 고려해보면 좋은 배치 스크립트 언어를 선택할수 있다. 할 발자국 나아가서 생각한다면, 빌드후 빌드 결과를 웹에 올리는것까지 고려할수 있다. python, perl, tcl 여러가지 고차원 스크립트 언어를 활용할수있다.

기타:

  Visual Studio IDE 상의 프로젝트 종속성 설정은? - 동적 라이브러리의 경우

  프로젝트 종속성, 말그대로 족속성이기 때문에 모듈의 인터페이스가 변하던 변하지 않던 해당 모듈에 종속성을 가지고 있는 것들을 모두 일괄 빌드해 버린다. 이런 경우가 쓰이긴하겠지만, 모듈의 외부 인터페이스가 변하지 않는 경우 그것에 의존성을 가지고 있는 다른 모듈들을 다시 빌드할 필요는 없다. 모듈의 갯수가 많고 불필요한 빌드를 줄이기 위해서는 사용하지 말아야할 기능중 하나이다. 물론 꼭 전부 다시 빌드해야할경우엔 사용해야 하겠지만 말이다. 아마 이기능은 정적 라이브러리를 위한 기능인듯 하다.

Comment 0 Trackback 2

Trackback : http://yagur.impon.net/trackback/110 관련글 쓰기

  1. 소프트웨어 프로젝트에서 빌드를 어떻게 하시나요?

    레이의 소프트웨어 개발 토론 팀블로그 | 2008/11/12 14:12 delete

    소프트웨어를 개발하고 계신다면 빌드를 어떻게 하고 계시나요? 여기서 제가 말하고 있는 "빌드"는 "공식빌드"입니다. "공식빌드"란 소프트웨어를 개발하는 프로젝트나 절차에서 공식 Output을 만들어 내는 것입니다. "공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다. 이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다. 그럼 원래 질문으로 돌아가서 "공식빌드"를 어떻게 하고 계십니까? 혹시 IDE(통합개발환경)에서..

  2. Broken tree

    레이의 소프트웨어 개발 토론 팀블로그 | 2008/11/12 14:12 delete

    소프트웨어의 빌드가 안 되는 상황을 Broken Tree라고 합니다. 소프트웨어를 개발하는 회사라면 Broken Tree의 발생을 엄격하게 규제해야 합니다. 소스코드관리시스템 안의 소스코드는 항상 빌드가 가능한 상태로 존재해야 합니다. 그리고 언제든지 꺼내서 빌드를 하면 빌드가 되어야 합니다. 개발자들은 버그를 고치거나 새로운 기능을 추가할 때 소스코드관리시스템에서 최신 소스코드를 가져와서 소스코드를 고치고 개발자 테스트를 마친 후 소스코드를 체크인..

Top

prev 1 next