가끔 개발하는 개인 프로젝트가 있는데 이 프로젝트에 최근 Jenkins CI/CD를 적용해서 사용하고 있었다.

Github으로 Push할 때마다 Unit Test와 정상적으로 Build 되는지 확인하는 용도, 그리고 QA 배포와 Release 배포할 때 사용하고 있었다.

(나중에 SonarQube도 적용해서 사용할 예정이다.)

 필자가 사용하고 있던 기존의 배포 프로세스는 다음과 같았다. 먼저 QA 배포이다.

1. develop Branch로 배포할 feature들을 전부 merge한다.
2. develop Branch를 Local로 pull 받은 후 release/?.?.? 형식의 release Branch를 생성한다.
3. release Branch에서 versionCode, versionName, 출시 노트를 변경하고 Commit 한다.
4. 위 Commit에 qa/0.0.0.0 형식의 Tag를 생성하고 Tag Push한다. (마지막에 붙는 4번째 버전은 QA 배포 버전이다.)
5. Jenkins가 Tag Push를 Trigger 해서 Tag가 qa/0.0.0.0 형식인지 release/0.0.0 형식인지 구분하고 형식에 맞는 QA Deploy 혹은 Release Deploy를 진행한다.

 이렇게 1차, 2차, 3차 QA를 진행하며 qa/0.0.0.1, qa/0.0.0.2, qa/0.0.0.3 형식으로 QA 배포를 계속한다. 그러다가 QA 이슈가 더이상 나오지 않으면 Release 배포를 진행한다. Release 배포 프로세스는 다음과 같다.

1. QA 진행했던 release Branch를 pull 받는다.
2. versionCode, versionName, 출시 노트를 변경하고 Commit 한다.
3. 위 Commit에 release/0.0.0 형식의 Tag를 생성하고 Tag Push한다.
4. Jenkins가 Tag Push를 Trigger 해서 Tag가 qa/0.0.0.0 형식인지 release/0.0.0 형식인지 구분하고 형식에 맞는 QA Deploy 혹은 Release Deploy를 진행한다.

 위와 같은 배포 프로세스를 사용하고 있었는데 사용하면 할 수록 versionName, versionCode, 출시 노트 변경하고 Commit 하고 Tag Push 하는 과정이 너무 비효율적으로 느껴졌다. versionName은 프로젝트 버전 규칙에 따라 변경되니 자동화하기 힘들다고 생각했고 출시 노트 또한 자동화하기 힘들다고 생각했다. 하지만 versionCode는 자동화할 수 있을 것 같았다. 프로젝트에서 사용하는 versionCode는 년, 월, 일, 시간을 순서대로 나열하여 2022052301과 같은 정수 값을 넣고 있었다. 그래서 이를 Jenkins의 Timestamp를 이용해서 자동화할 수 있겠다고 생각했다. 그래서 정리하면 versionName과 출시 노트는 직접 입력하기, versionCode, Commit & Push, Deploy는 자동화할 수 있을 것 같았다.

 위와 같은 비효율적인 반복 작업을 해결하기 위해 현재 구현한 배포 프로세스는 다음과 같다.

1. Jenkins에 접속해서 QA Deploy에 대한 pipeline 혹은 Release Deploy에 대한 pipeline을 선택하고 Build with Parameters를 클릭한다.
2. versionName과 출시 노트를 입력하고 빌드하기를 클릭한다.

위의 2단계가 끝이다. 위와 같이 Jenkins에서 입력값과 함께 Build를 실행하면 Jenkins가 versionName, versionCode, 출시 노트를 변경하고 Commit & Push, Unit Test, Build, Deploy까지 전부 자동화 하도록 개선했다.

 개선 방법은 추후에 포스팅할 예정이다.