Skip to content

#05. 버저닝 (Versioning)

Jump to bottom
Sung Yun Byeon edited this page Sep 26, 2022 · 1 revision

Target User

  • 소프트웨어 개발과 운영을 좀 더 디테일하게 알고 싶은 분
  • 혼자가 아닌 여러 사람이 함께 사용하는 소프트웨어를 개발할 때 어떻게 해야 더 잘할 수 있는지 궁금하신 분
  • 한번 배포하고 끝이 아닌, 지속적으로 배포하는 소프트웨어를 개발하시는 분
  • 흔히 말하는 버저닝의 의미와 활용이 궁금하신 분

Why you need to know

  • 지속적으로 개발하고 배포하는 소프트웨어는 배포할 때마다 엄밀히 말하면 이전과 다른 소프트웨어입니다.
  • 이전과 다르기 때문에, 이전과 다르다는 구분이 필요합니다.
  • 만약 이런 구분이 없다면, 소프트웨어 개발자와 사용자가 커뮤니케이션에 혼동이 오기 쉽습니다.
  • 이런 구분이 바로 버저닝입니다. 버저닝은 소프트웨어 업계에 일반적으로 자주 사용되는 개념이라 알아두실 필요가 있습니다.

Contents

버전이란?

먼저 버전에 대해서 이야기해봅시다.

우리는 쉽게 버전이라는 개념을 접합니다. 예를 들어, 유명한 게임인 스티크래프트도 오리지널 버전이 있고, 브루드워 버전이 있죠. 프로그래밍 언어로 사용하는 Python도 3.6, 3.7 등 여러 버전이 존재합니다. 구체적으로 설명하지 않아도, 버전에 대해서 다들 이미 경험을 하셨고, 어떤 것인지 이미 알거라 생각합니다.

제 식대로 조금 더 정의해보면, 버전은 "소프트웨어가 개발된 특정 상태에 대한 이름" 라고 생각합니다. 우리가 개발에 흔히 사용하는 Git으로 Commit을 찍게 되면, 그 소프트웨어는 개발된 어떤 특정 상태를 가진채 저장됩니다. 그리고 이는 Commit ID를 통해서 추후에 접근하거나 수정할 수 있습니다. 이 때 Commit ID 역시 일종의 버전인 셈입니다. 이 때문에 Git을 우리는 VCS(Version Control System) 도구라 부르는 것입니다.

버전을 사용하게 되면, 다음과 같은 장점이 있습니다.

  • 소프트웨어가 개발된 특정 상태를 어렵게 부르지 않고 그냥 버전으로 부를 수 있습니다.
  • 이전 버전과 현재 버전, 그리고 미래에 개발할 버전을 구분하여 표현할 수 있습니다.

버전으로 얻는 가장 큰 장점은, 소프트웨어의 개발 상태에 이름을 둠으로써 소프트웨어에 참여하게 되는 모두가 소통하기 용이해진다는 것입니다.


버저닝이란?

버저닝은 버전을 어떻게 정의할 것인가에 대한 방법입니다. 좀 더 풀어 설명하면, "소프트웨어가 개발된 특정 상태에 대한 이름을 어떻게 지을 것인가?" 에 대한 방법이라고 보시면 됩니다.

버저닝은 여러 방법이 있습니다. 기본적으로 Git을 사용한다면 Commit ID 같은 것도 버전이 될 수 있지만, 이는 너무 길기도하고 별다른 의미가 없어서 소통할 때 불편합니다. 따라서 사람들은 좀 더 버저닝에 용이한 여러 대안들을 고안했는데, 그 중에 가장 대표적인 것은 다음 두가지 입니다.

  • 시멘틱 버저닝 (Semantic Versioning)
    • 버전에서 흔히 보셨을 1.0.0 과 같은 모양을 가지고 있습니다.
    • 각 숫자는 MAJOR.MINOR.PATCH 의 의미를 가지고 있습니다.
  • 캘린더 버저닝 (Calendar Versioning)
    • Ubuntu 에서 이를 사용하는데 18.04 20.04 와 같은 버전을 보신적이 있으실겁니다.
    • 날짜를 기반으로 버저닝합니다. 위는 18년도 4월, 20년도 4월의 의미입니다.

여기서는 간단히 소개만 합니다. 버저닝에 대한 자세한 내용은 아래 페이지를 참고하시면 좋을거 같습니다.


커밋 메시지로 시멘틱 버저닝을 추론하는 방법

보통 소프트웨어 버저닝으로 시멘틱 버저닝을 많이 사용합니다. 그런데 이 시멘틱 버저닝에는 MAJOR, MINOR, PATCH 라는 명확한 규칙이 존재합니다. 이 규칙을 잘 활용하면 버전을 자연스레 추론할 수 있습니다.

Conventional Commit은 이러한 규칙을 고려하여 커밋 메시지로 버전을 추론할 수 있게하는 커밋 메시지 작성 규칙입니다. 이 규칙을 쓴다고 하면, 커밋 메시지 제목을 항상 다음과 같은 형태로 써야 합니다.

type(modify files): title message

이 때 type의 종류는 미리 정의되어 있는데, 이 중 하나인 feat 은 MINOR 버전의 올림으로, fix 는 PATCH 버전의 올림으로 추론하게 됩니다.

예를 들어 현재 상태의 버전을 0.1.0 이라 합시다. 그리고 현재 이후 여러 개발이 진행되었고, 커밋 내역이 다음과 같다고 합시다.

$ git log --oneline

* 5401667 (HEAD -> main) fix 커밋 메시지 4
* 0a54754 fix: 커밋 메시지 3
* 3ceeb86 fix: 커밋 메시지 2
* a95c036 feat: 커밋 메시지 1 (0.1.0)

이제 이 소프트웨어에 대하여 시멘틱 버저닝으로 버전을 남기고 싶습니다. 그럼 이 때 0.1.0 버전 이후 3개의 fix 타입의 커밋 메시지 밖에 없기 때문에 자연스럽게 0.1.1 로 버전을 추론할 수 있습니다.

이처럼 Conventional Commit 규칙으로 커밋 메시지를 작성하게 되면, 시멘틱 버전을 자연스럽게 추론할 수 있습니다.

여기서는 간단히 소개만 합니다. 더 자세한 내용은 아래 공식 페이지를 읽어보세요.


커밋 메시지로 시멘틱 버저닝을 자동화하는 방법

위처럼 Conventional Commit 규칙을 사용하면 시멘틱 버전을 추론하는 걸 넘어 버전을 자동화할 수 있습니다. 마지막 버전 이후의 모든 커밋 메시지를 가져와 파싱한 뒤 메시지 내 type 가지고 버전을 추론하는 과정을 자동화한다면 말이죠.

이러한 자동화를 도와주는 도구가 있는데, 이에 대한 내용은 다음을 참고하세요.

Home

효율적으로 일하기

Software 개발

MLOps

Streamlit

실습

Clone this wiki locally