소프트웨어를 발표하는 것은 매우 어렵다!그것은?

본문은 최초로 발표되었다https://lifelongstudent.io.
나는 줄곧 소프트웨어 발표와 버전 제어에 대해 실망을 느꼈다.
과거에 내가 소프트웨어 엔지니어의 첫 번째 일을 시작했을 때, 나의 팀 책임자는 모든 프로젝트 관리를 책임졌다.이것은 그가 당신이 현재 어떤 문제를 처리하고 있는지, 그리고 언제 (소프트웨어의 어느 버전에서) 합병해서 발표해야 하는지를 알고 있다는 것을 의미한다.지금까지 나는 버전 제어는 무작위적인 일일 뿐이라고 생각한다. 우리 모두가 그것을 토론하거나 인용할 때 같은 페이지에 있는 것을 제외하고는 아무런 의미가 없다.
버그와 특성은 다음 버전으로 미뤄졌고, 진정한 체계적인 추리는 없었다. 나는 그것에 관한 일부 것들이 이미 시대에 뒤떨어졌다는 것을 안다.이때 나는 브라우저를 열고 구글로 이 화제를 검색하기 시작했다.나는 많은 것을 검색하고 읽었는데, 마지막에 나는 만났다. Semantic Versioning
 

1. 의미 버전 제어

의미 버전 제어(또는semver)는 기본적으로 간단한 규칙과 요구로 버전 번호를 어떻게 분배하고 증가하는지 규정한다.실제로 SemVer는 현재 당신이 하고 있는 일과 유사할 수 있지만, 유사한 것은 아무런 가치가 없습니다.어떤 형식의 규범을 준수하지 않으면 버전 번호가 의존 관계 관리에 기본적으로 무용하기 때문이다.
의미 버전 제어는 이미 2011년에 개원 지역사회에서 광범위하게 사용되었다.모든 주요 개원 항목이 그것을 지원하기 때문에 적어도 이 규범을 읽을 만하다.semver규범을 따르면 버전 번호와 변경 방식은 베이스 코드의 의미와 한 버전에서 다음 버전으로 수정된 내용을 전달합니다.
만약 이것이 당신을 설득할 수 없다면, 의미 버전 규범이 최초로 Tom Preston-Werner (GitHub의 공동 창시자) 에 의해 작성되었다는 사실은 당신을 믿게 할 것이다.
그래서 만약 네가 아직도 이 글을 읽고 있다면, 나는 네가 semver에 대해 약간의 흥미를 가지고 있다고 생각한다.따라서 규범을 읽으십시오. 규범은 간단하고 간결하며 여러 언어로 번역됩니다.나는 단지 기본적인 내용을 말하고 싶다. 버전 양식은 X.Y.Z (각각 Major.Minor.Patch 이다.API 추가/변경이 이전 버전과 호환되지 않는 경우(즉, 변경 중단)Major가 증가합니다.API 추가/변경이 이전 버전과 호환되는 경우Minor가 증가합니다.버그 수정 사항이 API에 전혀 영향을 주지 않으면 증가Patch합니다.

 

2.듣기에는 괜찮은데...

어의 버전 제어는 듣기에는 괜찮지만, 그것은 새로운 문제를 가져왔다.모든 버전은 누군가가 앉아서 문제/요청을 읽고 이 버전changelog을 써야 한다. 그 중에서 그는 소프트웨어의 버전을 수정해야 한다.이것은 듣기에 매우 무미건조한 수공 작업 같다.그것만으로도 나는 오랫동안 SemVer를 제대로 사용하지 못했다.
내가 찾을 때까지semantic-release!이 도구는 전체 패키지 게시 워크플로우를 자동화하는 도구입니다(다음 버전 번호 확인, 릴리즈 노트 생성-changelog, 패키지 게시).이것은 인류의 감정과 버전 번호 간의 직접적인 관계를 없애고 Semantic Versioning규범을 엄격히 따른다.
우리의 생활을 더욱 간단하게 하기 위해서 우리는 Release me!GitHub를 사용하여 엔진 뚜껑 아래에서 사용할 수 있다semantic-release.

그러나 의미 발표는 버전의 어느 부분에 부딪혀야 하는지 어떻게 알 수 있을까?이것은 제출 메시지를 사용하여 코드 라이브러리에서 변경된 유형을 확인합니다.따라서, 이것은 우리가 특정한 제출 메시지 형식을 따라야 한다는 것을 의미한다.기본적으로 의미 버전은 Angular Commit Message Conventions을 따르지만 changelog 파일로 변경할 수 있습니다.우리는 이 글에서 그것을 바꾸지 않을 것이다. 왜냐하면 개원 지역사회에서 이런 격식을 광범위하게 사용하기 때문이다.
나는 우리가 공을 다른 곳으로 찼을 뿐 진정으로 문제를 해결할 방법이 없다고 생각하기 시작했다.현재 우리는 특정 형식의 제출 메시지를 배우고 수동으로 작성해야 하기 때문이다.
 

3. 우리 영원히 이 문제를 해결합시다

네 말이 좀 맞다.우리의 문제는 여전히 존재하지만, 우리가 이 문제들을 토론하기 전에, 다른 문제는 여전히 존재한다. 우리는 단지 그것들을 언급하지 않았을 뿐이다.하지만 두려워하지 마세요Conventional Commits. 구원하러 가세요.전통적인 제출 규범은 제출 메시지 위의 약정으로 현식 제출 역사를 만드는 규칙을 제공한다.나는 네가 지금 무슨 생각을 하고 있는지 안다.
다시 한 번, 나의 젊은 견습생을 두려워하지 마라.commitizen - 명령행 유틸리티가 도움말config을 주고 각 커밋을 완료하도록 안내합니다.

그럼 지금까지의 모든 도구를 되돌아봅시다.만약 우리가 commitizen를 commit에 사용한다면, 우리의 제출 메시지의 형식은 Angular Commit Message Conventions 및 Conventional Commits와 호환될 것이다.만약 우리의 제출이 이 형식과 호환된다면 semantic-release 우리는 다음 버전 번호를 확정하고 발행 설명을 생성하며 Semantic Versioning 규범에 따라 패키지를 발표할 것이다.완벽해!
 

4.손을 더럽힐 때

프로젝트 디렉터리에 간단한 commit 파일을 만듭니다. npm (우리는 package.json 이라고 부릅니다. namelix 생성기가 이 파일을 만들어 주기 때문입니다.

$ mkdir deweb
$ cd deweb
$ git init
$ npm init
$ echo node_modules >> .gitignore

이것은 나의 배치다.

지금 우리는 설치commitizen를 하고 우리의 환매 약속을 우호적으로 해야 한다.

$ npm install commitizen -g
$ commitizen init cz-conventional-changelog --save-dev --save-exact

이것은 commitizen에게 공헌자가 이 리포에 제출하려고 할 때 어떤 어댑터를 사용하길 원하는지 알려 주는 것입니다.현재 67914와 67914 명령을 사용하여 모든 67914 파일을 알릴 수 있습니다.

$ git cz

 

5. 그 망할 놈의 물건을 놓아라

현재, 우리는 수동으로 semantic-release 을 사용하여 버전을 자동으로 생성할 수 있다. (내 말은 우리가 새로운 버전을 만들 때마다 명령을 수동으로 작성해야 한다는 것이다.)하지만 우리는 더 잘할 수 있어!저희가 GitHub 작업에서 자동으로 완성되지 않았나요?심지어 GitHub의 이정표와 연결시킨다.
따라서 Release me! 조작을 사용하는 GitHub 조작을 만들고 GitHub에서 이정표 이벤트가 있을 때마다 실행합시다.

$ mkdir -p .github/workflows
$ touch .github/workflows/cd.yml

이 파일에서 GitHub action 의 기본 템플릿을 복사하고 release-me-action 사용해야 합니다.그런 다음 이정표가 닫혔을 때 파일 deweb 맨 위에 있는 git cz 키를 변경해야 합니다.

name: Continuous Deployment

on:
  milestone:
    types: [closed]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Create Release 🚀
        uses: ridedott/release-me-action@master
        env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          release-branches: '["main"]'

이제 새 파일을 제출하여 GitHub로 보냅니다.

$ git add .
$ git cz
$ git push origin main

우리가 해야 할 마지막 일은 GitHub에서 이정표를 만들고 작업 부분을 보고 작업 흐름을 보는 것입니다. 그러나 아직 실행되지 않았음을 알 수 있습니다.

그리고 이정표 git commit 단추를 누르면) 를 닫고 작업 옵션을 새로 고칩니다.

작업 흐름이 실행된 후에, 우리는releases 페이지를 열고, 우리의 새 버전을 봅시다. (이 작업은 모든 변경 사항을 포함하는 commit 파일을 만들었고, 버전마다 이 파일을 업데이트할 것입니다.)

 

6. 요약

위에서 말한 바와 같이, on 이정표 (GitHub 작업 흐름에서 쉽게 변경할 수 있음) 를 제외하고, 우리는 현재 소프트웨어를 자동으로 발표하여, 아무도 관여할 필요가 없다.우리의 제출 소식은 commitizen규범Conventional Commits을 통해 잘 조직되었다.GitHub 작업을 통해 게시가 자동화됩니다.릴리스 자체는 semantic-release에 의해 생성된 다음 릴리즈 번호, 릴리즈 노트 및 GitHub 릴리스에 게시된 내용입니다.
이 모든 일이 일어나거나 오래 갇혀 있을지도 모른다면 GitHub의 deweb 환매 프로토콜로 넘어가서 코드를 확인하십시오.