지속적인 배포로 프로젝트 버전화 및 릴리스를 자동화하는 방법

시맨틱 버전 제어를 사용하면 소프트웨어 변경을보다 쉽게 ​​유지하고 통신 할 수 있지만 수동 작업은 번거 롭습니다. PR을 수동으로 병합하더라도 제출물을 표시하고 릴리스를 푸시하면 릴리스 설명을 작성해야합니다. 많은 단계, 높은 반복, 시간 소모 및 노동 집약적 인 단계가 있습니다.

이 기사는 시맨틱 버전을 지속적인 배포 프로세스에 통합하여보다 효율적인 프로세스를 달성하고 릴리스 프로세스를 완전히 자동화하는 방법을 설명합니다.

시맨틱 버전 제어

시맨틱 버전은 1.4.10과 같은 세 가지 숫자로 구성된 버전 번호입니다. 각 숫자에는 특정한 의미가 있습니다.

주요 버전 변경 (전공)

첫 번째 숫자는 주요 버전 변경을 나타내며, 이는 파괴적인 변화가 있음을 의미합니다.

마이너 버전 변경 (사소한)

두 번째 숫자는 사소한 버전 변경을 나타내며 새로운 기능이 추가되었음을 의미합니다.

패치 버전 변경

세 번째 숫자는 패치 버전 변경을 나타내며 버그가 고정되어 있음을 의미합니다.

시맨틱 버전은 파괴적인 변화, 기능적 변화 및 버그 수정과 같이 더 간결하게 이해할 수 있습니다. 이 설명은 더 정확하고 모호성을 피합니다.

정보 형식을 제출하십시오

시맨틱 버전 번호가 올바르게 증가하고 올바른 버전이 해제되도록 표준화 된 제출 정보 형식이 필요합니다. 표준화 된 제출 정보 형식은 어떤 숫자를 증가시키고 출판 지침을 쉽게 생성 할시기를 결정하는 데 도움이됩니다. 여기서 Angular는 정보 규칙을 제출하는 데 사용되며 물론 필요에 따라 변경할 수도 있습니다.

형식은 다음과 같습니다.

<code></code>

각 제출에는 제목 , 신체 및 각주가 포함되어 있습니다.

제목을 제출하십시오

제목은 필수품이며 유형 , 선택적 범위 및 주제를 포함한 특별 형식이 있습니다.

제목 유형은 다음 버전에 대한 제출의 영향을 설명하는 데 필요한 필드입니다. 다음 유형 중 하나 여야합니다.

• 위업 : 새로운 기능
• 수정 : 버그 수정
• 문서 : 문서 변경
• 스타일 : 코드의 의미에 영향을 미치지 않는 변경 (예 : 공백, 형식, 누락 된 세미콜론 등)
• Refactor : Code Refactoring, 버그 수정이나 기능 추가
• Perf : 성능 향상
• 테스트 : 추가 또는 올바른 테스트
• CHORE : 문서 생성과 같은 프로세스 또는 보조 도구 및 라이브러리 구축 변경

범위는 API, 응용 프로그램 대시 보드 또는 사용자 계정 등과 같은 서브 시스템과 관련된 서브 시스템을 지정하는 그룹화 속성입니다. Commit에 의해 여러 서브 시스템을 수정하면 대신 별표 (*)를 사용할 수 있습니다.

제목 주제는 변경 사항을 간단히 설명해야합니다. 주제를 작성할 때 다음 규칙이 필요합니다.

• 명령 문장을 사용하고 시제를 제시하십시오 (예 : "변경"또는 "변경"대신 "변경").
• 초기 문자의 소문자.
• 끝에 기간 (.)이 추가되지 않습니다.
• 80 자를 초과하는 주제 길이를 피하십시오. 시체를 제출하십시오.

제목 테마와 마찬가지로, 본문은 필수 문장을 사용하고 현재 시제를 사용해야합니다. 변화에 대한 동기를 포함하고 이전 행동과 비교해야합니다.

각주를 제출하십시오

각주에는 파괴적인 변경 사항 에 대한 정보가 포함되어야 하며이 제출에 대해 인용 된 질문이 닫히는 곳이기도합니다.

파괴적인 변화 정보는 변화를 깨기로 시작해야합니다. 나머지 제출 정보는 여기에 있습니다.

제출 정보 형식을 시행합니다

팀워크에서 모든 사람이 따라야 할 모든 것을 표준화하는 것은 항상 어려운 일입니다. 모든 사람이 동일한 제출 기준을 사용하도록하기 위해 Commitizen을 사용합니다.

Commitizen은 일관된 커밋 메시지 형식을 사용하는 프로세스를 단순화하는 명령 줄 도구입니다. 저장소를 Commitizen과 호환한다는 것은 팀의 모든 사람이 GIT CZ를 실행하고 제출 정보를 작성하기위한 상세한 프롬프트를 얻을 수 있음을 의미합니다.

생성 및 게시

우리는 제출물이 일관된 표준을 따른다는 것을 알았으므로 릴리스 및 릴리스 노트 생성을 시작할 수 있습니다. 이를 위해 Semantic Release라는 패키지를 사용합니다. 이것은 다양한 CI (Continuous Integration) 플랫폼을 잘 지원하는 잘 관리 된 패키지입니다.

Semantic Release는 다음을 포함하여 출시에 필요한 모든 단계를 수행하기 때문에 우리 여행의 핵심입니다.

1. 공개 한 마지막 버전을 확인하십시오
2. 마지막 릴리스 이후 추가 된 제출물에 따라 게시 유형을 결정하십시오.
3. 마지막 릴리스 이후 추가 된 제출에 대한 게시 지침 생성
4. package.json 파일을 업데이트하고 새로 릴리스 된 버전에 해당하는 git 태그를 만듭니다.
5. 새 버전을 푸시하십시오

모든 CI는 괜찮습니다. 이 기사에서는 타사 솔루션을 찾기 전에 플랫폼의 기존 기능을 사용하기 때문에 GitHub Action을 사용합니다.

Semantic Release를 설치하는 방법에는 여러 가지가 있지만 Semantic Release-CLI는 단계별 작업을 제공하기 때문에 사용합니다. 터미널에서 NPX Semantic Release-CLI 설정을 실행하고 대화식 마법사를 작성합시다.

스크립트는 다음을 수행합니다.

• 제공된 NPM 정보와 함께 NPM AddUser를 실행하여 .NPMRC를 생성하십시오.
• Github 개인 액세스 토큰을 만듭니다.
• Package.json을 업데이트합니다.

CLI가 완료되면 Semantic Release를 Package.json에 추가하지만 실제로 설치하지는 않습니다. NPM 설치를 실행하여 설치 및 기타 프로젝트 종속성을 설치하십시오.

남은 유일한 것은 GitHub 작업을 통해 CI를 구성하는 것입니다. 시맨틱 릴리스를 실행하는 워크 플로를 수동으로 추가해야합니다. .github/workflows/release.yml에서 게시 워크 플로를 만들어 봅시다.

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff는 Github 액션으로 CI를 소개하는 데 큰 도움이되었지만 여기에서 무슨 일이 일어나고 있는지 간략하게 검토해 봅시다.

파이프 라인이 실행되기 전에 메인 브랜치로의 푸시가 발생할 때까지 기다립니다. 하나, 2 또는 모든 지점에서 실행하고 싶을 때이 설정을 변경할 수 있습니다.

 <code>on: push: branches: - main</code>

그런 다음 체크 아웃을 사용하여 저장소를 당기고 노드를 설치하여 NPM을 사용하여 프로젝트 종속성을 설치할 수 있습니다. 이것이 당신이 선호하는 것이면 테스트 단계를 추가 할 수 있습니다.

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

마지막으로 Semantic Release가 모든 마법 작업을 수행하도록하십시오.

 <code>- name: Release run: npm run release</code>

변경 사항을 푸시하고 동작보기 :

이제 지정된 지점이 커밋 (또는 병합) 될 때마다 작업이 실행되고 릴리스 메모로 게시됩니다.

파티를 게시하십시오!

우리는 CI/CD 시맨틱 릴리스 워크 플로를 성공적으로 만들었습니다! 그렇게 고통스럽지 않습니까? 설정은 비교적 간단하며 의미 론적 출판 워크 플로우에 대한 단점이 없습니다. 추적 변경을 훨씬 쉽게 만듭니다.

시맨틱 릴리스보다 고급 자동화를 가능하게하는 플러그인이 많이 있습니다. 예를 들어, 프로젝트가 성공적으로 배포 된 후 프로젝트 채널에 게시 할 수있는 슬랙 릴리스 봇도 있습니다. 업데이트를 찾기 위해 Github에 갈 필요가 없습니다!

위 내용은 지속적인 배포로 프로젝트 버전화 및 릴리스를 자동화하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!