私のリリースパイプラインはリリースの出荷を拒否した。それは正しかった。

最近、私のリリースパイプラインがリリースの出荷を拒否するという事態に直面しました。このインシデントは私のプロジェクトを救っただけでなく、堅牢なリリースプロセスを持つことの重要性を浮き彫りにしました。

インシデント

私は、agentsec-ecosystem の agent-security ツールの一部である自身のプロジェクト、agentwatch のリリースを開始しました。リリースワークフローが起動し、いくつかの重要なタスクを実行しました:

1. wheelのビルド: これは、簡単にインストールできるパッケージを作成するプロセスです。
2. Software Bill of Materials (SBOM) の生成: このドキュメントにはソフトウェア内のすべてのコンポーネントがリストされており、セキュリティとコンプライアンスにとって重要です。
3. チェックサムの書き込み: これらは、ファイルが改ざんされていないことを保証するための、ファイル固有の識別子です。
4. キーレス Sigstore ですべてに署名: これは、リリースの真正性を検証することでセキュリティのレイヤーを追加します。

しかし、ワークフローは最後のステップである「公開前のリリースの検証」で失敗しました。受け取ったエラーメッセージは次のとおりです:

ModuleNotFoundError: No module named 'cryptography'

この失敗により GitHub リリースは作成されませんでした。これはもどかしいことでしたが、最終的には良いことでした。システムが設計どおりに機能していることを示していたからです。

なぜこれが起きたのか？

この失敗は、リリースパッケージがインストールされ検証されるはずだったパイプラインのステップで発生しました。失敗した具体的なコマンドは agentwatch verify-release, クリーンな環境からビルドされたアーティファクトをチェックするものです。このワークフローの設計は、正常に検証されない限りアーティファクトの公開を拒否するため、極めて重要でした。

このケースでは、エラーの原因は 'cryptography' という見つからないモジュールにありました。このモジュールはオプションのエクストラと見なされていたため、リリース環境にはインストールされていませんでした。問題が発生したのは、コードが InvalidSignature を 'cryptography' モジュールからトップレベルでインポートしようとしていたためであり、これは不要な場合でもロードされることを意味していました。

リリースを救った設計

私のリリースワークフローの設計には、重要な前提条件が含まれていました。もし agentwatch verify-release コマンドが実行できなければ、何も出荷されないということです。この判断により、問題のあるリリースになり得たものが実行失敗へと変わり、ユーザーに届く前に問題に対処することができました。

エラーのトレースバックから、インポートチェーンに原因があることがわかりました。この障害は、CLI が起動時に、基本的な機能には不要なモジュールも含めてすべてをロードしようとしたために発生しました。これはソフトウェア開発でよくある問題であり、依存関係が予期せぬ問題を引き起こすことがあります。

問題の修正

この問題の修正はシンプルでした。私は InvalidSignature のインポート文を、実際にそれを必要とする関数の内部に移動しました。こうすることで、インポートは関数が呼び出されたときにのみ実行され、起動時の不要なロードを回避できます。変更の簡略化されたバージョンは次のとおりです:

def _verify_signature(public: Any, alg: str, signing_input: bytes, signature: bytes) -> bool:
    from cryptography.exceptions import InvalidSignature  # lazy import
    # rest of the function...

この調整により、署名検証に特に必要とされない限り、'cryptography' モジュールを要求することなく、残りのコードを実行できるようになりました。

まとめ

この経験から、適切に設計されたリリースパイプラインの価値を学びました。これはデプロイプロセスを自動化するだけでなく、従来のテスト方法をすり抜ける可能性のある問題を検出するセーフティネットとしても機能します。

メリット

• 欠陥のあるリリースの防止: 問題がユーザーに届く前に検知します。
• コード品質の向上: チェックを強制することで、より良いコーディングプラクティスを促進します。
• 信頼性の向上: リリースプロセスに対する信頼を構築します。

デメリット

• 初期セットアップの複雑さ: 堅牢なパイプラインの設計には時間がかかる場合があります。
• 誤検知の可能性: 厳格なチェックにより、正当なリリースがブロックされることがあります。

注意事項

この記事は教育目的を意図したものです。実際のシナリオでは、プレースホルダーの値は実際の値に置き換える必要があります。依拠する前に、必ず元の情報源に照らして主張を検証してください。

よくある質問

• リリースパイプラインとは何ですか？ — リリースパイプラインとは、ソフトウェアを準備してデプロイする一連の自動化されたステップのことです。
• なぜリリースパイプラインが重要なのですか？ — ソフトウェアがユーザーにリリースされる前にバグやエラーを検知し、品質を向上させるのに役立ちます。
• ModuleNotFoundError は何を意味しますか？ — 現在の環境で必要なモジュールが利用できないことを示します。
• ModuleNotFoundError はどのように修正できますか？ — 不足しているモジュールが環境にインストールされていることを確認してください。
• Software Bill of Materials (SBOM) とは何ですか？ — SBOM はソフトウェアパッケージ内のすべてのコンポーネントのリストであり、セキュリティとコンプライアンスに役立ちます。
• キーレス Sigstore とは何ですか？ — 手動でキーを管理することなくソフトウェアリリースに署名する方法です。

タグ

#release #pipeline #software #development #automation #quality #security #testing