세 프로젝트를 오가며 일하는데 빌드하는 방법이 다 달랐다. 프로젝트를 옮길 때마다 어떻게 하는지 다시 찾아봐야 했다.
Table of contents
Open Table of contents
세 가지를 다 외워야 했다
A는 Eclipse 에서 내보내기로 WAR 를 만들고, B는 build.xml 을 Ant 로 돌리고, C는 빌드 스크립트가 아예 없어서 폴더를 통째로 올린다.
Ant 도 안 쓰는 C가 특히 문제였다. 무엇을 올려야 하는지가 사람마다 달라서 어떤 사람은 .svn 폴더까지 올리고 있었다. 올리는 사람이 누구냐에 따라 서버에 들어가는 것이 달라진다.
무엇이 다른지 표로
셋을 나란히 놓고 항목별로 적어 봤다.
A B C
빌드 도구 이클립스 ant 없음
결과물 WAR WAR 폴더
설정 분리 아니오 예 아니오
제외 파일 - 정의됨 사람마다
빌드 문서 없음 build.xml 없음Ant 를 쓰는 B만 제대로 돼 있었다. 무엇을 기준으로 삼을지가 표를 그리니까 바로 보였다.
가장 위험한 것부터 옮겼다
C부터 손댔다. 제외할 것을 build.xml 에 적어 두니 사람마다 다를 일이 없어졌다.
<war destfile="dist/C.war" webxml="web/WEB-INF/web.xml">
<fileset dir="web">
<exclude name="**/.svn/**"/>
<exclude name="**/*.bak"/>
<exclude name="WEB-INF/classes/**"/>
</fileset>
<classes dir="build/classes"/>
<lib dir="web/WEB-INF/lib"/>
</war>옮기고 나서 새 WAR 와 옛 방식으로 올리던 것을 파일 목록으로 비교했다. .svn 폴더와 백업 파일과 테스트 클래스 셋이 새 것에 없었고 셋 다 없어야 할 것이었다.
빠진 것도 같이 봤다. 있어야 할 것이 안 들어갔으면 그게 더 큰일이라 양쪽 방향으로 대조했다.
설정 분리와 명령 이름
세 프로젝트의 build.xml 이 같은 명령으로 빌드되게 타깃 이름을 맞췄다. 지우는 것과 컴파일하는 것과 배포 파일을 만드는 것에 같은 이름을 붙이면, 프로젝트를 옮겨도 무엇을 치는지 다시 안 찾아도 된다.
A와 C는 개발용 설정이 소스에 그대로 들어가 있어서 build.xml 에서 환경별로 나눴다. 빌드할 때 어느 환경인지를 인자로 주고 그에 맞는 파일을 복사하는 방식이다. 무엇을 넣었는지는 빌드 로그에 남게 했다. 어느 설정으로 만든 것인지가 나중에 문제가 된다.
빌드 방법과 WAR 위치와 배포 절차와 설정 파일 위치를 프로젝트마다 적어 뒀다. 물어봐야만 알 수 있는 것이 많으면 그만큼 사람이 묶인다.
라이브러리 판이 섞여 있었다
정리하다 보니 세 프로젝트가 같은 라이브러리의 다른 판을 쓰고 있었다. C에는 두 판이 같이 들어 있기까지 했다.
두 판이 함께 있으면 어느 것이 쓰이는지를 클래스 로더가 읽는 순서가 정한다. 찾아보니 Servlet 명세는 WEB-INF/lib 안의 순서를 정하지 않는다. 컨테이너가 알아서 정하고 운영체제에 따라 갈리기도 한다. 우리가 정한 것이 아니라 우연히 정해진 것이다. 같은 판으로 맞추고 WEB-INF/lib 에 무엇이 왜 있는지를 적었다.
정리
- 프로젝트마다 빌드가 다르면 옮길 때마다 다시 배워야 한다
- 무엇이 다른지 표로 적으면 어느 것을 기준으로 삼을지가 보인다
- 가장 위험한 것부터 옮긴다.
build.xml에 제외할 것을 적으면 사람마다 다를 일이 없다 - 옮기고 나서
WAR안을 비교한다. 빠진 것과 더 들어간 것을 둘 다 본다 - 프로젝트가 달라도
build.xml타깃 이름을 같게 맞춘다 - 설정을 환경별로 나누고 무엇으로 만들었는지 로그에 남긴다
- 빌드와 배포와 설정 위치를 적어 둔다. 물어봐야 아는 것이 많으면 사람이 묶인다
Servlet명세는WEB-INF/lib안의 순서를 정하지 않는다- 같은 라이브러리의 두 판이 함께 있으면 무엇이 쓰이는지를 우연이 정한다