 |
|
CI부터 시작하기
본 절에서는 CI 프로세스의 다양한 컴포넌트가 맞춰지는 방법과 그런 식으로 맞춰지는 이유에 대해 보여줄 것이다. 그리고 나서 코딩을 시작할 것이다.
필요한 사전지식: 빌드 시스템!
반복 가능하고 신뢰성 있는 빌드는 예측할 수 있는 소프트웨어 프로세스를 위한 초석이다. 전에 언급했듯이 자바 플랫폼에서는 컴파일이나 배치 같은 일반적인 작업을 자동화하는 것을 주 목표로 삼는 앤트가 인기있는 빌드 도구다. 또한 JUnit이나 TestNG 같은 테스트 프레임워크로 유닛 테스트를 수월하게 하고 정적 코드 분석을 자동화하는 PMD나 FindBugs 같은 많은 다른 도구와도 잘 통합한다. 앤트를 사용하여 소스 파일을 컴파일하는 것은 명령 프롬프트에서 ant compile 명령을 하는 것처럼 쉽다.
신뢰성 대 반복성
앤트가 반복성을 책임진다면 신뢰성은 독자에게 달렸다. 소프트웨어 빌드에 있어서 신뢰성은 컴파일 또는 테스트 명령을 내렸을 때 누구나 같은 행동을 경험하는 것을 의미한다. 하지만 만약 어떤 사람이 빌드 자체에서 필요한 라이브러리가 명시적으로 참조되지 않아 컴파일을 할 수 없게 된다면(누군가는 라이브러리를 가지고 있고) 빌드는 신뢰성이 없다는 뜻이다. 이는 반복성도 없다고 의의를 제기할 수도 있다!
CI에서 신뢰성과 반복성은 매우 중요하다. CI는 인간의 중재 없이 자동화된 프로세스이므로 궁극적으로 발생하는 빌드 프로세스는 결점없이 작동해야 한다. 빌드 프로세스는 꼭 필요한 라이브러리, 문서화되지 않은 부분, 수동으로 새로 고친 데이터베이스처럼 CI 서버가 제어할 수 없는 간단한 독립적 이벤트여야 한다. 물론 어떤 빌드는 실패하겠지만 — 예를 들어 컴파일되지 않은 코드를 확인할 때 — 빌드 자체가 망가졌기 대문에 빌드는 실패해서는 안 된다.
기본적인 빌드 프로세스
소프트웨어 개발 프로세스에 가치를 추가하는 CI에 있어 빌드 자체는 코드를 컴파일하는 이상의 일을 해야 한다. 빌드는 코드가 변화할 때마다 작동하기 때문에 테스트하고 코드를 검사하는 데 적격이다.
기본적인 빌드 프로세스는 다음과 같은 작업을 한다.
- 테스트를 포함한 소스코드 컴파일하기
- JUnit이나 TestNG로 작성된 테스트 실행하기
- PMD 같은 코드 검사하기
- JAR, WAR, 또는 파일 시리즈에 최종 제품을 저장하기
- 최종 애셋 배치하기(최종 제품이 이를 보증한다고 가정하자)
이들 단계는 최소 단계고 데이터베이스 처리나 소프트웨어 제품의 다른 부분 같은 고급 옵션은 건드리지도 않았음을 기억하자.
디렉터리 구조 설정하기
소프트웨어 프로젝트의 디렉터리 구조를 설정하기 위해 무수한 전략이 존재하고 각각 장점과 단점이 있다. 나는 테스트 코드에서 소스코드를 분리하는 걸 좋아하는 편이고 항상 이들 코드 행에 대해 각기 다른 디렉터리 구조를 만든다. 써드파티 라이브러리를 처리하는 일반적인 기술은 lib 디렉터리를 만드는 것이다. 하지만 Ivy 같은 써드파티 의존성을 처리하기 위해 관리 가능한 메커니즘이 있음을 더 많이 기억하자.
프로젝트의 디렉터리 구조를 어떻게 설정할지 결정하는 것과 상관없이 더 정교하고 조직적일수록 좋다. 이는 특히 프로젝트의 자산(소스 파일이나 테스트 같은)이 늘어날수록 그렇다. 예를 들어 그림 1은 써드파티 라이브러리의 디렉터리를 포함하는 간단한 프로젝트 디렉터리 구조와 소스 파일과 이와 관련된 테스트의 두 가지 다른 디렉터리를 보여준다.
그림 1. 간단한 프로젝트 구조
그림 1처럼 build.xml 파일은 프로젝트의 루트 디렉터리에 위치함을 주목하자. 이는 프로젝트의 빌드 파일로 소스코드를 제품 준비 상태로 옮기는 것과 관련된 자동화된 동작의 최소화 세트를 정의한다.
| 
