SW 릴리스를 간편하게 - Maven plugin + Jenkins

다양한 형태의 소프트웨어들(OS, 응용프로그램, WAS, DB, 오픈소스, 3rd party 프레임워크, 라이브러리 등)은 공통점을 가지고 있습니다. 소프트웨어의 버전(Version) 입니다. 그리고 대부분 Release Note 라는 문서 파일이 같이 포함되어 어떤 버그가 수정되었는지, 어떤 기능이 추가되었는지, 또는 어떤 개선이 이루어져있는지 등의 정보를 소프트웨어를 사용하는 클라이언트에게 제공하고 있습니다.

진화하는 소프트웨어, 하지만 항상 1.0.0-SNAPSHOT

지난 수년간 소프트웨어를 만들어오면서 버저닝(Versioning)을 해본 경험은 많지 않았습니다. 어찌보면 지금까지 필요성을 못 느꼇던 부분도 있고, 어떻게 하는지 몰라서 혹은 해본적이 없어서 일 것입니다.

대부분 프로젝트 생성시 POM(우리가 소프트웨어 빌드 도구로 대부분 Maven을 많이 사용하기 때문에 Maven 기준으로 글을 작성하였습니다.) 파일에 0.0.1-SNAPSHOT 혹은 1.0.0-SNAPSHOT 으로 시작하게 되고, 시간이 흐르면서 소프트웨어는 변화 하지만 버전은 영원히 동일하게 유지되는 경우가 많았습니다.

계속 1.0.0-SNAPSHOT 버전을 유지하면서 ‘오류 수정하고 배포 하였으니 의존관계를 업데이트 받고 다시 해봐!!’ 라고 다른 팀에게 말로 전하기도 하고, 버전체계가 있기는 하지만 수동으로 버전을 관리하거나 배포할 때만 '이건 버전이 몇이다!!' 라고 전하는 경우도 있었습니다. 심지어는 있던 버전관리 체계가 귀찮은 작업으로 취급되어 없어지는 현상도 목격 했습니다.

소프트웨어 버전의 필요성

우리가 만드는 소프트웨어를 버전관리 하지 않는다고 문제가 있는 것은 아닙니다. 소프트웨어가 단일 모듈이거나 규모가 작아서 관리가 어렵지 않고, 개발 초기단계처럼 빈번한 변화가 발생하는 등의 경우는 오히려 소프트웨어 버저닝이 오버헤드가 될 수 있습니다.

버전은 소프트웨어에 유일한 식별 번호를 부여하여 관리와 커뮤니케이션을 용이하게 하기 위한 목적이 강합니다.

패키징되어 고객에게 전달되는 제품, 차세대와 같은 대규모의 프로젝트, 여러 팀이 개발한 소프트웨어 간의 복잡한 의존관계가 발생하는 경우 버저닝은 다음과 같은 상황에서 유용한 커뮤니케이션의 용도로 활용되고, 관리를 용이하게 합니다.

어떤 버전에서 발생하는 버그(bug) 였는지, 어떤 버전에서 픽스(fix) 되었는지
어떤 버전에서 기능이 추가/삭제 되었는지, 무엇이 변경되고 개선이 되었는지
소프트웨어를 사용하는 클라이언트는 어떤 버전을 사용하고 있는지

소프트웨어 릴리스(Release)

제가 진행했던 프로젝트에서 소프트웨어 릴리스는 다음과 같은 절차를 거쳐 수행하게 됩니다.

릴리스 되는 모듈의 전체 소스코드 SVN checkout/update
릴리스 되는 모든 모듈의 단위테스트 수행하여 점검
모듈의 모든 POM 파일의 SNAPSHOT 버전을 RELEASE 버전으로 변경후 SVN commit(1.0.0-SNAPSHOT -> 1.0.0-RELEASE)
릴리스 버전을 SVN Tagging 하여 해당 버전의 소스코드를 유지
릴리즈 버전 빌드(JAR, WAR)
모듈의 모든 pom.xml 파일의 버전을 다음 SNAPSHOT 버전으로 변경후 SVN commit(1.0.0-RELEASE -> 1.0.1-SNAPSHOT)
통합 저장소(Nexus)에 배포(Deploy)
릴리스 공지(EMAIL)

최대한 빨리 오류수정 및 기능 추가하고 배포해야 하는데 릴리스 절차가 생겨나면서 위의 번거로운 작업들을 하기란 쉽지 않았습니다.

릴리스를 간편하게

제가 참여했던 차세대 프로젝트는 업계 1위의 서비스를 제공하고, 그에 맞게 규모 또한 상당했습니다. 각 팀에서 개발하고 있는 단위 모듈 또한 전체 합하면 수십 개가 넘었습니다.(JAR, WAR 갯수로 헤아려 보면 수백개는 될 것입니다.) 그리고 서로간의 복잡한 의존관계를 가지고 있었습니다.

앞서 작성한 이유에 의해 분명 릴리스는 반드시 필요했습니다. 하지만 위의 절차대로 진행하도록 모든 팀에게 요구하기에는 쉽지 않은 일이며, 게다가 환경에 익숙하지 않은 엔지니어들에게는 변경된 소프트웨어를 상용화 하기란 여간 어려운 것이 아니었습니다.

그래서 각 팀에서 릴리스를 최대한 편하게 할 수 있는 방안을 마련하고자 하였습니다...

Maven Release Plugin + Jenkins

프로젝트에 구성된 환경은 다음과 같습니다.

프로젝트에 구성된 릴리스 환경

Maven Release Plugin

Maven Release Plugin은 Maven의 추가 플러그인으로 우리가 필요했던 위의 1~7번 릴리스 절차를 쉽게 처리할 수 있도록 지원합니다.(프로젝트에서는 maven-release-plugin-2.2.2 버전을 사용했습니다.)

릴리즈 되는 모듈의 POM에는 SCM 정보와 Maven Release Plugin이 선언되어 있어야 합니다.

릴리스 대상 모듈의 pom.xml의 Maven Release Plugin 선언

릴리스 대상 모듈의 pom.xml의 SCM 정보

Maven Release 과정은 크게 두 단계(prepare, perform)로 구분됩니다.

prepare : 릴리스 준비단계

소스코드 오류 체크
의존관계를 가지고 있는 하위 모듈에 SNAPSHOT이 포함되어 있는지 체크(릴리스되는 모듈은 의존관계에 있는 하위 모듈의 SNAPSHOT 버전이 없어야 합니다.)
릴리스되는 모듈들의 POM에 존재하는 x-SNAPSHOT 버전을 릴리스 버전으로 변경
POM의 SCM 정보(TAG경로) 변경
릴리스되는 모듈들의 전체 단위테스트 수행
POM의 모든 변경된 정보를 commit
SCM Tagging 수행
POM의 정보를 다음 개발버전 y-SNAPSHOT으로 변경
POM의 변경정보 commit