継続的な展開でプロジェクトバージョンとリリースを自動化する方法

セマンティックバージョン制御を使用すると、ソフトウェアの変更を維持および通信しやすくなりますが、手動操作は面倒です。 PRを手動でマージしても、提出をマークしてリリースをプッシュしても、リリースの説明を書く必要があります。多くのステップ、高い繰り返し、時間がかかり、労働集約的です。

この記事では、セマンティックバージョンを継続的な展開プロセスに統合することにより、より効率的なプロセスを実現し、リリースプロセスを完全に自動化する方法について説明します。

セマンティックバージョンコントロール

セマンティックバージョンは、1.4.10などの3つの番号で構成されるバージョン番号です。各番号には特定の意味があります。

メジャーバージョンの変更（メジャー）

最初の数字は主要なバージョンの変更を示しています。つまり、破壊的な変更があります。

マイナーバージョンの変更（マイナー）

2番目の番号は、マイナーバージョンの変更を示しています。つまり、新しい機能が追加されています。

パッチバージョンの変更

3番目の数値は、パッチされたバージョンの変更を示します。つまり、バグが修正されます。

セマンティックバージョンは、破壊的な変化、機能的変化、バグの修正として、より簡潔に理解できます。この説明はより正確であり、あいまいさを回避します。

情報形式を送信します

セマンティックバージョン番号が正しく増分され、正しいバージョンがリリースされるようにするには、標準化された提出情報形式が必要です。標準化された提出情報形式は、どの数値をインクリメントするかを決定し、公開手順を簡単に生成するのに役立ちます。ここでは、Angularを使用して情報規則を提出します。もちろん、必要に応じて変更することもできます。

フォーマットは次のとおりです。

<code></code>

各提出には、タイトル、ボディ、脚注が含まれています。

タイトルを提出します

タイトルは必須であり、タイプ、オプションの範囲、トピックなどの特別な形式があります。

タイトルタイプは、次のバージョンに対する提出の影響を示すために必要なフィールドです。それは次のタイプのいずれかでなければなりません：

• 偉業：新機能
• 修正：バグ修正
• ドキュメント：ドキュメントの変更
• スタイル：コードの意味に影響しない変更（たとえば、スペース、フォーマット、欠落セミコロンなど）
• リファクタリング：コードリファクタリング、バグの修正も機能の追加も
• パフォーマンス：パフォーマンスの改善
• テスト：テストを追加または正しいテスト
• 雑用：ドキュメントの生成など、プロセスや補助ツールやライブラリを構築するための変更

スコープは、API、アプリケーションダッシュボード、ユーザーアカウントなどのサブシステムに関連するサブシステムを指定するグループプロパティです。複数のサブシステムがコミットによって変更された場合、アスタリスク（*）を使用できます。

タイトルトピックは、行われた変更を簡単に説明する必要があります。トピックを書くときは、次のルールが必要です。

• 命令文を使用して、現在の緊張を使用します（たとえば、「変更」または「変更」の代わりに「変更」）。
• 最初の文字の小文字。
• 最後には期間（。）は追加されていません。
• 80文字を超えるトピックの長さは避けてください。体を提出します。

タイトルテーマと同様に、メインテキストは緊張した命令文を使用する必要があります。変更の動機を含めて、それを以前の動作と比較する必要があります。

脚注を送信します

脚注には、破壊的な変更に関する情報を含める必要があり、この提出に引用された質問が閉じられている場合もあります。

破壊的な変更情報は、変化を破ることから始まるはずです。その後、スペースまたは2つの新しい行が続きます。残りの提出情報はこちらです。

提出情報形式を強制します

チームワークでは、誰もが従う必要があるものを標準化することは常に挑戦です。全員が同じ提出基準を使用するようにするために、コミットメントを使用します。

commitizenは、一貫したコミットメッセージ形式を使用するプロセスを簡素化するコマンドラインツールです。リポジトリをコミットンと互換性のあるものにするということは、チームの誰でもGit CZを実行し、提出情報を入力するための詳細なプロンプトを取得できることを意味します。

生成して公開します

提出物が一貫した基準に従っていることがわかったので、リリースの生成とノートのリリースを開始できます。これを行うには、Semantic-Releaseというパッケージを使用します。これは、さまざまな連続統合（CI）プラットフォームを適切にサポートする適切にメンテナンスしたパッケージです。

セマンティックリリースは、リリースに必要なすべての手順を実行するため、旅の鍵です。

1. リリースした最後のバージョンを確認してください
2. 最後のリリース以降に追加された提出物に基づいてパブリッシュタイプを決定する
3. 最後のリリース以降に追加された提出物の公開手順を生成する
4. package.jsonファイルを更新し、新しくリリースされたバージョンに対応するgitタグを作成します
5. 新しいバージョンをプッシュします

CIは大丈夫です。この記事では、サードパーティのソリューションを探す前にプラットフォームの既存の機能を使用するのが好きなので、GitHubアクションを使用します。

セマンティックリリースをインストールするには多くの方法がありますが、段階的な操作を提供するため、セマンティックリリース-CLIを使用します。ターミナルでNPX Semantic-Release-Cliセットアップを実行し、インタラクティブウィザードに記入しましょう。

スクリプトは次のことを行います。

• 提供されたNPM情報でNPM Adduserを実行して、.NPMRCを生成します。
• GitHubの個人アクセストークンを作成します。
• package.jsonを更新します。

CLIが終了すると、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を導入するという素晴らしい仕事をしましたが、ここで何が起こっているのかを簡単に確認しましょう。

これにより、パイプラインが実行される前にメインブランチへのプッシュが発生するのを待ちます。この設定は、1つ、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>

最後に、セマンティックリリースにすべての魔法の操作を実行させてください。

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

変更をプッシュしてアクションを表示します。

これで、指定されたブランチがコミットされる（またはマージされた）たびに、操作が実行され、リリースノートで公開されます。

パーティーを投稿してください！

CI/CDセマンティックリリースワークフローを正常に作成しました！そんなに苦痛ではありませんか？セットアップは比較的簡単で、セマンティックパブリッシングワークフローを持つことに不利な点はありません。追跡の変更がはるかに簡単になります。

セマンティックリリースにより、より高度な自動化を可能にする多くのプラグインがあります。たとえば、プロジェクトが正常に展開された後、プロジェクトチャネルに公開できるSlackリリースボットもあります。更新を見つけるためにGitHubに行く必要はありません！

以上が継続的な展開でプロジェクトバージョンとリリースを自動化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。