CI/CDパイプラインは、あらゆる言語やツールのためのセマンティックなバージョニングを備え、迅速かつ簡単です。 ツールの新しいバージョンをリリースすることは退屈でなければなりません. 儀式はなく、会議の予定もなく、議論さえありません. それは透明で、簡単で、信頼性があり、さらには情報性があります。 しかし、チームがDevOpsソリューションを実装するのを助けるソフトウェアコンサルタントとして、私はしばしばそうではないことを発見します。私が見つける品質は非常に異なりますので、私が嫌いなものをあなたに伝える代わりに、新しいリポジトリを迅速かつ容易に搭載するためにパイプラインを構造する方法に焦点を当てましょう。 私の視点を理解するために、私はこのトピックに対する私の見解が何年もの間どのように進化してきたかを共有したいと思います。現在、私は、パラメータの変更などの小さな変更でモジュールワークフローの「LEGOブロック」を整理することを含むプロセスを適用しています。 たとえば、Rust ライブラリ X のビルド プロセスは Rust ライブラリ Y とほぼ同じで、Node サーバー foo は Node サーバー バーとほぼ同じです。 長年にわたり、私はこれを達成するためにオープンソースのコンポーネントを組み合わせようとしましたが、正しい組み合わせを見つけることはありませんでした。 しかし、まず... 私はバージョニングとリリースが最もエキサイティングなトピックではないことに気づいていますが、すべてのプロジェクトが直面する問題です(おそらく特に!) それを正しく行うことで、プロジェクトはよりプロフェッショナルに見えるようになり、ユーザーに変更を伝えることができます. This establishes more trust in your projects by helping developers understand and adopt new changes in a clear and consistent way. 初めから... 私のソフトウェアエンジニアリングのキャリアの初めに、リリースはかなりイベントでした。それらは、一連のスプリントを通じて達成されたマイルストーンの副産物であり、すべての能力の最高に計画され、バックロッグがスライドされ、価値のあるタスクが選択された計画会議のシリーズでした。 私たちは、プランの仕様を書くために最善を尽くし、フィボナッチ番号やTシャツのサイズ、または最悪の場合、数日を推定します。 リリースはこのプロセスの頂点でした。 配信可能な配信は、実際のユーザーに配信されました。 このプロセスの頂点として、そしてそれを正しくするための高い賭けとして、リリースは感情的な瞬間でした。 エキサイティング? 怖い? もしかしたら、あなたが引き起こした数人は、彼らが機械を動かすときにあなたのハートをレースにしました。 バージョン番号を決定するための詳細とドラマもあります。 これは大きなリリースですか? まったく新しいバージョンですか?? マイナーですか? パッチですか? 時々、マーケティングがバージョン... 2.0 を指令しました! 私のキャリアのこの時点では、このバージョン番号の話題で重要なのは私の意見ではなかったし、振り返ってみると、それはおそらく誰の意見でもなかったはずだった(私は後で何を意味するかを見るでしょう)。 私は最初にリリースに責任を負いませんでした...しかし...それは永遠に続くことはありませんでした。 オープンソースへ 私のキャリアのある時点で、オープンソースに貢献することに興味がありました. 一般的に、npmモジュールの形で、当時私はノードに非常に興味がありました。 解放の責任を担うのが私の番でした。 マット・ウォルターズと僕が一緒に走っていたNYC NodeJSミーティングの一部を通じて、もしかしたら何らかのニュースレターを通じて、どうしてか覚えていません。 セマンティックリリースは、ウェブ開発者として、セマンティクスに基づく懸念の分離の原則を実装しました。 semantic-release あなたが走り出してセマンティックリリースを使用し始める前に、私はそれに遭遇したいくつかの制限があります...そして私は一瞬でそれらに到達します。 まず、高いレベルで、セマンティックリリースが説教した基本的なアイデアは、コミットメッセージの特定のフォーマットに従うことであり、メッセージに基づいて、バージョンが計算できることでした。 それは、実際に変化したものに基づいて、リリースから感情を除去し、それらをロボット化することについて話していました。 たとえば、新しいメジャーバージョンのリリース(v2 から v3)があった場合、それは大きな変化があったことを意味します。 このことをコミットメッセージに表示するには、あなたは コミットメントの体内で BREAKING CHANGE: feat: revamp user auth flow BREAKING CHANGE: Per Chad's "game-changer" vision in the 3am Slack rant, we've ditched the old auth system for a blockchain-based solution because "passwords are so 2024." Update your clients or enjoy the 500 errors! v2.0.0 から v2.1.0 までの小さなバックアップは、新しい機能が追加されたことを意味しました。 feat: add dark mode toggle Per the 47-comment thread in the "urgent" ticket, users can now save their retinas. Dark mode added, but brace for the inevitable "make it darker" feedback. パッチバージョンは修正、またはリファクター、または基本的に新しいリリースを引き起こすべき他のすべてをシグナルしました。 fix: revert "fix" by AI that skipped the breaking tests to avoid the failure そして最後に、いくつかのコミットはまったくリリースを引き起こさないはずです。“Chores”は私に紹介されたように、No-opsは、私がそれらを呼ぶように。 chore: update release pipeline version from v3.1.0 to v3.1.1 このコミットメッセージの特定の形式は、 You can check out their page for the full spec, but I wanted to share the gist of it. あなたは完全なスペックのために彼らのページをチェックすることができます。 従来のコミットメント さらに、コミットに含まれるこの情報は、変更ログとして表面上に表示されることもできます - 例えば、破壊的な変更を強調します。 What's new in v2.0.0 * feat: remove deprecated API BREAKING CHANGE: the FooBar API that was deprecated. To upgrade, you can use the new BazBar API. だから、しばらくの間、セマンティックリリースは私にとって素晴らしいものでした。ノードプロジェクトにとっては、それはまだ... しかし... DevOpsについて 私は常に、スケーラブルな分散システムを構築する方法のアイデアに興味を持っていたので、それは私のキャリアでかなり長い間追求してきたものだった。 これらはnpmモジュールではなく、アプリケーション、サービス、データベース、列でした! I loved the simplicity of semantic-release, but it only worked well for Node.js projects. 確かに、あなたは、私は数回、追加することができます。 ノード以外のプロジェクトにファイルを送信しましたが、それは最善のところ混乱とハッキングでした。 package.json この頃、私はJenkinsの時代にDevOpsに深く関わり、Dockerがトラクションを獲得し始めた。 私はJenkinsでパイプラインを書くことを学び、Docker Swarmですべてを展開しました! 私の初期のDevOpsの旅とデプロイのためにDockerの発見。 私の最近の、まだ関連性があり、正確なGit with Trunk Based Developmentガイド記事は、あなたが興味がある場合は、なぜか、どのように説明します。 私の最近の、まだ関連性があり、正確なGit with Trunk Based Developmentガイド記事は、あなたが興味がある場合は、なぜか、どのように説明します。 私は常に、私が取り組んだこれらのプロジェクトが、セマンティックリリースプロジェクトのようにバージョン化され、リリースされることを望みましたが、同じように機能するソリューションを見つけたことはありませんでした。 それは私のリストで最も重要なことではなかったので、私は一般的にそれを十分に良いと言い、欠点と共に生きていました。 時間の経過とともに、DevOpsのコンサルタントとして、私は複数の言語とフレームワークでさまざまなプロジェクトに出会い、リリースし、それぞれバージョンアップ、リリース、変更ログを必要としました。 私がしばしば遭遇したもう一つの頭痛は、大きな、モノリチックなパイプラインでした。ジェンキンズ時代から来て、私はそれを手に入れました、これは私もパイプラインを書くために使われていた方法です。私は大きな一連のステップで完全なリリースフローを試みて、メインに押すことから始めました。 これはそれ自体では恐ろしいものではなく、ほとんどの場合「十分」である可能性がありますが、DevOpsコンサルタントとして、私はそれを繰り返ししなければなりません。より小さく、よりモジュール化されたパーツに物事を分解すると、これらのパーツがより多くのプロジェクトに役立つことができます。 つまり、UNIXの哲学を採用することから生まれたアイデアです。 アイデアのカバー たとえば、Node Quality パイプラインはすべての Node プロジェクトで同じであり、標準の npm スクリプト規約に従うと仮定し、パイプラインを実行するための一般的なパイプライン、ビルディング、およびユニットテストは、ほとんどの場合、すべての Node.js プロジェクトで共有することができます。 and etc., and the scripts section of the ファイルは、それが起こるときに何が起こるかを決定します。 コマンドは走る。 npm run lint --if-present package.json lint バージョニングとリリースのための高レベルのパイプライン 高いレベルでは、リリースする必要があるすべてのプロジェクトが最初に新しいバージョン番号でタグされ、その後、バージョン番号に関連付けられたリリースが作成され、関連パイプラインの一部としてアーティファクトが生成されます。 私は最も頻繁にGitHub Actionsを使用していますが、パイプラインは商品であると考えており、これから始めるのは簡単です。私は多くを使用しましたが、すべては基本的に同じです - 共有ボリュームで一連のステップを実行します。 バージョン化自体は、従来のコミットがセマンティックなバージョン増加に結びついているという基準に従っている場合、言語特有のものではありません。 長い間、私はリリースをバージョンに結びつけており、実際には2つの異なる実体が結びついているとき、それらは同じものの一部だと思っていた。 それらを分割すると、パイプラインのバージョン部分が独自のモジュール部品となり、その後、そのバージョンの構築とその後のリリースを引き起こした。 それぞれのプロジェクトに対して、GitHub Actions では、2 つのパイプラインがあります。 On commit to the trunk branch, version, and tag When a commit occurs in the trunk branch (usually or ), trigger a pipeline that runs quality checks, and, if they pass, calculates a new version number. It then creates and pushes a tag with that new version number. We can also use this opportunity to update that version number in the code base if necessary, and generate a change log from the commit data that was used to calculate the new version number. main master When a tag is created, build new versions and release them. This step is simplified by the previous step of doing the version bump. Everything’s already been bumped to the new version. We can just run build and release using the tag as the base. 前述したように、GitHub Actions Marketplaceからオープンソースのコンポーネントを組み合わせようと何度も試みた後、私はついに諦め、ステップ1を扱う自分のツールを書きました。 導入 vnext 次の vnext は、従来のコミット メッセージを使用して次のセマンティック バージョンを計算し、簡素化されたリリースのためにメジャー、マイナー、またはパッチ ブームを自動化する高速な Rust CLI ツールです。 こちらは、どう使うかです。 NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md かなりシンプルだと思うけど、どう思うか教えてください。 それは完全にプロジェクトの git 歴史に基づいています。 どの言語やツールをリリースしているかは関係ありませんが、バージョニングプロセスは基本的に同じです。新しいバージョンを取得し、いくつかのファイルで更新し、Changelog、タグ、Pushを作成します。 迅速かつ簡単にインストールする方法 via ── 設定が完了したら、実行できます: vnext ubi 『Universal Binary Installer』 ubi --project unbounded-tech/vnext また、あなたが呼び出せる共有の GitHub アクションワークフローを作成し、すべての詳細を処理しました。 共有ワークフローを使用する方法は次のとおりです。 name: On Push Main, Version and Tag on: push: branches: - main - master permissions: packages: write contents: write jobs: version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1 with: useDeployKey: true changelog: true ほとんどのプロジェクトでは、新しいバージョン番号でどのファイルを更新するか、どのように設定するかを設定する必要があります。 現在、 2 一般的な方法をサポートする( そして )およびいくつかの言語特有のオプション。 vnext yqPatches regexPatches 言語特有のオプションは最も使いやすいです. たとえば、 2位 利用 プロジェクトのパッケージファイルを更新します。 with.node true npm ツールを使う YAML ファイルの特定のフィールドをパッチするために. I often use this for updating version numbers in Helm charts: yqPatches yq version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1.13.0 secrets: GH_PAT: ${{ secrets.YOUR_ORG_SECRET_PAT }} with: usePAT: true changelog: true yqPatches: | patches: - filePath: helm/values.yaml selector: .image.tag valuePrefix: "v" - filePath: helm/Chart.yaml selector: .version valuePrefix: "v" また、デプロイ キーの代わりに Personal Access Token を使用する方法を共有する機会も利用しました。 また、デプロイ キーの代わりに Personal Access Token を使用する方法を共有する機会も利用しました。 利用 新しいバージョン番号を挿入した文字列を検索して置き換える。 regexPatches sed regexPatches: | patches: - filePath: package/composition.yaml regex: /ghcr.io/org-name/package-name:(.*)/g valuePrefix: ghcr.io/org-name/package-name:v - filePath: README.md regex: /Current version: v[0-9]+\.[0-9]+\.[0-9]+/g valuePrefix: Current version: v 選択肢の組み合わせも利用できます。 GitHubのアクションについてのニュアンス GitHub Actions でアクションを実行する場合、デフォルトでは、ワーカーが一時的な GitHub 認証トークンを生成します。このトークンにはいくつかの基本的なタスクを実行する権限がありますが、他のパイプラインを引き起こすことは決して許されません。 しかし、新しいバージョンをタグ化した後の次のステップは、そのタグで別のパイプラインを起動することでした! 心配しないでください、これはデザインによって──単にGitHubによって行なわれた措置で、ランナーの群れを意図せずに回転させないようにします。 それについて意図的にすることにはいくつかの方法があります - 私はすでに2つの例を示しました: デプロイ キーと GitHub Actions Secret を使用する Personal Access Token を GitHub Action Secret として使用する方法 GitHub アプリケーションの作成(理論的には、私はこのオプションを必要としなかった) 個人アクセストークンの使用は、組織全体の秘密が利用可能であるため、GitHubエコシステムの有料顧客である場合に便利です。 フリーレベルでは、それはオプションではありませんので、代わりにデプロイキーを設定する方法を示します。 実際、私はそれを構築することによって非常に単純にしました。 CLI. It is a great option, as when configured this way, no human needs to know it, and it can easily be rotated by rerunning the same command. vnext 設定したいリポジトリごとに デプロイキーでリリースするには、プロジェクトのディレクトリに... vnext まずは、AUTHトークンを使うこと。 キーを管理する権限: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) そして、走る: vnext generate-deploy-key You may be wondering, can’t this go into a pipeline itself? Unfortunately, I can’t find a way to automate this step in Github Actions without creating a Personal Access Token, as the default token can not modify Secrets. This defeats the pupose of using a Deploy Key instead in the free tier, as you’d need to create it in every repo. This requires some sort of secret management to make it easy, and thus makes it more work than using a deploy key. I have thought of it. :) あなたは疑問に思うかもしれないが、これはパイプライン自体に入ることはできないだろうか?残念ながら、私はPersonally Access Tokenを作成することなく、Github Actionsでこのステップを自動化する方法を見つけることができないので、デフォルトのトークンはSecretsを変更することはできません。 デプロイキー、またはPAT(Personal Access Token)が適用され、バージョンとタグのワークフローがあなたのトランクブランドに押し付けられると、次のステップはリリースすることです! これはプロジェクトごとに異なりますが、すべては前のステップからタグ付けされたバージョンによって引き起こされます。 name: On Version Tag, Trigger GitHub Release on: push: tags: - 'v*.*.*' permissions: contents: write jobs: release: uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} もし、Rustプロジェクトだったら、もしかしたら、こういうものかもしれない。 name: On Version Tagged, Build and Publish Rust Binaries on: push: tags: - "v*.*.*" permissions: contents: write jobs: build-and-release: uses: unbounded-tech/workflows-rust/.github/workflows/release.yaml@v1 with: binary_name: ${{ github.event.repository.name }} build_args: "--release --features vendored" または、Dockerfile と k8 のリソースの定義が Gitops のデプロイに含まれるアプリケーションだったら、もしかしたら、以下のようなものかもしれません。 name: promote on: push: tags: - v*.*.* permissions: contents: write packages: write issues: write pull-requests: write jobs: publish: uses: unbounded-tech/workflows-containers/.github/workflows/publish.yaml@v1.1.1 release: needs: publish uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} promote: needs: release uses: unbounded-tech/workflows-gitops/.github/workflows/helm-promote.yaml@v1 secrets: GH_PAT: ${{ secrets.GH_PAT }} with: environment_repository: your-org/staging-env path: .gitops/deploy project: staging 注: デプロイ キーは、gitops プロモート ステップのように他の repos に押すことができませんので、この repository のどこにでも PAT を使用することを検討する場合があります。 注: デプロイ キーは、gitops プロモート ステップのように他の repos に押すことができませんので、この repository のどこにでも PAT を使用することを検討する場合があります。 一般的に、各リリースは、これらの類似モジュールのいくつかの部分の組み合わせであり、それらの特定のツールや言語に対してはほとんど同じことをします。 通常、組織は少なくとも、構築するアプリケーションやサービスで同じパターンの多くを追跡しようとしますので、ワークフローを共有モジュールに分解すると、開発者はそのタイプの各プロジェクトにこれらの共有ワークフローの呼び出しの味をコピーして貼り付けることができます。 Changelogs による一貫したリリース あなたがたは、わたしの種の視線をその上に注目したのかもしれない。 これは成熟したリリースプロセスの重要な部分であるため、バージョンステップのフラッグに戻りたいと思いました。Changelogは、プロジェクトが他の開発者に変更された方法を伝える方法です。 with.changelog バブルバージョンとともに、 また、Commit メッセージを使用してこのChangelogを構築し、バージョンタグとバンプと共にコミットされる CHANGELOG.mdというファイルに保存します。 vnext 私が上記で共有したリリースワークフローに隠されたこのファイルは、GitHubリリースの体として使われています。 プロジェクト自体: vnext このリリースは修正版であり、依存性バージョンバンプの形で修正を含んでおり、その他いくつかのチャーリーも含まれていた。 これらのリリースノートは、その後、他のツール、例えば , あなたの依存性を最新に保つためにPRを作るツール。 リニューアル Pull Requests を合併するとき、GitHub の Squash and Merge 機能を使用して、Changelog で使用される素敵な最終的なコミット メッセージのタイトルと体を書く機会を得るのが好きです。 例えば: 例に示すように、完全な Markdown をコミット体として設定できます. It will be rendered appropriately in the Release Notes! 結論 バージョニングとリリースが最もセクシーなテーマではないことは知っているが、それはかなり退屈なことだ - むしろ、そうすべきだ! しかし、それは必ずしもそうではない、だからこそ私は創造したのです。 and a bunch of 今、私は簡単にほとんどのプロジェクトを非常に迅速に搭載することができます! vnext 共有ワークフロー きっと、あなたにも役に立つと思います! Please let me know if you give そして、いくつかの共有ワークフローを試してみてください! 私はGitHubでいくつかの星を評価し、役に立つと感じたらシェアします! vnext
