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