(2) 젠킨스씨가 있는 개발풍경
젠킨스에 대한 두번째 포스팅으로 오늘은 젠킨스가 실제 프로젝트에서 어떤 형태로 사용될 수 있는지 살펴 보고자 한다.
젠킨스씨가 있는 개발풍경
 |
| 하루 24시간이 모자르신 젠킨스씨 |
형상관리 툴과의 연동
젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적 이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모두 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었는데 이를 nightly-build라 한다. Fire Fox와 같은 많은 오픈소스 프로젝트들은 정식 배포 버전과 별도로 nightly-build에서 생성된 바이너리를 함께 배포함으로서 오픈 베타테스트 또한 지속적으로 수행 할 수 있게 되었다.
젠킨스는 정기적인 빌드에서 한반 나아가 서브버전, Git와 같은 버전관리 툴과 연동하여 소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동되도록 설정 할 수 있다.
물론 개발도중의 프로젝트에서 커밋은 매우 빈번히 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라 큐잉되어 자신이 실행될 차례를 기다리게 된다.
코드의 변경과 함께 이뤄지는 이같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.
- 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
- 자동화 테스트 수행
- 정적 코드 분석에 의한 코딩 규약 준수여부 체크
- 프로파일링 툴을 이용한 소스 변경에 따른 성능변화 감시
- 결합 테스트 환경에대한 배포작업
이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이선과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.
각종 배치 작업의 간략화
프로젝트 기간중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, 디플로이 작업과 같은 단순 작업에 시간과 노력을 빼았기는 경우가 빈번하다.
데이터베이스의 구축, 어플리케이션 서버에의 디플로이, 라이브러리 릴리즈와 같이 이전에 커맨드 라인 인터페이스로 실행되던 작업들이 젠킨스 덕분에 미려한 웹인터페이스로 손쉽게 가능해 지게 되었다.
Build 자동화의 확립: 빌드 툴의 경우 Java는 이미 Maven이 대세로 자리잡았다. 물론 Ant도 훌륭한 기능들을 많이 갖추고 있지만 플러그인의 편리함은 Maven을 따라잡지 못한다. 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 Jenkins를 사용하지 않을 이유가 하나도 없다.
데이터베이스의 구축, 어플리케이션 서버에의 디플로이, 라이브러리 릴리즈와 같이 이전에 커맨드 라인 인터페이스로 실행되던 작업들이 젠킨스 덕분에 미려한 웹인터페이스로 손쉽게 가능해 지게 되었다.
젠킨스씨는 거들뿐
이와같이 다양한 작업들을 손쉽게 처리해 주지만 테스트를 만들고 빌드 전략을 세우는 등의 작업은 여전히 개발자의 몫으로 남아 있다. 젠킨스가 진정으로 프로젝트에 도움이 되기 위해서는 다음과 같은 작업이 반드시 함께 이루어 져야 한다.Build 자동화의 확립: 빌드 툴의 경우 Java는 이미 Maven이 대세로 자리잡았다. 물론 Ant도 훌륭한 기능들을 많이 갖추고 있지만 플러그인의 편리함은 Maven을 따라잡지 못한다. 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 Jenkins를 사용하지 않을 이유가 하나도 없다.
자동화 테스트: 자동화 테스트야 말로 젠킨스를 사용해야 하는 이유중 으뜸이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git와 같은 버전관리 시스템관 연동하여 코드변경을 감지하고 자동화 테스트를 수행해 줌 으로서 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.
무엇보다 중요한것은 이러한 안전망이 제공해 주는 안심감이야 말로 개발자들이 악취나는 코드를 리팩토링을 통해 적극적으로 제거 할 수 있게 해 주는 든든한 버팀목이 된다는 점이다.
코드 표준 준수여부 검사: 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수여부의 검사나 정적 분석을 통한 코드 품질 빌드 내부에서 수행하는 것으로서 기술적 부채의 감소에도 크게 기여한다.
빌드 파이프라인 구성: 2개 이상의 모듈로 구성되는 프로젝트의 경우 당연하게도 레이어드 아키텍처가 적용되어 있을터이고 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들자면 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다. 이러한 파이프라인의 구성은 선형뿐만 아니라 간단한 스크립트를 통해 매우 복잡한 제어 까지도 가능하다.
무엇보다 중요한것은 이러한 안전망이 제공해 주는 안심감이야 말로 개발자들이 악취나는 코드를 리팩토링을 통해 적극적으로 제거 할 수 있게 해 주는 든든한 버팀목이 된다는 점이다.
 |
| 제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스씨를 만나게 된다. |
테스트 커버리지: 젠킨스는 자동화 테스트 실시와 더불어 테스트 커버리지도 리포팅을 해 준다. 개인적으로 테스트 커버리지가 품질에 대해서 기여하는 부분에 대해서는 회의적인 입장이다. 결국 자동화 테스트의 작성 자체는 프로그램 사양에 대한 개발자 심도있는 고찰을 기반으로 하는데 커버리지 라고 하는 일괄적인 기준으로 제약을 가하게 되면 테스트가 본래의 의미를 잃어버린 커버리지를 달성하기 위한 테스트가 만들어지기 쉽기 때문이다.
젠킨스에서는 다양한 형태로 클러스터링을 지원하는데, 자동화 테스트가 충실하게 작성된 프로젝트라면 테스트에 상당한 컴퓨팅 파워가 투입되어야 하기 때문이다.
젠킨스에서는 다양한 형태로 클러스터링을 지원하는데, 자동화 테스트가 충실하게 작성된 프로젝트라면 테스트에 상당한 컴퓨팅 파워가 투입되어야 하기 때문이다.
코드 표준 준수여부 검사: 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수여부의 검사나 정적 분석을 통한 코드 품질 빌드 내부에서 수행하는 것으로서 기술적 부채의 감소에도 크게 기여한다.
빌드 파이프라인 구성: 2개 이상의 모듈로 구성되는 프로젝트의 경우 당연하게도 레이어드 아키텍처가 적용되어 있을터이고 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들자면 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다. 이러한 파이프라인의 구성은 선형뿐만 아니라 간단한 스크립트를 통해 매우 복잡한 제어 까지도 가능하다.
 |
| Build Pipeline Plugin을 이용하면 논리 구조를 가진 파이프라인도 웹 인터페이스를 통해 간단히 만들 수 있다. |
