Harness(ハーネス)、ブランチごとのCIシーケンスIDを導入

Harness(ハーネス)、ブランチごとのCIシーケンスIDを導入

Harness(ハーネス)は、単一のグローバルカウンターによって引き起こされていた長年の混乱に対処するため、Harness CIにブランチスコープのビルドシーケンスID機能を導入した。この発表では、具体的なシナリオで問題が説明されている。かつては単純な順序を提供していたビルド番号が、パイプラインの実行ごとに単一のグローバルカウンターがインクリメントされるようになったことで、リリースの実態と一致しなくなったというものだ。例として、以前はmainブランチでビルド#47が最新のプロダクションリリースとして表示されていたのに、その後他のブランチで#48と#49が生成され、1週間後にはmainブランチのレジストリーに#47、#52、#58、#61という連続しない番号が反映され、どのビルドが実際にプロダクションに対応しているかを判断するのが困難になったというケースが挙げられている。同社は、このギャップはGitFlow、トランクベース開発、またはその他のブランチ戦略を使っているチームにとって特に問題であると指摘している。ブランチごとのシーケンスにギャップがあると、「mainブランチの最新ビルドは何か?」といった質問に対する明確な回答が妨げられ、アーティファクトの命名とセマンティックバージョニングがリリースの実態から乖離してしまうためだ。

この新機能では、パイプライン式<+pipeline.branchSeqId>が提供され、パイプライン+リポジトリー+ブランチの組み合わせごとに、ブランチごとにアトミックにインクリメントされるカウンターが返される。ドキュメントでは、ブランチとリポジトリーの値は正規化され(refs/heads/プレフィックスが削除され、リポジトリーのURLが正規化される)、異なるURL形式や大文字小文字が同じ論理カウンターにマッピングされることが説明されている。インクリメントはアトミックに保存および更新され、同じブランチでの並列実行がそれぞれ異なるシーケンス値を受け取るようにする。結果として得られるシーケンスIDは実行メタデータに添付され、パイプライン実行コンテキストで公開されるため、実行時に式が解決される。タグのみのトリガーなど、ブランチコンテキストのない実行の場合、式はnullを返すため、パイプラインはフォールバックを提供するか、ブランチ固有のタグ付けをスキップすることが推奨される。

リリースで強調された実用的なユースケースは、アーティファクトのタグ付けとバージョン管理のワークフローに焦点を当てたものだった。例として、<+pipeline.branchSeqId>または<+codebase.branch>-<+pipeline.branchSeqId>のような連結形式を使ってmain-42やfeature-auth-3のような明確なタグを生成するDockerイメージのタグ付けが挙げられた。Helmチャートのバージョン管理の例では、--version 1.0.<+pipeline.branchSeqId> --app-version <+codebase.commitSha>をコミットSHAに設定することで、チャートのバージョンがビルドシーケンスを追跡し、アプリのバージョンが特定のコミットを追跡するようにした。リリース ノートとデプロイメントラベルも自然な組み合わせとして示され、ブランチローカルのビルド番号がステージング環境と本番環境に適用された。この機能は、ブランチシーケンスを一覧表示したり、ブランチとリポジトリーの現在の値を取得したり、カウンターをリセットしたり、カウンターを特定の値に設定したりするREST APIを介して管理できることも説明された。これらの機能は、移行時やメジャーリリース後に役立つと位置付けられている。クリーンアップ動作が確認された。パイプラインを削除すると、孤立したカウンタが残らないように、その分岐シーケンスデータも削除される。

ロールアウトモデルとより広範な位置付けは、実用的なガードレールと業界のコンテキストで説明された。この機能は、CI_ENABLE_BRANCH_SEQUENCE_IDという名前の機能フラグによって制限されており、広く採用する前に、タグとバージョン文字列の動作を確認するために、まず非本番パイプラインで実行することが推奨される。ウェブフックトリガー(push、PR、branch、release)とブランチ構成を使用した手動実行がサポートされているトリガータイプとしてリストされているが、タグのみの実行では、ブランチ シーケンス値に対してnullが返される。リリースで提供されている表形式の比較では、このアプローチが他のCIプラットフォームと比較されている。Jenkinsのマルチブランチジョブは、調整なしでブランチごとに番号が付けられていることが指摘されている。GitHub ActionsとGitLabは、グローバルまたはプロジェクト全体のカウンターを提供していると特徴付けられている。CircleCIはジョブごとにインクリメントすると説明されている。Bitbucket Pipelinesは設計上リポジトリー全体であり、Azure DevOpsはYAML設定が必要なcounter(prefix、seed)を提供していると説明されている。今回のリリースは最初のステップとして位置付けられており、同社は、ブランチごとのカウンター、式サポート、APIなどを含む最初のリリース基盤としてこれらの機能を説明し、機能フラグを有効にしてフィードバックを提供するとともに、プランの権利や開発者向けドキュメントと照らし合わせて機能の利用可能性を確認するよう推奨している。

出典:Harness

この製品の詳細については、Harness製品ページをご覧ください。

You've successfully subscribed to DXable News
Great! Next, complete checkout to get full access to all premium content.
Welcome back! You've successfully signed in.
Unable to sign you in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Billing info update failed.
Dark Light