<div id="readability-page-1" class="page"><div>
<blockquote>
<p>소프트웨어<em> </em>개발에서<em> </em>버전<em> </em>관리와<em> </em>릴리스<em> </em>프로세스는<em> </em>필수적이지만<em>, SW </em>엔지니어링이<em> </em>충분히<em> </em>성숙하지<em> </em>못하였던<em> </em>시절에<em> </em>이는 꽤나<em> </em>골치<em> </em>아픈<em> </em>작업으로<em> </em>여겨졌다<em>. Semantic Versioning </em>과<em> Conventional Commit</em>는 널리 알려진 릴리즈와 버저닝 전략이기에 프로덕션 레벨의 소프트웨어 릴리즈 관리에 관심이 있다면 한 번 쯤 들어봤을 것이다. 이 글은 SemVer와 Conventional Commit 을 이용하여 CI 단계에서 릴리즈와 버저닝을 자동화하는 구글의 Release Please를 소개하고, <em>GitHub Actions</em>를 이용하여 프로젝트에 적용하는<em> </em>방법을<em> </em>소개한다<em>.</em></p>
</blockquote>



<h2>뭔가 많이 바뀐 것 같으니 2.0이라고 할게요</h2>



<figure><img data-recalc-dims="1" decoding="async" width="382" height="190" data-attachment-id="2143" data-permalink="https://01010011.blog/2024/10/05/conventional-commit%ea%b3%bc-semantic-versioning-%ea%b7%bc%eb%8d%b0-%ec%9d%b4%ec%a0%9c-release-please-actions%eb%a5%bc-%ea%b3%81%eb%93%a4%ec%9d%b8/image-30/" data-orig-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/09/image-2.png?fit=382%2C190&amp;ssl=1" data-orig-size="382,190" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="image" data-image-description="" data-image-caption="" data-medium-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/09/image-2.png?fit=300%2C149&amp;ssl=1" data-large-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/09/image-2.png?fit=382%2C190&amp;ssl=1" tabindex="0" role="button" src="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/09/image-2.png?resize=382%2C190&amp;ssl=1" alt="" sizes="(max-width: 382px) 100vw, 382px"></figure>



<p>소프트웨어 버저닝 체계가 갖춰지지 않았던 시절, 버전 넘버는 퍼스널 컬러처럼 그날의 개발자 기분에 따라 정성적으로 정해졌다. <br>뭔가 많이 바뀐 것 같은 느낌이 들면 2.0, 별로 한게 없다는 생각이 들어서 1.1, <br>바뀌긴 바꼈는데 임시로 떼운 코드라 넘버링을 하고 싶지 않으면 1.0-a, <br>근데 또 어떤 날은 버전명에 의미를 담고 싶어서 1.0-a-opengl-windows-x64, <br>이전 릴리즈랑 다르게 이름붙여야 해서 git hash를 곁들인 1.0-a-f917bc …</p>



<figure><img data-recalc-dims="1" decoding="async" width="1024" height="666" data-attachment-id="2152" data-permalink="https://01010011.blog/2024/10/05/conventional-commit%ea%b3%bc-semantic-versioning-%ea%b7%bc%eb%8d%b0-%ec%9d%b4%ec%a0%9c-release-please-actions%eb%a5%bc-%ea%b3%81%eb%93%a4%ec%9d%b8/image-32/" data-orig-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-1.png?fit=1280%2C833&amp;ssl=1" data-orig-size="1280,833" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="image" data-image-description="" data-image-caption="" data-medium-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-1.png?fit=300%2C195&amp;ssl=1" data-large-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-1.png?fit=1024%2C666&amp;ssl=1" tabindex="0" role="button" src="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-1.png?resize=1024%2C666&amp;ssl=1" alt="" sizes="(max-width: 1000px) 100vw, 1000px"><figcaption>출처: 침하하</figcaption></figure>



<p>이런 ad-hoc 한 버전 정보는 사용자에게 ‘뭔가 바꼈구나’라는 것 외에는 어떤 유용함도 제공하지 않는다. ad-hoc versioning의 진짜 문제는 의존성을 관리할 때 발생한다. 1.0-a 를 1.0-opengl-f917bc 로 변경할 때 의존성 문제가 발생하는지 여부는 오롯이 라이브러리를 가져다 쓴 사용자가 책임져야 한다.</p>



<h2>SemVer : 버전 정보에 의미를 담다</h2>



<figure><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="578" data-attachment-id="2146" data-permalink="https://01010011.blog/2024/10/05/conventional-commit%ea%b3%bc-semantic-versioning-%ea%b7%bc%eb%8d%b0-%ec%9d%b4%ec%a0%9c-release-please-actions%eb%a5%bc-%ea%b3%81%eb%93%a4%ec%9d%b8/image-31/" data-orig-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image.png?fit=1408%2C795&amp;ssl=1" data-orig-size="1408,795" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="image" data-image-description="" data-image-caption="" data-medium-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image.png?fit=300%2C169&amp;ssl=1" data-large-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image.png?fit=1024%2C578&amp;ssl=1" tabindex="0" role="button" src="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image.png?resize=1024%2C578&amp;ssl=1" alt="" sizes="(max-width: 1000px) 100vw, 1000px"><figcaption>출처: devopsschool.com</figcaption></figure>



<p>2011년 9월, GitHub의 공동 창업자 Tom Preston-Werner는 Semantic Versioning(이하 SemVer) Spec 1.0.0을 공개했다. SemVer와 이전의 버저닝 규칙과의 분명한 차이점은 버전 정보 만으로도 이전 버전과의 호환성 여부를 판별할 수 있게 되었다는 것이다. 이는 자동화 관점에서 매우 중요하다. 왜냐하면 의존성 관리를 자동화할 수 있기 때문이다.</p>



<h3>버전 증가 규칙</h3>



<ol>
<li>MAJOR 버전
<ul>
<li>이전 버전과&nbsp;호환되지 않는 API 변경&nbsp;시 증가</li>
</ul>
</li>



<li>MINOR 버전
<ul>
<li>이전 버전과&nbsp;호환되는 기능 추가 시 증가</li>



<li>PATCH를&nbsp;0으로 초기화</li>
</ul>
</li>



<li>PATCH 버전
<ul>
<li>이전 버전과 호환되는&nbsp;버그 수정 시 증가</li>
</ul>
</li>
</ol>



<p>MAJOR.MINOR.PATCH 규칙 외에도 Pre-Release 규칙(하이픈 -)이라던지 메타데이터 규칙(더하기+) 등 몇 가지 세세한 규칙이 있는데, 자세한 것은 SemVer 2 스펙을 확인하자.(링크: <a href="https://semver.org/lang/ko/">https://semver.org/lang/ko/</a>)</p>



<h2>Conventional Commit : 사람도 기계도 모두 이해할 수 있는 커밋 메세지</h2>



<figure><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="574" data-attachment-id="2155" data-permalink="https://01010011.blog/2024/10/05/conventional-commit%ea%b3%bc-semantic-versioning-%ea%b7%bc%eb%8d%b0-%ec%9d%b4%ec%a0%9c-release-please-actions%eb%a5%bc-%ea%b3%81%eb%93%a4%ec%9d%b8/human_machine/" data-orig-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/human_machine.png?fit=2912%2C1632&amp;ssl=1" data-orig-size="2912,1632" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="human_machine" data-image-description="" data-image-caption="" data-medium-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/human_machine.png?fit=300%2C168&amp;ssl=1" data-large-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/human_machine.png?fit=1024%2C574&amp;ssl=1" tabindex="0" role="button" src="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/human_machine.png?resize=1024%2C574&amp;ssl=1" alt="" sizes="(max-width: 1000px) 100vw, 1000px"></figure>



<p>앞서 SemVer가 호환성에 영향을 주는 변경을 추적하는 규칙임을 설명하였는데, 현대 소프트웨어 개발에서 변경의 최소 단위는 commit이라 할 수 있다. 여러 개발자의 commit 이력이 모여 소프트웨어 릴리즈의 변경사항을 구성한다면, commit message에도 SemVer처럼 작성 규칙을 정해둘 수 있지 않을까?</p>



<p>Angular 프로젝트는 Change log를 자동 생성하기 위해 <a href="https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines">Commit Message Guidelines</a> 를 제안하였고, 이는 Conventional Commit 표준에 큰 영향을 주었다.</p>



<pre data-enlighter-language="generic" data-enlighter-theme="" data-enlighter-highlight="" data-enlighter-linenumbers="" data-enlighter-lineoffset="" data-enlighter-title="" data-enlighter-group="">&lt;타입&gt;[적용 범위(선택 사항)]: &lt;설명&gt;
&lt; 빈 칸 &gt;
[본문(선택 사항)]
&lt;빈 칸&gt;
[꼬리말(선택 사항)]</pre>



<p>Angular 포맷에 많은 영향을 받은 탓인지, Angular 포맷과 Conventional Commit 의 커밋 메세지 구조는 거의 비슷하다. 메세지 헤더에 해당 커밋의 타입이 무엇인지( fix / feature / BREAKING CHANGE 등등…) 기술하고 공백 라인을 추가한 후, 구체적인 내용을 작성하는 구조이다. 경우에 따라 꼬리말(=footer)을 작성하거나 생략할 수 있다.</p>



<p>Conventional Commit 과 Angular 포맷의 결정적인 차이는 의무화되는 커밋 타입의 종류가 얼마나 많은지 여부이다. 상술하였듯, 커밋 메세지 포맷을 구조화하는 가장 큰 목적은 호환성에 영향을 주는 변경을 추적하기 위함이다. 따라서 다음 3가지 type 외에 나머지는 반드시 지켜야 하는 커밋 타입이 아니다.</p>



<ul>
<li>feat: (=MINOR)</li>



<li>fix: (=PATCH)</li>



<li>BREAKING CHANGE: (=MAJOR)</li>
</ul>



<pre data-enlighter-language="generic" data-enlighter-theme="" data-enlighter-highlight="" data-enlighter-linenumbers="" data-enlighter-lineoffset="" data-enlighter-title="" data-enlighter-group="">fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123</pre>



<p>프로젝트에 Conventional Commit 규칙을 도입하였을 때 가장 좋은 점은 릴리즈 버저닝과 Change log 생성을 자동화할 수 있다는 것이다.<br>PR을 머지하는 시점에 우리는 어떤 커밋 이력이 이번 릴리즈에 포함되어 있는지 정확히 파악할 수 있다.</p>



<ul>
<li>Commit log 헤더가 &lt;fix:&gt; 로 시작한다면, PATCH 버전을 올린다.</li>



<li>Commit log 헤더가 &lt;feature:&gt; 로 시작한다면, MINOR 버전을 올린다.</li>



<li>Commit log footer가 &lt;BREAKING CHANGE:&gt; 로 시작하거나 타입 뒤에 !표기가 있다면, MAJOR 버전을 올린다.</li>
</ul>







<h2>근데 이제 Release Please Actions를 곁들인…</h2>



<p>많은 오픈소스 프로젝트에서 Conventional Commit 과 SemVer 규칙을 따르기 때문에 익숙한 내용이었을 것으로 생각한다. 필자가 소개하려는 도구는 Google에서 제공하는 Release Please이다. (링크: <a href="https://github.com/googleapis/release-please">https://github.com/googleapis/release-please</a>) Conventional Commit 규칙을 따르는 프로젝트의 CHANGELOG와 SemVer 규칙에 맞는 Bump up을 자동화해주는 유용한 도구다. 특히 GitHub Actions 와 함께 사용하면 프로덕션 레벨의 소프트웨어 릴리즈 관리를 자동화할 수 있다.<br>(공식적으로도 <a href="https://github.com/googleapis/release-please?tab=readme-ov-file#github-action-recommended">GitHub Actions를 추천</a>한다. 하지만 CLI 와 GitHub App도 지원을 한다.)</p>



<p>Release Please 의 기본 설정대로 구성하였을 때의 플로우는 다음과 같다.</p>



<figure><img data-recalc-dims="1" loading="lazy" decoding="async" width="1024" height="483" data-attachment-id="2171" data-permalink="https://01010011.blog/2024/10/05/conventional-commit%ea%b3%bc-semantic-versioning-%ea%b7%bc%eb%8d%b0-%ec%9d%b4%ec%a0%9c-release-please-actions%eb%a5%bc-%ea%b3%81%eb%93%a4%ec%9d%b8/image-34/" data-orig-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-3.png?fit=1396%2C658&amp;ssl=1" data-orig-size="1396,658" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="image" data-image-description="" data-image-caption="" data-medium-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-3.png?fit=300%2C141&amp;ssl=1" data-large-file="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-3.png?fit=1024%2C483&amp;ssl=1" tabindex="0" role="button" src="https://i0.wp.com/01010011.blog/wp-content/uploads/2024/10/image-3.png?resize=1024%2C483&amp;ssl=1" alt="" sizes="(max-width: 1000px) 100vw, 1000px"><figcaption>Release Please 봇이 생성한 Release PR</figcaption></figure>



<ol>
<li><strong>PR 생성(from 개발자)</strong> → 리뷰 후 Approve → main 브랜치에 머지</li>



<li><strong>Release PR 생성(from 봇)</strong>  → main 브랜치에 머지
<ul>
<li>Release PR에는 version tag, CHANGELOG 등의 정보가 포함</li>



<li>추가적으로 다른 필요한 동작을 설정할 수도 있음(e.g. docker registry push 등)</li>
</ul>
</li>



<li><strong>Release 생성</strong> → Bump up 된 버전 tag 와 CHANGELOG 등을 바탕으로</li>
</ol>



<p>특히, 잘 알려진 언어 / 패키지 매니저는 쓰기 편하도록 release-type을 지정하여 버전 정보를 관리할 수 있다.(e.g. nodejs를 쓰는 경우 package.json 정보도 함께 자동 갱신)<br>다음은 지원하는 언어 / release-type 목록이다.(링크: <a href="https://github.com/googleapis/release-please-action?tab=readme-ov-file#release-types-supported">https://github.com/googleapis/release-please-action?tab=readme-ov-file#release-types-supported</a>)</p>



<figure><table><thead><tr><th>release type</th><th>description</th></tr></thead><tbody><tr><td><code>dart</code></td><td>A repository with a pubspec.yaml and a CHANGELOG.md</td></tr><tr><td><code>elixir</code></td><td>An elixir repository with a mix.exs and a CHANGELOG.md</td></tr><tr><td><code>expo</code></td><td>An Expo based React Native repository, with a package.json, app.json and CHANGELOG.md</td></tr><tr><td><code>go</code></td><td>Go repository, with a CHANGELOG.md</td></tr><tr><td><code>helm</code></td><td>A helm chart repository with a Chart.yaml and a CHANGELOG.md</td></tr><tr><td><code>java</code></td><td><a href="https://github.com/googleapis/release-please/blob/main/docs/java.md">A strategy that generates SNAPSHOT version after each release</a></td></tr><tr><td><code>krm-blueprint</code></td><td><a href="https://github.com/GoogleCloudPlatform/blueprints/tree/main/catalog/project">A kpt package, with 1 or more KRM files and a CHANGELOG.md</a></td></tr><tr><td><code>maven</code></td><td><a href="https://github.com/googleapis/release-please/blob/main/docs/java.md">Strategy for Maven projects, generates SNAPSHOT version after each release and updates&nbsp;<code>pom.xml</code>&nbsp;automatically</a></td></tr><tr><td><code>node</code></td><td><a href="https://github.com/yargs/yargs">A Node.js repository, with a package.json and CHANGELOG.md</a></td></tr><tr><td><code>ocaml</code></td><td><a href="https://github.com/grain-lang/binaryen.ml">An OCaml repository, containing 1 or more opam or esy files and a CHANGELOG.md</a></td></tr><tr><td><code>python</code></td><td><a href="https://github.com/googleapis/python-storage">A Python repository, with a setup.py, setup.cfg, version.py and CHANGELOG.md</a>&nbsp;and optionally a pyproject.toml and a &lt;project&gt;/__init__.py</td></tr><tr><td><code>php</code></td><td><a href="https://github.com/setnemo/asterisk-notation">A php composer package with composer.json and CHANGELOG.md</a></td></tr><tr><td><code>ruby</code></td><td><a href="https://github.com/google/google-id-token">A Ruby repository, with version.rb and CHANGELOG.md</a></td></tr><tr><td><code>rust</code></td><td>A Rust repository, with a Cargo.toml (either as a crate or workspace) and a CHANGELOG.md</td></tr><tr><td><code>sfdx</code></td><td>A repository with a&nbsp;<a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm">sfdx-project.json</a>&nbsp;and a CHANGELOG.md</td></tr><tr><td><code>simple</code></td><td><a href="https://github.com/googleapis/gapic-generator">A repository with a version.txt and a CHANGELOG.md</a></td></tr><tr><td><code>terraform-module</code></td><td><a href="https://github.com/terraform-google-modules/terraform-google-project-factory">A terraform module, with a version in the README.md, and a CHANGELOG.md</a></td></tr></tbody></table></figure>



<p>Releas Please는 잘 만들어진 도구답게, 워크플로우 단계의 꽤 많은 것들을 커스터마이즈할 수 있다.<br>하지만 기본적인 워크플로우 및 제공되는 기능으로도 충분하다.</p>



<h2>결론</h2>



<p>지금까지 소프트웨어 릴리즈 및 버저닝을 위한 SemVer와 Conventional Commit을 알아보고, 이를 통해 릴리즈 관리를 자동화할 수 있는 도구인 Release Please 를 알아보았다.<br>프로덕션 레벨로 소프트웨어 릴리즈 관리를 하고 싶은 분들에게 도움이 되었으면 한다.</p>




</div></div>

01010011

소프트웨어 개발에서 버전 관리와 릴리스 프로세스는 필수적이지만, SW 엔지니어링이 충분히 성숙하지 못하였던 시절에 이는 꽤나 골치 아픈 작업으로 여겨졌다. Semantic Versioning 과 Conventional Commit는 널리 알려진 릴리즈와 버저닝 전략이기에 프로덕션 레벨의 소프트웨어 릴리즈 관리에 관심이 있다면 한 번 쯤 들어봤을 것이다. 이 글은 SemVer와 Conventional Commit 을 이용하여 CI 단계에서 릴리즈와 버저닝을 자동화하는 구글의 Release Please를 소개하고, GitHub Actions를 이용하여 프로젝트에 적용하는 방법을 소개한다.
뭔가 많이 바뀐 것 같으니 2.0이라고 할게요
소프트웨어 버저닝 체계가 갖춰지지 않았던 시절, 버전 넘버는 퍼스널 컬러처럼 그날의 개발자 기분에 따라 정성적으로 정해졌다. 
뭔가 많이 바뀐 것 같은 느낌이 들면 2.0, 별로 한게 없다는 생각이 들어서 1.1, 
바뀌긴 바꼈는데 임시로 떼운 코드라 넘버링을 하고 싶지 않으면 1.0-a, 
근데 또 어떤 날은 버전명에 의미를 담고 싶어서 1.0-a-opengl-windows-x64, 
이전 릴리즈랑 다르게 이름붙여야 해서 git hash를 곁들인 1.0-a-f917bc …
이런 ad-hoc 한 버전 정보는 사용자에게 ‘뭔가 바꼈구나’라는 것 외에는 어떤 유용함도 제공하지 않는다. ad-hoc versioning의 진짜 문제는 의존성을 관리할 때 발생한다. 1.0-a 를 1.0-opengl-f917bc 로 변경할 때 의존성 문제가 발생하는지 여부는 오롯이 라이브러리를 가져다 쓴 사용자가 책임져야 한다.
SemVer : 버전 정보에 의미를 담다
2011년 9월, GitHub의 공동 창업자 Tom Preston-Werner는 Semantic Versioning(이하 SemVer) Spec 1.0.0을 공개했다. SemVer와 이전의 버저닝 규칙과의 분명한 차이점은 버전 정보 만으로도 이전 버전과의 호환성 여부를 판별할 수 있게 되었다는 것이다. 이는 자동화 관점에서 매우 중요하다. 왜냐하면 의존성 관리를 자동화할 수 있기 때문이다.
버전 증가 규칙
MAJOR 버전
이전 버전과 호환되지 않는 API 변경 시 증가
MINOR 버전
이전 버전과 호환되는 기능 추가 시 증가
PATCH를 0으로 초기화
PATCH 버전
이전 버전과 호환되는 버그 수정 시 증가
MAJOR.MINOR.PATCH 규칙 외에도 Pre-Release 규칙(하이픈 -)이라던지 메타데이터 규칙(더하기+) 등 몇 가지 세세한 규칙이 있는데, 자세한 것은 SemVer 2 스펙을 확인하자.(링크: https://semver.org/lang/ko/)
Conventional Commit : 사람도 기계도 모두 이해할 수 있는 커밋 메세지
앞서 SemVer가 호환성에 영향을 주는 변경을 추적하는 규칙임을 설명하였는데, 현대 소프트웨어 개발에서 변경의 최소 단위는 commit이라 할 수 있다. 여러 개발자의 commit 이력이 모여 소프트웨어 릴리즈의 변경사항을 구성한다면, commit message에도 SemVer처럼 작성 규칙을 정해둘 수 있지 않을까?
Angular 프로젝트는 Change log를 자동 생성하기 위해 Commit Message Guidelines 를 제안하였고, 이는 Conventional Commit 표준에 큰 영향을 주었다.
<타입>[적용 범위(선택 사항)]: <설명>
< 빈 칸 >
[본문(선택 사항)]
<빈 칸>
[꼬리말(선택 사항)]
Angular 포맷에 많은 영향을 받은 탓인지, Angular 포맷과 Conventional Commit 의 커밋 메세지 구조는 거의 비슷하다. 메세지 헤더에 해당 커밋의 타입이 무엇인지( fix / feature / BREAKING CHANGE 등등…) 기술하고 공백 라인을 추가한 후, 구체적인 내용을 작성하는 구조이다. 경우에 따라 꼬리말(=footer)을 작성하거나 생략할 수 있다.
Conventional Commit 과 Angular 포맷의 결정적인 차이는 의무화되는 커밋 타입의 종류가 얼마나 많은지 여부이다. 상술하였듯, 커밋 메세지 포맷을 구조화하는 가장 큰 목적은 호환성에 영향을 주는 변경을 추적하기 위함이다. 따라서 다음 3가지 type 외에 나머지는 반드시 지켜야 하는 커밋 타입이 아니다.
feat: (=MINOR)
fix: (=PATCH)
BREAKING CHANGE: (=MAJOR)
fix: prevent racing of requests
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.
Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
Reviewed-by: Z
Refs: #123
프로젝트에 Conventional Commit 규칙을 도입하였을 때 가장 좋은 점은 릴리즈 버저닝과 Change log 생성을 자동화할 수 있다는 것이다.
PR을 머지하는 시점에 우리는 어떤 커밋 이력이 이번 릴리즈에 포함되어 있는지 정확히 파악할 수 있다.
Commit log 헤더가 <fix:> 로 시작한다면, PATCH 버전을 올린다.
Commit log 헤더가 <feature:> 로 시작한다면, MINOR 버전을 올린다.
Commit log footer가 <BREAKING CHANGE:> 로 시작하거나 타입 뒤에 !표기가 있다면, MAJOR 버전을 올린다.
근데 이제 Release Please Actions를 곁들인…
많은 오픈소스 프로젝트에서 Conventional Commit 과 SemVer 규칙을 따르기 때문에 익숙한 내용이었을 것으로 생각한다. 필자가 소개하려는 도구는 Google에서 제공하는 Release Please이다. (링크: https://github.com/googleapis/release-please) Conventional Commit 규칙을 따르는 프로젝트의 CHANGELOG와 SemVer 규칙에 맞는 Bump up을 자동화해주는 유용한 도구다. 특히 GitHub Actions 와 함께 사용하면 프로덕션 레벨의 소프트웨어 릴리즈 관리를 자동화할 수 있다.
(공식적으로도 GitHub Actions를 추천한다. 하지만 CLI 와 GitHub App도 지원을 한다.)
Release Please 의 기본 설정대로 구성하였을 때의 플로우는 다음과 같다.
PR 생성(from 개발자) → 리뷰 후 Approve → main 브랜치에 머지
Release PR 생성(from 봇)  → main 브랜치에 머지
Release PR에는 version tag, CHANGELOG 등의 정보가 포함
추가적으로 다른 필요한 동작을 설정할 수도 있음(e.g. docker registry push 등)
Release 생성 → Bump up 된 버전 tag 와 CHANGELOG 등을 바탕으로
특히, 잘 알려진 언어 / 패키지 매니저는 쓰기 편하도록 release-type을 지정하여 버전 정보를 관리할 수 있다.(e.g. nodejs를 쓰는 경우 package.json 정보도 함께 자동 갱신)
다음은 지원하는 언어 / release-type 목록이다.(링크: https://github.com/googleapis/release-please-action?tab=readme-ov-file#release-types-supported)
Releas Please는 잘 만들어진 도구답게, 워크플로우 단계의 꽤 많은 것들을 커스터마이즈할 수 있다.
하지만 기본적인 워크플로우 및 제공되는 기능으로도 충분하다.
결론
지금까지 소프트웨어 릴리즈 및 버저닝을 위한 SemVer와 Conventional Commit을 알아보고, 이를 통해 릴리즈 관리를 자동화할 수 있는 도구인 Release Please 를 알아보았다.
프로덕션 레벨로 소프트웨어 릴리즈 관리를 하고 싶은 분들에게 도움이 되었으면 한다.

Conventional Commit과 Semantic Versioning. 근데 이제 Release Please Actions를 곁들인…

댓글