Semantic Versioning과 각 배포환경에서의 버전 관리에 대한 고민.
목차 펼치기
머리말
머리말
버전 관리란 S/W 개발과 관련하여
시간의 변화에 따른 변경을 관리하는 활동이다. 개발자가 Git이나 SVN과 같은 버전 관리 시스템(VCS)을 사용하는 것은 필수적인 영역이 되었으며, 문서 작업만 하더라도 파일명에 버전을 명시하고 내부에 버전에 대한 내역을 관리하는 걸 흔히 볼 수 있다. 우리는 모두 버전으로 관리되는 앱을 이용하고 있다.
VCS를 통해 자동으로 관리되는 버전이 아닌 서비스에 책정되어 나가는 버전을 관리하는 방법으로 가장 일반적인 방법은 Semantic Versioning이다.
1.0.0,
5.3.251등으로 버전을 표시하는 방식인데, 이를 사용한 많은 서비스를 이미 접해보았기 때문에 익숙한 방식일 것이다.
Semantic Versioning의 정확한 프로토콜은 어떤지, 개발 및 상용 환경에 이를 어떻게 적용하면 좋을 지 고민해보았다. 공식 문서를 토대로 작성하였으며, 관심이 있다면 길지 않으니 원문을 읽어보면 더 도움이 될 것이다.
견고하고 확장성 있는 서비스 구축
특정 상태로 완벽히 변경 가능
사용자에 서비스 수정에 대한 정보 제공
Semantic Versioning
Semantic Versioning
Gravatar의 발명가이자 GitHub의 공동 창립자인 Tom Preston-Werner 작성.
Major.Minor.Patch순으로 버전 번호를 매기는 가장 일반적인 방법
Major Version
Major Version
이전 버전과 호환되지 않는 API 변경
양수만 사용 가능
증가할 경우 Minor, Patch 버전은 0으로 초기화
Minor Version
Minor Version
이전 버전과 호환되는 방식으로 새 기능 추가
일부 기능에 대한 제거 예고
양수만 사용 가능
증가할 경우 Patch 버전은 0으로 초기화
Patch Version
Patch Version
이전 버전과 호환되는 방식으로 버그 등 수정
양수만 사용 가능
Pre-release Version
Pre-release Version
필요 시 사용
‘-’ 기호 뒤에 pre-release 버전 표기.
숫자 및 알파벳 대소문자 사용 가능.
동일 Patch Version보다 낮은 우선 순위를 가진다.
ex)
2.1.1-alpha,
2.1.1-alpha.1
Build Version
Build Version
필요 시 사용
‘+’ 기호 뒤에 build 버전 표기.
숫자 및 알파벳 대소문자 사용 가능.
동일 Patch Version보다 높은 우선 순위를 가진다.
ex)
1.0.0+120,
1.0.0+exp.sha.511,
1.0.0-alpha.1+build120
FAQ
FAQ
This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.
빠르게
1.0.0버전에서
42.0.0버전이 된다는 것은, 이전과 호환되지 않는 버전으로 41번의 배포가 나갔다는 것인데 이처럼 호환되지 않는 내용에 대해 가볍게 배포가 나가서는 안된다. 책임감 있는 개발과 미래에 대한 예측이 필요하다.
It is your responsibility as a professional developer to properly document software that is intended for use by others. Managing software complexity is a hugely important part of keeping a project efficient, and that’s hard to do if nobody knows how to use your software, or what methods are safe to call. In the long run, Semantic Versioning, and the insistence on a well defined public API can keep everyone and everything running smoothly.
다른 사람이 사용할 S/W에 대한 적절한 문서화는 전문적인 개발자의 책임이다. 또한 S/W 복잡성을 관리하는 것은 프로젝트의 효율성을 유지하는 데 매우 중요한 부분으로 장기적 관점에서 모든 사람이 모든 것을 원활하게 실행하게 될 수 있다.
As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backward compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.
혹여 호환되지 않는 버전을 Major Version이 아닌 채로 내보냈다면, Release 된 Version을 수정하는 것이 아니라 이전 버전과의 호환을 지원하는 Minor Version을 추가 개발하여 Release 하도록 한다.
No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example:
git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.
자주 보이는
v1.2.3같은 경우는 Semantic Version이 아니다. “v”는 버전 번호임을 나타내는 일반적인 방법일 뿐이며, 여기서 Semantic Version은
1.2.3이다.
배포 환경에서의 버전 관리
배포 환경에서의 버전 관리
일반적인 서비스에서 배포 환경은 크게 development, qa, stage, production이 있다.
local 환경은 개발 환경이지 배포 환경이 아니므로 제외했다.
이제 Jira나 Jenkins 등과 같은 CI/CD 배포 환경을 사용하고 있을 때, 각 환경마다 Versioning을 다르게 적용한다고 가정해보자.
CI/CD 툴에서 자동으로 책정되는
build_number값을 활용하여 development, qa, stage 환경에서 Build Version을 체크해준다.
브랜치 이름을 활용하기에는 ‘/’, ‘-’ 등 이름이 Semantic Versioning의 명명 규칙에 어긋나는 경우가 발생할 수 있어 제외하기로 하자.
1.0.0의 서비 스를
1.0.1로 배포를 준비한다고 했을 때, 다음과 같이 버전을 부여할 수 있다.
Pre-release Version은 베타 기능 등을 서비스 할 경우 책정해서 사용하면 될 것 같아 평소에는 사용할 일이 드물지 싶다.
1.0.0+dev.{build_numer}
1.0.0+qa.{build_number}
1.0.0+stage.{build_number}
1.0.1-beta.1
1.0.1
모니터링 툴을 사용할 경우
모니터링 툴을 사용할 경우
데이터독과 같은 모니터링 툴을 사용할 경우, 서비스의 버전에 따른 로그들을 필터하여 확인할 수 있으며 버전 별 성능, 오류 등에 대한 비교까지 제공해준다.
이 기능을 제대로 사용하기 위해서는 버전 관리에 대한 룰이 더욱 제대로 확립되어 있어야 한다.
참고
참고