파란하늘의 지식창고
article thumbnail
반응형

이 방법이 좋은 방법인지는 잘 모르겠다.

snapshot 버전으로 매번 빌드하여 프로젝트를 개발하는데 배포 시점에는 release 배포를 해야 한다는 요구사항이 있었다.

매번 release로 변경하는 과정을 수작업으로 하면 불편하기 때문에 jenkins에서 처리하려고 하였다.

또한 개발은 git develop branch에서 진행하고 배포 시엔 master branch로 merge 하려고 한다.

정리하면 다음 요구사항을 수행한다.

  1. develop branch를 master branch로 merge
  2. version 변경
  3. property 값 변경
  4. deploy 수행

스크립트로 작성하면 대략 다음과 같다.

git merge/develop
mvn versions:set -DnewVersion=${BUILD_NUMBER}
mvn versions:set-property -Dproperty=bluesky-boot.version -DnewVersion=${BUILD_NUMBER}
mvn deploy -DskipTests

배포를 위한 버전 변경에 대해서는 git으로 다시 push 처리는 하지 않았다.

(필요에 따라 결정하면 될 부분이다.)

위에선 단순히 jenkins의 BUILD_NUMBER를 release 버전으로 썼지만 1.0.${BUILD_NUMBER}처럼 patch 버전으로도 사용하거나 date 정보로 버전 처리를 할 수도 있을 것이다.

쉘 스크립트 상에서 BUILD_NUMBER가 아닌 빌드된 날짜 기준으로 만들고 싶은 경우는 아래 변수를 사용하면 된다.

git merge/develop
mvn versions:set -DnewVersion=`date +"%Y%m%d%H%M"`
mvn versions:set-property -Dproperty=bluesky-boot.version -DnewVersion=`date +"%Y%m%d%H%M"`
mvn deploy -DskipTests

단순하게 ${BUILD_NUMBER} 나 date format을 사용하였지만 다양하게 조합해서 원하는 형태의 버전을 사용할 수 있다.

여기까지의 설정은 develop -> master를 수작업 없이 사용하는 방법에 대한 것이다.

git의 branc를 어떻게 사용하면 좋은가에 대해서는 오래전부터 아래 형태의 사용이 제안되어 왔다.

nvie.com/posts/a-successful-git-branching-model/

 

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

nvie.com

무조건 develop -> master merge를 하는 것보단 hotfix나 release branch를 merge 처리할 수 있도록 더 세밀하게 옵션을 추가하고 배포 후 git에 tag를 지정하고 push 하는 형태로 다듬어 사용하는 게 정석적인 방법이다.

하지만 굳이 이렇게 까지 사용하지 않아도 되는 프로젝트의 경우 굳이 복잡도를 높일 필요 없이 처음 소개한 간단한 형태로 사용하는 게 좋지 않을까 싶다.

 

반응형
profile

파란하늘의 지식창고

@Bluesky_

내용이 유익했다면 광고 배너를 클릭 해주세요