release의 로그 관리는 어떻게 하는 것인가?

aws-cdk의 변경 사항을 보기 위해 GitHub를 보던 중 궁금증이 생겼습니다.

image

위와 같은 변경 사항 로그를 직접 작성하는 것은 아닐 것 같은데 어떻게 저렇게 적용이 되는 것인가에 대한 궁금증이었습니다.

자동화가 가능하다면 버전 관리에 대한 편의성도 높아지고 동시에 내용의 가독성이 좋아져 배포에 대한 변화의 내용 전달이 좋아지게 될 것이라 생각해 어떤 방식으로 이뤄지는지 찾아보기로 했습니다.

standard-version

저희 회사에서는 일관된 GitHub log 관리를 위해 Conventional Commits 방식의 규약을 두고 Commit 메시지 작성 해왔습니다.

Conventional Commits 란 commit 시에 일관된 양식을 유지하고 그 양식을 이용하여 로그를 자동으로 만들 수 있게 해줍니다.

여러 가지 package가 있었지만 제가 사용한 것은 standard-version입니다. standard-version 이용하면 간단하게 자동으로 log 파일을 생성 할 수 있습니다. 그럼 본격적으로 설치부터 사용까지 해보겠습니다.

설치

# yarn 기준으로 설명을 진행 하겠습니다.
yarn add standard-version --dev

설정

.versionrc 파일을 생성하여 아래와 같은 형식으로 내용을 작성 하면 본인이 설정한 대로 로그 파일을 생성하여 줍니다.

type: Conventional Commits에서 사용하는 여러 타입

section: type에 맞는 제목

hidden: log 생성 시 숨김 여부

{
  "types": [
    { "type": "chore", "section": "Others", "hidden": false },
    { "type": "revert", "section": "Reverts", "hidden": false },
    { "type": "feat", "section": "Features", "hidden": false },
    { "type": "fix", "section": "Bug Fixes", "hidden": false },
    {
      "type": "improvement",
      "section": "Feature Improvements",
      "hidden": false
    },
    { "type": "docs", "section": "Docs", "hidden": false },
    { "type": "style", "section": "Styling", "hidden": false },
    { "type": "refactor", "section": "Code Refactoring", "hidden": false },
    { "type": "perf", "section": "Performance Improvements", "hidden": false },
    { "type": "test", "section": "Tests", "hidden": false },
    { "type": "build", "section": "Build System", "hidden": false },
    { "type": "ci", "section": "CI", "hidden": false }
  ]
}

image

.versionrc 파일의 section 부분이 사진의 Bug Fixes 부분이 됩니다.

설정 후 Conventional Commits 방식에 맞게 commit 메시지를 작성해 둡니다.

실행

# 처음 한번 실행 CHANGELOG.md 파일 생성
yarn standard-version --first-release # yarn

CHANGELOG.md 파일이 생성과 tag가 부착된 commit 이 생성 됩니다.

image

### [0.2.4](https://github.com/XXX/test/compare/v0.2.3...v0.2.4) (2020-07-13)

### Bug Fixes

* **테스트1:** 테스트1 ([7adda2b](https://github.com/XXX/test/commit/7adda2bbfcaa2429a91cd6dcce1301237752f25c))
* **테스트2:** 테스트2 ([5a0416d](https://github.com/XXX/test/commit/5a0416d298bc2bdb9bd262a142f2fb0cb2141090))
* **테스트3:** 테스트3 ([40f9131](https://github.com/XXX/test/commit/40f913180f3bbe534beb59610c1611cde340c4d3))

파일의 내용은 위와 같이 자신이 commit 한 메시지를 토대로 생성 됩니다.

# CHANGELOG.md 파일에 로그 내용이 추가됨
yarn standard-version # 0.0.1(patch)
yarn standard-version --release-as minor # 0.1.0 (minor)
yarn standard-version --release-as major # 1.0.0 (major)
yarn standard-version --release-as 원하는버전

실행 방법에 따라 원하는 만큼 버전을 올릴 수 있습니다.

conventional-github-releaser

태그가 달려 있는 commit 이 생성되었다면 이제 release를 생성을 하여야 합니다. 여러 가지 방법으로 release를 생성할 수 있겠지만 저는 conventional-github-releaser를 이용해서 생성해 보겠습니다.

conventional-github-releaser를 설치해 줍니다.

$ yarn add conventional-github-releaser

js 파일로 다양한 설정이 가능합니다.

require("dotenv/config");
const conventionalGithubReleaser = require("conventional-github-releaser");

conventionalGithubReleaser(
  {
    type: "oauth",
    url: "https://api.github.com/",
    token: process.env.GITHUB_TOKEN,
  },
  {
    preset: "angular",
  },
  (e, release) => {
    if (e) {
      console.error(e);
      process.exit(1);
    }

    // console.log(release)
    process.exit(0);
  }
);

저는 간단히 GitHub 접근 권한 부여, preset은 화면에 보여지는 디자인에 대한 preset 입니다.

설정을 완료 하고 명령어를 실행 해 보았습니다 .

"release": "standard-version && node conventionalGithubReleaser"

실행 시 standard-version의 실행 후 node conventionalGithubReleaser도 실행 되도록 script를 만들었습니다.

image

fix commit 2개를 한 모습입니다. Bug Fixes로 처리 되어 해당 버전에 있는 로그에 맞게 잘 올라 갔습니다.

일반적인 fix, feat 정도의 변경은 0.0.1 부터 올리는 것이 가능하고 BREAKING CHANGE가 들어가는 변경의 경우 최소 0.1.0의 버전 상승이 있습니다.

마무리

프로젝트를 좀 더 체계적으로 관리하기 위해 release를 만들어 로그에 대한 내용을 손으로 적는다고 한다면 스스로 commit log도 들고 와서 정리를 해야 하고 commit에 대한 링크도 작성해야 하고 귀찮은 일이 한두 가지가 아닐 것입니다.

자동화를 통해 많은 수고를 하지 않더라도 로그를 남겨 버전 관리가 가능하기에 적용을 하는 것에 손해가 없다고 생각합니다.

해당 내용은 lerna + workspaces 사용 시 불편함과 문제점이 있었습니다. 다음에는 lerna + workspaces를 사용해서 로그 관리 방법에 대해 글을 써보도록 하겠습니다.

References