실용주의이야기(Pragmatic Story)

지속적인 통합 프랙티스

앞서 언급한 이야기는 CI의 개요와 CI를 가지고 어떻게 생활하는지에 대한 것 이었다. 이 모든것들이 부드럽게 작동한다면 더 할 나위 없을 것이다. 지금 부터는 효과적인 CI를 구축하는데 중요 프랙티스에 대해 다루어 볼 것이다.

단일 소스 레파지터리 유지하기.

소프트웨어 프로젝트는 제품을 빌드하기 위해 같이 편성되어야 하는 많은 파일이 있다. 이 모든 것들을 추적관리하는데는 많은 노력이 필요하다. 특히 여러 사람이 관여하는 경우에는 더욱 그렇다. 그래서 수 년동안 소프트웨어 개발팀이 이 모든것을 관리하기 위한 툴을 만들어 왔다는 사실은 놀랄일이 아니다. 이런 툴에는 소스 코드 관리 도구, configuration management, 형상관리 시스템, 레파지터리와 같은 여러 이름을 가지는데 대부분 개발 프로젝트의 중요한 부분이다. 하지만 모든 프로젝트가 다 그렇지는 않다는 것은 놀랍고도 슬프 사실이다.

드물기는 하지만 그런 시스템을 아예 이용하지 않거나 로컬과 공유 서버에 몇가지를 혼용해서 사용하는 프로젝트도 있다.

그래서 단순하면서도 기본이 되는것이 적절한 소스 코드 관리 시스템을 갖는 것이다. 좋은 품질의 오픈 소스 툴을 사용할수 있어서 비용은 이슈가 되지 않는다. 현재 오픈소스 레파지터리로 선택할 수 있는건 서브버전(Subversion)이다. (오랫동안 오픈 소스 툴 CVS가 널리 사용되었는데 더 개선된 부분이 없기 때문에 서브버전을 쓰는게 더 나은 선택이 될것이다.) 재밌게도 나는 개발자들에게 대부분 상용 소스코드 관리 툴이 서브버전보다 못하다고 말해왔다. 돈을 지불할만한 툴은 퍼포스(Perforce)뿐이라는 이야기를 계속해서 들었다.

소스 코드 관리 시스템이 준비되면 모든 사람들이 소스코드 위치를 잘 알수 있도록 해야한다. "foo-whiffle 파일이 어디있죠 ?" 라고 물어보는 사람은 없어야 한다. 모든것이 레파지터리에 있어야 한다.

많은 팀들이 레파지터리를 사용하면서도 저지르게 되는 공통된 실수가 한가지 있다. 레파지터리에 모든것을 넣지 않는다. 코드에서 사용하는 것들을 레파지터리에 넣는것은 물론 테스트 스크립트, 프로퍼티 파일, 데이터베이스 스키마, 설치용 스크립트, 외부 라이브러리같은 빌드에 필요한 모든것들도 레파지터리에 있어야 한다.

예전에 컴파일러까지 레파지터리에 넣은 프로젝트를 본적이 있다.(특이한 C++ 컴파일러가 처음 등장했을때는 중요했다.) 기본 규칙은 새로운 PC를 가지고  프로젝트를 시작할때, 레파지터리에서 체크아웃 받으면 시스템 전체 빌드가 가능해야 한다는 것이다. 새로운 PC에서 최소한의 작업으로 위와 같은 일이 가능해야 한다. 보통은 할일도 많고, 설치도 복잡하고, 안정화도 시켜야 하다. 운영체제, 자바 개발환경, 데이터 베이스가 전형적인 예가 된다.

빌드에 필요한 모든것들을 소스 코드 시스템에 넣어야 한다. 그러나 사람들이 보통 사용하는 IDE 툴의 설정 같은것은 간과하는데 이를 레파지터리에 넣게 되면 같은 IDE 설정을 쉽게 공유할수가 있다.

버전 컨트롤 시스템의 특징중 하나는 개발의 다른 흐름을 관리하기 위해 여러개의 브랜치를 만들수 있다는 것이다. 이 특징은 유용하고 중요하지만 자주 남용되기 때문에 사람들이 문제에 부딪치기도 한다. 브랜치는 최소한으로 유지하라. 개발할때 현재 프로젝트에서 사용하는 브랜치를 하나로 유지해야 하는데 이를 주흐름(mainline)이라 부른다. 많은 사람들이 이 주 흐름에서  대부분의 시간을 보내야만 한다.(브랜치로서 의미 있는건 제품을 릴리즈 하기 전에 버그를 수정한다던가 임시로 실험하는것등이다.)

빌드에 필요한 것은 어떤것이든 레파지터리에서 관리해야 하지만 실제로 빌드되서 만들어 지는것은 대상이 아니다. 어떤 사람은 소스 콘트롤에 빌드된 제품을 유지하기도 하는데, 이렇게 하면 빌드를 반복함으로써 얻게 되는 신뢰성을 해치는 더 큰 문제가 발생할수도 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.