カスタムワークフローブロック

Workflow blocks are reusable, composable units of automation – the building blocks from which pipelines are assembled without rewriting the same logic for every workflow.

ハードウェアの CI/CD パイプラインでは、同じ操作が繰り返し現れます。承認済みベンダーリストを呼び出す、必須パラメーターが入力されているか確認する、下流システムに通知する、特定クラスの設計データを検証する、といった処理です。ワークフローブロックがなければ、各ワークフローはこのロジックをそれぞれ独立して再実装することになります。ブロックを使えば、そのロジックは一度定義し、一度テストし、必要なあらゆる場所で組み合わせて使えるようになります。

ワークフローブロックは、特定の処理、その入力、出力、振る舞いをカプセル化し、任意のワークフローで使用できるステップとして公開します。ブロックが実装を担い、ワークフローが順序を担います。

Workflow Blocks によって可能になること

• Reuse of validated logic – コンプライアンスチェック、外部システム呼び出し、データ変換を実装するブロックは、単体でテストしたうえで複数のワークフローに再利用できます。基になる要件が変更された場合、たとえば制限部品リストに新しい項目が追加された、調達部門で新たなパラメーターが必須になった、といった場合でも、ブロックを一度更新するだけで、その変更はそれを使用するすべてのワークフローに反映されます。

• Separation of concerns – 調達システムを理解しているエンジニアが AVL 参照ブロックを実装します。リリースプロセスを定義するエンジニアは、それをパイプラインに組み込みます。どちらも相手の領域を細部まで理解する必要はありません。ブロックのインターフェースが、その間の契約になります。

• Incremental pipeline construction – チームはシンプルで手作業のワークフローから始めて、現在は手動ステップになっている処理に対してブロックを導入することで、時間をかけて複雑さを追加していけます。ワークフローに追加されるブロックが 1 つ増えるごとに、誰かが覚えて実行することに依存する作業が 1 つ減ります。

• Standardization across teams – 複数のチームがそれぞれ独自の設計フローを保守している組織では、共有ワークフローブロックにより、チームごとにパイプライン全体の構造が異なっていても、ステップレベルでは一貫した振る舞いを強制できます。たとえばコンプライアンスチェックブロックは、PCB リリースワークフローに埋め込まれていても、ライブラリ承認ワークフローに埋め込まれていても、同一の方法で実行されます。

ブロックとスクリプトの違い

スクリプトは、直接呼び出される自己完結型の処理です。ワークフローブロックは、より大きなパイプラインへ組み込むために設計された、構成可能な単位です。ブロックはしばしばスクリプトを呼び出します。つまり、ロジックを実装するのはスクリプトであり、ワークフローの文脈で利用可能にするインターフェース契約を提供するのがブロックです。

単独で実行する処理が必要な場合は、スクリプトを使用します。その処理を複数のワークフローのステップとして再利用する必要がある場合、実装と利用を切り離す安定したインターフェースが必要な場合、またはパイプラインの順序制御やゲーティングロジックに参加させる必要がある場合は、そのスクリプトをブロックでラップします。