VMWareのシニアスタッフエンジニアであるBryan Liles氏は、CI/CDパイプラインを構築する際のパターンと推奨事項の考えについてDeliveryConfで語った。Liles氏は、単にJenkinsやSpinnakerを使用するような、実装ではなくパターンとしてCI/CDについて考えることを勧めている。交換可能なコンポーネントを備えたコンポーザブルブロックを備え、テクノロジースタックに依存しないプラットフォームを構築できる必要がある。
Liles氏は、いくつの企業がCI/CDパイプラインを従来通りに構築しているかについて話した。これらのパイプラインを使用する目的は、アプリケーションを本番環境に移行することである。本質的に、配信プロセスは、ソースコード管理からアプリケーションコードを取得する。次に、パイプラインはアプリケーションをコンパイルし、そのアーティファクトをバンドルとしてリポジトリに保存する。最後に、パイプラインは、dev、test、prodなどのすべての異なる環境にバンドルを出荷する。Liles氏は、デプロイパイプラインが複雑に見えても、アプリケーションスタックはこれ以上複雑にならないはずだと述べた。
Liles氏によると、エンジニアは、単にJenkinsやSpinnakerを使用するような実装ではなく、パターンとしての構成可能なブロックとしてデプロイパイプラインを再考することができる。たとえば、パイプラインには、アプリケーションの構築、テストの実行、アーティファクトの作成のための統合ブロックを含めることができる。このブロックはJenkinsを使用している可能性があるが、将来的にはCircle CIなどの別のツールを使用する可能性がある。パイプラインの別のブロックは、アプリケーションをデプロイし、承認を求め、データの移行を実行するデプロイプロセスブロックにもなり得る。統合ブロックとデリバリブロックの両方に同じ基本コンポーネントを持つ。それは、Webhookトリガー、ワークフロー、通知、承認である。また、統合ブロックおよびデリバリブロックは、より大きな構成可能ブロックであるデプロイメントパイプラインの一部である。
Liles氏は、「システムにおける構成可能性についてもっと考えなければならない」と述べた。デプロイパイプラインは、アプリをプッシュし、アプリを宛先に発送するサービスとしてのプラットフォーム（PaaS）である必要がある。Liles氏は、デプロイメントパイプラインの名前をコンポーザブルPaaSに変更することを提案した。そこではエンジニアがコンポーネントを簡単に変更できる。Liles氏によると、このパターンの例は、プラットフォームを構築するためのプラットフォームであるKubernetesである。したがって、Kubernetesを使用すると、デプロイメントパイプラインは、統合ブロックおよびデリバリブロックとして同じ基本コンポーネントを持つことができるが、異なるツールを使用する。たとえば、統合ブロックでは、トリガーブロック、ワークフローブロック、通知ブロック、承認ブロックにTektonまたはArgoを使用できる。
さらに、Liles氏は、Jenkins、Spinnaker、ConcourseCIなどのツールは、CI/CDパイプラインの構築方法とそれらの使用方法の定義に役立つと述べた。ただし、これらのツールから学んだ教訓を取り入れ、それらを残しておくことが不可欠であると、Liles氏は述べている。したがって、彼はツールについて別の考え方をすることを勧めている。
私達は本当にツールについて別の考え方をする必要があります。現状では、私たちは現在の場所に到達しましたが、必要な場所に到達していないでしょう。私たちはもっと大きく、別の考え方をするべきです。
最後に、Liles氏は、ツールは複雑となっていると述べた。そして、エコシステムは、より小さく、構成可能なツールの構築に取り組む必要があると述べた。彼は、エコシステムをより洗練させるのではなく、共に改善する方法について研究を始めることを推奨している。彼が提案したブロックは始まりに過ぎない。彼は「ポイントは私たちのシステムの構成可能性についてもっと考えることであるべきだ」と述べた。