작성 계기는 이직한 회사에 입사한 지 얼마 안 된 무렵이었습니다. 저희 회사는 CI/CD를 젠킨스로 운영하는데 기존에는 배포할 때 새롭게 반영이 되었는지 확인이 안 되는 문제와 기존 이미지가 업데이트되면 만일의 비상 상황에 이전 버전으로 롤백시킬 수도 없다는 단점이 있었습니다, 물론 새롭게 반영할 때마다 젠킨스 스크립트를 수정하면 되지만 작업도 결국 사람이 하기에 버전수정을 위해 매번 스크립트를 수정 및 반영하는게 매우 번거롭고 잊어먹는 경우가 발생했습니다. 그래서 저의 사수님은 이러한 문제를 해소하고자 기존 도커로 운영 중인 애플리케이션 버전관리 체제와 버전을 태그에 붙이는 방식을 설계하라는 업무를 받았습니다.
기존에는 단순히 X.Y 버전 체제로 배포버전과 수정버전만 확인 가능했습니다. 그래서 체제를 많은 소프트웨어 회사와 프로젝트들이 사용하는 X.Y.Z (시맨틱 버저닝)을 사용하기로 했습니다.
기존에는 방식은 API를 수정하고 반영하고 추가로 젠킨스 스크립트도 변경해야 비로소 새로운 버전으로 컨테이너가 생성되었습니다. 이렇게 되니 API 수정과 별개로 젠킨스 스크립트도 수정해야 해서 좀 번거로운 부분이 있었습니다. 그래서 생각해 낸 방법은 Spring Boot Gradle의 version속성을 이용하여 버전관리를 해보자고 생각했습니다.
기존 버전관리 방식
설계한 신규 버전관리 방식
// build.gradle
version = '{버전정보 X.Y.Z}'
// 중간생략
tasks.register('{태스크 함수 명}') {
doLast {
println version
}
}
// 젠킨스 스크립트
stage('get version') {
steps {
script {
// Gradle 실행권한 부여
sh 'chmod +x ./gradlew'
// Gradle의 callVersion 태스크를 실행하여 버전 값 가져오기
def appVersion = sh(returnStdout: true, script: './gradlew -q callVersion').trim()
// 가져온 버전을 환경 변수로 설정
env.DOCKER_TAG = appVersion
}
}
}
이러한 세팅을 선임님과 CTO분께 리뷰를 하고 이 방식이 좋겠다는 피드백을 받아 이방법을 사용하기로 결정했습니다.
결과적으로 애플리케이션의 API를 수정하고 build.gradle의 version만 수정하면 별다른 작업이 필요없어졌고 나아가 더이상 소프트웨어 버전수정을 위해 젠킨스 스크립트를 수정할 필요가 없어졌기에 API 배포과정을 많이 간소화 시킬 수 있었습니다.