✊ 필오의 개발일지
Back to Posts
2021년 2월 23일

웹 버저닝과 배포내역관리 (feat. standard-version)

웹 버저닝과 배포내역관리 (feat. standard-version)
정리 이미지
정리 이미지

셋팅은 여기 레포 에서 확인 가능하다.

최근 버그와 관련된 CS가 인입이 되어, 픽스 후 배포했음에도 불구하고 유사한 CS가 인입이 되었을때 또 다시 버그 개선 티켓이 생성되곤 했다. 버그 픽스가 제대로 되지 못했을 수도있지만, 상황을 확인해보면 이슈를 CS단계에서 확인하지 못하고 바로 넘어오는 상황이 많았다. (커뮤니케이션으로 해결가능한 것들도) 이런 상황이 반복되고 누적되다보니 개발 집중력이 떨어지고, 불필요한 커뮤니케이션에 시간을 쏟고 있다는 생각이 들어, 개선해야겠다는 생각이 들었다.

유저, CS담당자, 개발자
유저, CS담당자, 개발자

문제 사항

CS단계에서 진행되지 못하고 넘어올수밖에 없었던 이유

  1. CS 대응 메뉴얼에 새로고침과 관련된 항목이 없었음.

    CSR의 경우 새로운 배포가 이루어졌을때, 새로고침을 하지 않을 경우 새로 배포한 JS파일을 바라보지 못하고, 이전 JS파일을 바라보고 있게 된다.

  2. 새로고침 이전에 사용자가 바라보는 버전이 신규 배포 버전의 JS파일인지 확인을 해야하지만 서비스에 버전을 명시하지 않아, CS 담당자가 확인할 수 없었다는 점.
  3. 버전명을 확인해도 해당 버전에 어떤 배포가 이루어졌었는지. 이전에 등록됐던 버그 픽스건이 배포가 되었었는지 확인할 수 있는 내역을 슬랙에서 검색해서 찾는 등 히스토리를 찾아야하는 상황.

    배포 notice를 확인할 수 있는 채널이 있지만, CS담당자가 이를 확인하지 못했거나, 잊을수도 있다.

사실 1번과 2번의 경우 SSR형태의 프로젝트나, 브라우저를 오래 유지하지 않고 사용하는 프로젝트라면 화면을 이동할때나 새로 들어갈때 최근에 배포한 파일을 load하기때문에 문제가 거의 발생하지 않는다. 하지만 어드민과 같은 프로젝트의 경우 브라우저를 끄지 않거나 컴퓨터를 아예 끄지 않는 경우 등, 오랫동안 새로고침하지 않고 유지되는 상황이 존재하기에 위 상황이 발생할 가능성이 있다.

해결 방향

생각나는 해결 방법은 아래와 같았다.

문제사항의 해결방향으로 다시 바라보면

해결방법 3번이 가장 효과적인 방법이긴하나, 이번 포스팅에서는.. 해결방법 1,2번의 경우에 해당되는 버전관리, 배포내역관리에대해 작성하고자 했다.ㅎㅎ

구현 방향

버전관리와 배포내역 관리는 배포시점에 진행해야하는데, 생각나는 순서는 아래와 같았다.

  1. 프러덕션 배포 전 버전을 업데이트
    1. 버전의 경우 배포하는 기능의 범위와 유형에 따라 major, minor, patch를 올릴지 결정
    2. package.json의 버전을 결정한 버전으로 변경
  2. 빌드 및 배포
  3. 배포가 성공하면 배포사항을 내역에 추가

버전을 업데이트하고, 배포사항을 내역에 추가하는 일련의 과정을 배포때마다 한다는 것은 여간 번거로운 일이 아니다. 직접 구현전에 자동화로 만들어 놓은 오픈소스를 찾아보고, 배포시점때마다 진행되어야해서 CI툴에 JOB으로 단계별로 생성하여 진행하기로 했다.

  1. 관련 라이브러리 찾아보기
  2. 배포 파이프라인에 추가하기

1. 라이브러리 서칭

찾기전에 버전과 배포내역이라는 개념을 정리해볼 필요가 있었다. 두 가지는 오픈소스 프로젝트에서 자주 볼 수 있었다. 이를 참고하여 리서칭해보니 2가지 개념이 나온다.

  1. 시맨틱 버저닝
  2. CHANGLOG

개념) 시멘틱 버저닝이란?

시맨틱 버저닝의 경우 이 링크 에서 자세히 확인 가능하다. 소프트웨어의 버전 변경 규칙에 대한 제안이다. 간단히 말하자면 의존성 지옥을 해결하고자 배포시 버전번호를 명시하여 정의를 내림으로써 의존성관리를 용이하게 한다. SemVer의 형태는 아래와 같다.

MAJOR.MINOR.PATCH
출처: bytearcher
출처: bytearcher

npm에서는 버전을 관리할 수 있는 cli를 제공한다. 이 명령어를 통해서 package.json의 버전명을 올릴 수 있다.

npm version
    [
        <newversion>
        | major
        | minor
        | patch
        | premajor
        | preminor
        | prepatch
        | prerelease [--preid=<prerelease-id>]
        | from-git
    ]

개념) CHANGELOG란?

CHANGELOG
CHANGELOG

릴리즈 노트와 CHANGLOG

CHANGLOG

// .versionrc
{
  "types": [
    ...
    {"type":"release"}, // release용으로 생성
    ...
  ]
}
Gatsby.js내의 릴리즈노트 페이지
Gatsby.js내의 릴리즈노트 페이지

release note

library) standard-version 

이 2가지를 관리할 수 있는 standard-version이라는 라이브러리가 존재한다. standard-version 스크립트 하나로 여러가지 일을 실행해주는데 아래와 같다.

  1. 깃의 commit로그를 확인하여
    1. 새로운 버전을 생성하고 package.json의 버전 업데이트 (npm version 명령어 대체가능)
    2. 커밋을 기준으로 CHANGLOG파일 생성 및 갱신
  2. 해당 과정이 마무리되면 CHANGLOG파일과 package.json의 변경내역 커밋을 진행한다.
    • 자동 커밋메세지 : chore(release): 버전명
  3. 버전명을 Tag로 만들어서 추가한다.

생각 및 고민

  1. 장점) 버전 업데이트, 릴리즈 tag명시, CHANGLOG 갱신을 한번에 해결해준다.
  2. 고민) 기여자 모두가 커밋을 conventional commit 스펙에 맞추어 엄격하게 작성해야한다.
  3. 장점) 커밋 규칙을 지키며 개발하는 덕분에 커밋정리 및 규칙도 정리된다.
  4. 확장) 배포때마다 tag관리가 되어 롤백등의 상황에서도 태그기준으로 롤백이 편리하게 가능하다.

커밋에 의존적인 상황

하나 걱정되는 것은 기여자 모두가 conventional commit 스펙을 정확히 맞춰서 작성해야하는 부분이였는데 아래 라이브러리들로 해결이 가능했다.

'commitizen/cz-cli' 셋팅 후 commit 진행시

규격) conventional commit 

컨벤셔널 커밋은 페이지에서 이렇게 설명한다.

프로젝트에 셋팅하지 않아도 커밋 습관을 들이기 좋은 컨벤션이라고 생각이 들었다.

형태는 아래와 같다.

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

즉, 위의 규격을 지키며 커밋을 진행해야한다.

(예시)

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

library) commitlint

commitlint를 사용해 commit시에 컨벤션을 잘 지켰는지 체크한다. 컨벤션은 어느정도 규격화 되어있다.

  1. 컨벤션 셋팅
  2. commit hook에 셋팅

컨벤션 셋팅

.commitlintrc.js파일. 기본 아이콘 이뿜
.commitlintrc.js파일. 기본 아이콘 이뿜
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'build',
        'ci',
        'chore',
        'docs',
        'feat',
        'fix',
        'perf',
        'refactor',
        'revert',
        'style',
        'test',
        'release',
      ],
    ],
  },
};

commit hook에 셋팅

husky를 사용하여 셋팅하였다.

// package.json
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
  }
}

정리

정리 이미지
정리 이미지

2. 배포 파이프라인에 추가하기

build:
  ...
  steps:
    - uses: actions/checkout@v2 # 레포 바라보게 하기용
    - uses: fregante/setup-git-user@v1 # 유저 셋팅용
 
    - name: 패키지 설치
      run: yarn
 
      # 커밋타입에 release 타입을 추가하여
      # 릴리즈 노트를 마지막 커밋에 대신 작성하게 하였다.
      # 해당 스크립트는 lastCommit.sh 파일을 실행한다.
    - name: 릴리즈 내역 커밋 확인
      run: yarn check:lastCommit
 
      # standard-version 진행
    - name: version 업데이트 및 changelog 생성
      run: yarn release
 
      # 빌드 및 배포 start
    - name: 빌드 시작
      run: yarn build
 
    - name: 배포
      run: echo "배포2"
      # 빌드 및 배포 end
 
    - name: 변경내역 푸시
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        branch: ${{ github.ref }}
        tags: true # 태그까지 생성되기때문에 같이 추가한다.
 
    - name: 배포완료 사항 노티
      ...
 
    - name: Job 상태 노티
      ...
github action 캡쳐
github action 캡쳐

마치며

운영이슈에서 오는 피로감을 개선하고자 여러가지 방향을 고민해보았는데, 문제해결로 가다가 살짝 옆으로 샌감이 없지않아 있다.ㅎㅎ 무튼 덕분에 버전관리와 배포내역관리에 대한 라이브러리들 을 알 수 있었고 github액션도 사용해보아서 개인적으로 재밌었던 포스팅이었다.

참고자료

  1. SemVr 
  2. wiki-CHANGELOG 
  3. standard-version 
  4. commitlint 
  5. commitizen/cz-cli 
  6. 규격화 
PreviousSvg로 Rounded rect형태의 progress bar 만들기 (feat. animation, path)
Next피츠의 법칙과 Touch Target

Related

HomePostsRSSLinkedinGitHub
© 2025 Felix
CTRL K