Versioning Strategies in Enterprise Software

Don’t SemVer
엔터프라이즈 소프트웨어에서의 Versioning

Patch Version
• 이전 버전과 인터페이스는 완전히 동일함
• 버그 수정이 있을 때 올라가는 버전
• v2.6.1은 v2.6.0의 버그만 수정한 버전을 의미함
• (버그를 제외하고) v2.6.1과 v2.6.0의 동작은 완전히 동일해야한다.

Patch Version
기능 A
기능 B 🪲
v2.6.0
기능 A
기능 B
v2.6.1
버그 수정

Minor Version
• 이전 버전과 호환되는 인터페이스
• 새로운 API가 추가되었을 때 올라가는 버전
• 2.7.x 은 2.6.x와 호환되며 2.6.x에는 없는 새로운 API를 포함

Minor Version
기능 A
기능 B
v2.6.3
기능 A
기능 B
v2.7.0
기능 추가
새로운 기능
기능 C

Major Version
• 이전 버전과 호환되지 않는 API
• API가 변경 / 삭제 되었을 때 올라가는 버전
• v2.6.0과 v3.0.0

Major Version
v2.6.0
기능 B
v3.0.0
Breaking
Changes
기능 C
기능 A
기능 B
기능 C
Interface 변화
기능 A’
제거

Semantic Versioning
• 약속을 기반으로 함
• 오픈소스 커뮤니티를 위한 디자인
• 라이브러리 설계에서 가장 널리 쓰이는 버저닝 기법
• 문서화된 내용에 대해서만 보장

Versioning의 목적
End-User Application
Version 1 Version 2 Version 3 Version 4 Version 5 Version 6 Version 7
지원범위
지원하지 않는 범위

User의 선택지
Semantic Versioing이라면?
v1.0.0
v1.0.1
v1.1.0 v1.1.1
2.0.0
신규 기능
버그 수정
버그 수정
Breaking Changes (??)
?????

User의 선택지
v1.0.0
v1.0.1
v1.1.0 v1.1.1
2.0.0
신규 기능
버그 수정
버그 수정
?????
사용자에겐 이런 선택지가 없다!

User의 선택지
v1.0.0
v1.0.1
v1.1.0 v1.1.1
2.0.0
신규 기능
버그 수정
버그 수정
?????
Breaking Changes가 있는데
같은 소프트웨어의 다른 버전이라할 수 있을까?

User의 선택지
v1.0.0
v1.0.1
v1.1.0 v1.1.1
2.0.0
신규 기능
버그 수정
버그 수정
?????
모순 그 자체

이 버전을 언제까지 사용할 수 있을까?
• 버그픽스만 있는 버전을 따로 내줄 수
없다
• 언제까지나 구버전을 지원해줄 수 없
다
• 선형적인 버저닝만 가능하다
User의 관심사 (1)
업데이트가 싫어!

2.0이 나왔다고? 그래서?
• 대규모 개편이 있을때 Major 버전을
올림
• 유저 입장에선 같은 앱일뿐이다
• 2.0이 나왔는데 유저는 1.0을 계속 쓰
게 해줄거라고요? 정말?
• Major 업데이트는 대규모 개편을 할
개발팀의 세레머니일뿐
User의 관심사 (2)
Instagram 2.0 출시!
1.0은 어디가고?

How-To Version
End-User Application
• 그럼에도 앱스토어는 SemVer를 강제한다.
• SemVer의 개념을 따라갈 필요가 없다.
• 선형적인 변화만 주면 충분하다
• Major 버전 올리기 세레머니를 해도 좋다. 개발팀의 사기가 높아진다면야!

How-To Version
Release Train에서
• Release Train에선 매주 고정된 날짜에 배포를 한다.
• 해당 열차에 문제가 있을 때 핫픽스를 낼 수 있다.

How-To Version
Release Train에서
버그발견!
🪲
v1.12.1
Hot
fi
x
v1.10.0
10월 첫째 주
🚃
v1.11.0
10월 둘째 주
🚃
v1.12.0
10월 셋째 주
🚃
v1.13.0
10월 넷째 주
🚃

How-To Version
비정기 릴리즈에서
v2022.9.23
버그a 픽스
기능A 추가
v2022.10.2
기능B 추가
v2022.10.13
버그c 픽스
v2022.10.20
버그d 픽스
기능C 추가

How-To Version
비정기 릴리즈에서 (Major 버전을 유지하고 싶다면)
v1.22.13
2022년 13번째 릴리즈
v1.22.14
V1.22.15
v2.22.1
v2 릴리즈

How-To Version
버저닝에 관심을 두고싶지 않다면
v0.3.14 v0.3.141 v0.3.1415 v0.3.14159 v0.3.141592

Don’t SemVer
in End-User Application
• 맞지 않는 옷을 입지 말자!
• 이번 릴리즈가 버그픽스인지, 신규기능 추가인지 고민하는건 시간낭비
• 더 자주, 더 빠르게 릴리즈하는데에 방해만 될뿐이다
• 버전에 분기를 만들 이유가 없다, 물론 만들 방법도 없지만
• 유저는 버전에 관심이 없다는걸 기억하자

Server-Side Application
이전 릴리즈 현재 릴리즈 릴리즈 후보

릴리즈

롤백

• 릴리즈의 히스토리를 남기는것이 주 목적이다.
• 다음 릴리즈, 롤백포인트를 지정하기 위해서 버저닝을 한다.
• Major 버전을 올리는 세레머니는 사기 진작도 안되고 아무 의미 없다.
• SemVer를 강요하는 빅브라더도 존재하지 않는다.

How-To Version
Timestamp 전략
20220923
2022년 9월 23일 릴리즈
20220924
2022년 9월 24일 릴리즈
20220924.1
2022년 9월 24일의 두번째 릴리즈
20220925
2022년 9월 25일 릴리즈

How-To Version
Timestamp 전략
• SemVer에서 하는 고민을 일체 할 필요가 없다
• 언제 배포했는지 기억하기 쉽다.
• 버전 넘버에 대해 크게 고민할 필요가 없다
• 하루에 배포가 많이 일어나지 않을때 적절하다

How-To Version
Build Number 전략
1021
1021번째 릴리즈
1022
1023
1024

How-To Version
Build Number 전략
• 버저닝에 아무런 관심을 두지 않는다.
• 빌드 넘버를 생성하는 도구에 의존하면 된다.
• 하지만 여전히 배포 순서는 쉽게 알 수 있다.
• 하루에도 몇 번 씩 배포가 일어나는 소프트웨어에 유용하다.

Don’t SemVer
in Server-Side Application
• 서버사이드 릴리즈는 Semantic Versioning의 Lifecycle과 전혀 일치하지 않는다.
• 버그픽스, Breaking Changes, 기능추가 고민은 비즈니스 로직 레벨에서만 하자.
• 우리는 선형적인 버전만 신경쓰면 된다.
• 버저닝에 대한 불필요한 고민은 빠른 Delivery에 방해물일 뿐이다.

SemVer에서의 약속들
• Major Version - Breaking Change를 포함하면 반드시 올라간다.
• Minor Version - Breaking Change를 포함하지 않는다.
• Patch Version - 새로운 기능을 포함하지 않는다.

현실은? - go-pkg에서의 사례
• 기존에 있는 도구를 제거함
• Major Version이 올라가야하는 릴리
즈
• 하지만 util.Set 의존성은 이미 지워져
서 영향 받는곳이 없었음

• 새로운 기능이 추가됨
• Minor Version이 올라가야하는 릴리
즈
• 사실 버전엔 아무도 관심이 없었다

• 버그픽스, 신규기능 등 여러 요소가 섞
여있음
• Patch Version과 Minor Version을
올리는 릴리즈로 나눠야 했다.
• 굳이 나눠서 올리는게 합리적일까?

문서화 되지 않은 기능
Fizz()
Buzz()
class Foo
Fizz()
Buzz()
class Foo
Major Version
Update(?)
문서화 된 기능
문서화 되지
않은 기능
제거

문서화 되지 않은 기능
• 문서화 되지 않은 기능이라도 있으면 사용한다.
• 의도하지 않은 기능도 문서화 되지 않은 기능의 일종이다.
• 내가 약속하지 않은 기능이라고요? 그로 인한 장애가 나는 회사는 내가 일하는 그곳입니
다.
• 지켜질 수 없는 약속은 무의미하다.
• Breaking Changes에 대한 책임은 변화를 만드는 사람에게 있다.

SemVer의 문제점
• Breaking Changes를 만드는데에 보수적이 될 수 밖에 없다.
• 사용하는 입장에선 버전을 올리고 싶지 않다.
• 모든 기능은 필요하기에 만드는것이다. 버전은 항상 최신으로 유지해야한다.
• 우리는 오픈소스 컨트리뷰트를 하는것이 아니다

How-To Version
만들지 않는다
• 책임을 질 수 없다면 In-house 라이브러리를 만들지 않는다.
• 라이브러리를 만든 사람이 사용하는 사람의 코드베이스를 수정할 수 있는 문화가 필요하
다.
• 그렇지 못하다면 In-house 라이브러리는 독이다.

How-To Version
One-Version 원칙
• In-house 라이브러리는 최신 버전 하나의 버전만 유지한다.
• 모두가 In-house 라이브러리를 항상 최신버전을 사용하도록 보장한다.
• Breaking Change에 대한 검증과 대응은 변화를 만드는 사람이 직접 해결한다.

How-To Version
One-Version 원칙 - 버저닝 없는 의존성
Library v33
Application A
Application B
의존성

How-To Version
Library v33
Application A
Application B
의존성
Library v34
Breaking Changes

How-To Version
Library v33
Application A
Application B
의존성
Library v34
Breaking Changes
(릴리즈 불가능)
v34 대응 완료

How-To Version
Library v33
Application A
Application B
의존성
Library v34
Breaking Changes
(릴리즈 가능)
v34 대응 완료
v34 대응 완료

How-To Version
Library v33
Application A
Application B
의존성
Library v34
v34 대응 완료
v34 대응 완료

How-To Version
One-Version 원칙 - Mono repo에서의 적용
root
libs apps
library-a app-a app-b

How-To Version
root
libs apps
Breaking Changes ☠ CI 실패 ☠ CI 실패
Pull Request (Merge 불가능)

How-To Version
root
libs apps
Breaking Changes
Breaking
Changes 대응
Breaking
Changes 대응
Pull Request (Merge 가능)

How-To Version
• Application이 의존성을 직접 빌드한다.
• 버전이 없으니 라이브러리 릴리즈 절차가 필요 없다.
• 패키지 Registry를 운영할 필요가 없어진다. (사설 PyPI, Sonatype Nexus 등등)
• 라이브러리에 대한 의존성을 가진 App들에게 가는 영향을 즉시 파악할 수 있다.
• 각 컴포넌트들이 테스트를 충분히 작성한다는 조직적 합의가 필요하다.

Don’t SemVer
in In-house Library
• 여러 버전을 제공하는 In-house Library는 불필요한 짐일 뿐이다.
• 릴리즈만 던져놓고 다른 동료에게 업데이트 책임을 미루지 말고 직접 업데이트 해주자!
• SemVer는 의존성을 사용하는 쪽에 업데이트 책임을 지우는 전략이다.
• 책임질 수 없는 도구는 만들지도 말자.
• Mono repo는 인하우스 도구 제공을 위한 최고의 솔루션이다.

Versioning Strategies in Enterprise Software

More Related Content

Similar to Versioning Strategies in Enterprise Software

Versioning Strategies in Enterprise Software