Release and versioning

임도형

임도형

개발 문화삽질 증오

Case 1.

일반적인 배포 프로세스

• 프로젝트 초기 커밋

SVNtrunk

pom.xml : 0.0.1-SNAPSHOT

TEST ENV

NEXUS

• 개발 진행• pom.xml 의 버전은 변경되지 않는다 .

SVNtrunk


TEST ENV

NEXUS

개발

• 개발 계속 진행• 역시 pom.xml 의 버전은 변경되지 않는다 .

SVNtrunk


TEST ENV

NEXUS

계속 개발

SVNtrunk

pom.xml : 0.0.1-SNAPSHOTbranches

0.1.xpom.xml : 0.1.1-SNAPSHOT

TEST ENV

NEXUS

• 0.1 로 배포 준비 시작• 배포 작업을 위한 branch 0.1.x 를 생성 .• 브랜치 0.1.x 의 pom 버전을 0.1.1-SNAPSHOT 으로 변경

버전 변경

브랜치 생성

SVNtrunk



TEST ENVsome-0.1.1-SNAPSHOT.jar

NEXUS

• 브랜치 0.1.x 에서 패키징 하고 테스트 환경에 설치

설치

패키징

SVNtrunk




NEXUS

• 개발 서버에서 테스트 실패 . 버그가 있다 .• 브랜치 0.1.x 에서 디버깅한다 .

테스트 실패

디버깅

SVNtrunk




NEXUS

• 브랜치 0.1.x 의 pom 의 버전을 0.1.2-SNAPSHOT 으로 변경• 다시 패키징 하고 테스트 환경에 설치

설치

버전 변경 , 패키징

SVNtrunk




NEXUS

• 테스트 성공하였다 . 배포 하자 .

테스트 성공

SVNtrunk



tags0.1.2

pom.xml : 0.1.2


NEXUS

• 브랜치 0.1.x 를 복사하여 tag 0.1.2 를 생성 .• tag 0.1.2 의 pom.xml 의 버전을 0.1.2 로 수정

태그 생성

버전 변경

SVNtrunk



tags0.1.2

pom.xml : 0.1.2


NEXUSsome-0.1.2.jar

• tag 0.1.2 에서 패키징하고 Nexus 에 업로드한다 .

패키징

업로드

SVNtrunk



tags0.1.2

pom.xml : 0.1.2


NEXUSsome-0.1.2.jar

• 브랜치 0.1.x 의 것을 trunk 로 머징 .• trunk 의 버전은 브랜치의 버전 0.1.2-SNAPSHOT 이 되었다 .

머징

SVNtrunk


0.1.xtags

0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• 배포에 사용된 브랜치 0.1.x 를 삭제 .

삭제

SVNtrunk

pom.xml : 0.1.2-SNAPSHOTbranchestags

0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• trunk 의 것으로 개발을 진행한다 .• 버전은 변경되지 않는다 .

개발

SVNtrunk

pom.xml : 0.1.2-SNAPSHOTbranchestags

0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• trunk 의 것으로 계속 개발한다 .• 이 때 trunk 의 것을 패키징하여 개발 서버에 배포하여 테스트 할수도 있다 .• 하지만 배포가 아니기에 버전관리는 고려되지 않는다 .

계속 개발

DEV serversome-0.1.2-SNAPSHOT.jar패키징 , 설치

some-0.1.2-SNAPSHOT.jar• 그냥 현재의 것을 패키징한 것이다 . 배포한 것이 아니다 .• 패키징 할 때의 소스가 확보되어 있지 않다 .

some-0.1.2.jar• 버전관리되어 배포된 것이다 .• 패키징 할때의 소스가 확보되어 있다 .(tag 0.1.2 로 )

DEV serversome-0.1.2-SNAPSHOT.jar

• 패키징되어 배포된 소스의 영구 보관을 의미 .• 그렇기 때문에 반드시 READ ONLY 이다 . • 수정도 삭제도 안된다 .

SVNtrunk

pom.xmlbranches

0.1.xtags

0.1.2

• 작업 공간을 의미 .• main 인 trunk 말고 특정 작업이 필요할 경우 생성 .• 보통 작업이 완료되면 삭제한다 .

SVNtrunk

pom.xmlbranches

0.1.xtags

0.1.2

Case 2.

특정 기능 개발을 위한 브랜치

SVNtrunk


coolpom.xml : 0.1.2-cool-SNAPSHOT

tags0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• 혹은 특정 기능 cool 의 개발을 진행할 브랜치를 생성하고 여기서 개발을 진행 .

브랜치 생성

개발

SVNtrunk



tags0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• 브랜치 cool 는 개발을 진행하며 수시로 패키징하고 개발 서버에 설치해 볼 수도 있다 .• 하지만 배포가 아니기에 버전을 수정하거나 관리하지 않는다 .

개발 , 패키징

DEV serversome-0.1.2-cool-SNAPSHOT.jar설치

SVNtrunk



tags0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• cool 브랜치에서의 개발과 별개로 , trunk 에서도 개발을 진행한다 .

개발

개발

Case 3.

배포 프로세스 , 한 번 더

SVNtrunk




tags0.1.2

TEST ENV

NEXUSsome-0.1.2.jar

• 0.2 로 배포 준비 시작• 배포 작업을 위한 branch 0.2.x 를 생성 .• 브랜치 0.2.x 의 pom 버전을 0.2.1-SNAPSHOT 으로 변경

브랜치 생성

SVNtrunk




tags0.1.2


NEXUSsome-0.1.2.jar

• 브랜치 0.2.x 에서 패키징하여 테스트 환경에 설치

패키징

설치

SVNtrunk




tags0.1.2


NEXUSsome-0.1.2.jar

• 테스트가 실패하였다 . 브랜치 0.2.x 에서 수정한다 .

디버깅

테스트 실패

SVNtrunk




tags0.1.2


NEXUSsome-0.1.2.jar

• 브랜치 0.2.x 의 pom.xml 의 버전을 0.2.2-SNAPSHOT 으로 수정 .• 다시 패키징 하여 테스트 환경에 설치

패키징

설치

SVNtrunk




tags0.1.2


NEXUSsome-0.1.2.jar

• 테스트가 계속 실패한다 . 브랜치의 버전은 계속 변경되어 0.2.9-SNAPSHOT 이 되었다 .• 이와중에 trunk 와 cool 브랜치에서는 별개의 개발이 동시에 진행되어도 무방하다 .

계속 디버깅

계속 테스트 실패

개발 진행

개발 진행

SVNtrunk




tags0.1.2


NEXUSsome-0.1.2.jar

• 0.2.10-SNAPSHOT 에서 테스트가 성공하였다 .

테스트 성공

SVNtrunk




tags0.1.20.2.10

pom.xml : 0.2.10TEST ENVNEXUS

some-0.1.2.jar

• 브랜치 0.2.x 를 복사하여 tag 0.2.10 을 생성 .• 0.2 태그의 pom.xml 의 버전을 0.2.10 로 변경 .

태그 생성

SVNtrunk




tags0.1.20.2.10


some-0.1.2.jarsome-0.2.10.jar

• 태그 0.2 에서 패키징하고 Nexus 에 업로드

SVNtrunk




tags0.1.20.2.10


some-0.1.2.jarsome-0.2.10.jar

• 브랜치 0.2.x 의 소스를 trunk 로 머징 .• trunk 의 버전은 0.2.10-SNAPSHOT 이 된다 .

머징

삭제

Case 4.

이미 배포된 버전의 핫 픽스

SVNtrunk


cool (pom.xml : 0.1.2-cool-SNAPSHOT)0.1.x

pom.xml : 0.1.2-SNAPSHOTtags

0.1.20.2.10

TEST ENV

NEXUSsome-0.1.2.jarsome-0.2.10.jar

• 배포한 0.1.2 에서 버그가 발견되었다 . 핫픽스하여 배포하여야 한다 .• tags 0.1.2 를 카피하여 브랜치 0.1.x 생성• 브랜치 0.1.x 의 pom.xml 의 버전을 0.1.2-SNAPSHOT 으로 수정

브랜치 생성

SVNtrunk



pom.xml : 0.1.3-SNAPSHOTtags

0.1.20.2.10



• 0.1.x 의 버전을 0.1.3-SNAPSHOT 으로 수정 .• 패키징하고 개발환경에 설치 .

설치

버전 수정

SVNtrunk



pom.xml : 0.1.3-SNAPSHOT.jartags

0.1.20.2.10



• 테스트 성공 .

테스트 성공

SVNtrunk



tags0.1.20.1.30.2.10

TEST ENVNEXUS

some-0.1.2.jarsome-0.1.3.jarsome-0.2.10.jar

• 브랜치 0.1.x 를 카피하여 tag 0.1.3 를 생성 . 버전을 0.1.3 으로 변경 • tag 0.1.3 에서 패키징하고 , 업로드 .• 브랜치 0.1.x 를 trunk 로 머징 . 버전은 0.2.10-SNAPSHOT 을 유지 .

업로드

머징

tag 생성

작업 브랜치 삭제

Case 5.

특정 기능의 브랜치 배포

SVNtrunk


cool (pom.xml : 0.1.2-cool-SNAPSHOT)1.0.x (pom.xml : 1.0.1-SNAPSHOT)

tags0.1.20.1.30.2.10

TEST ENVNEXUS


• 오래 개발해 오던 기능 cool 개발이 완료되었다 .• trunk 에서 복사하여 브랜치 1.0.x 를 생성• 브랜치 1.0.x 의 버전을 1.0.1-SNAPSHOT 로 변경

브랜치 생성

SVNtrunk



tags0.1.20.1.30.2.10

TEST ENVNEXUS


• 브랜치 cool 을 브랜치 1.0.x 로 머징 .

머징

SVNtrunk



tags0.1.2, 0.1.3, 0.2.10

TEST ENV1.0.1-SNAPSHOT.jar

NEXUSsome-0.1.2.jar, some-0.1.3.jar, some-0.2.10.jar

• 브랜치 1.0.x 를 패키징하고 테스트 환경에 설치 .

설치

패키징

SVNtrunk



tags0.1.2, 0.1.3, 0.2.10

TEST ENV1.0.1-SNAPSHOT.jar

NEXUSsome-0.1.2.jar, some-0.1.3.jar, some-0.2.10.jar

• 테스트가 성공하였다 .

테스트 성공

SVNtrunk



tags0.1.2, 0.1.3, 0.2.101.0.1 (pom.xml : 1.0.1)

TEST ENVNEXUS

some-0.1.2.jar, some-0.1.3.jar, some-0.2.10.jarsome-1.0.1.jar

• 브랜치 1.0.x 를 복사하여 tag 1.0.1 을 생성 . 버전을 1.0.1 으로 수정 .• 패키징하고 업로드

업로드

버전 수정 , 패키징

tag 생성

SVNtrunk



tags0.1.2, 0.1.3, 0.2.101.0.1

TEST ENVNEXUS


• 브랜치 1.0.x 를 trunk 에 머징 . trunk 의 버전은 1.0.1-SNAPSHOT 이 됨 .

머징

SVNtrunk


cool1.0.x

tags0.1.2, 0.1.3, 0.2.101.0.1

TEST ENVNEXUS


• 기능 cool 개발에 사용된 브랜치 1.0.x 를 삭제 .

두 브랜치 삭제

기타

제시된 예는 예일뿐이다 .회사마다 정책이 다르고 , 실 운영도 다르다 .• micro version 사용 여부• branch 이름• 버전에 release, rc 표기• 테스트 환경에 따른 버저닝 방법 .

‘rc’ in some-2.3.1-rc.jarRelease Candidate; 배포 후보 .alpha, beta 테스트 이후의 배포 전 단계 .

특정 버전에 대한 배포 단계를 의미1.2-a1(1st alpha test version)1.2-b1(1st beta test version)1.2-b2(2nd beta test version)1.2-rc1(1st release candidate version)1.2-rc2(2nd release candidate version)1.2-r(release version)1.2-r2(release version with another bug fixed)1.2-r3(release version with 2nd bug fixed)

some-3.5.6.jar

3 : major version. 아주 굵직한 변경 . 하위호환포기면 무조건 Major.5 : minor version. 기능 추가 .6 : micro/patch/build/revision version. 버그 픽스 , 사소한 변경 .

Software

Release and versioning