既存のCI/CDの問題

CI/CD（※1）により、ビルド、静的コード解析、テスト、デプロイが自動化され、デリバリープロセスは大幅に効率化、高速化されました（ここで、デリバリープロセスは、ビルドからリリースまでの一連の流れを指します）。

これらの自動化を実現するためには、Jenkins（※2）などのCI/CDツールが利用されています。CI/CDツールでは、GUIによる操作が中心であるため、誰でも気軽にジョブの作成、実行、閲覧が可能です。

図1：Jenkinsのジョブ設定画面

しかし、GUIによる設定は、とっつきやすい反面、ジョブの「履歴管理」、「差分管理」、「再利用」が難しいという課題があります。その結果、特定の人しかCI/CDツールの維持メンテができず、デリバリープロセスの単一障害点になってしまうという状況が発生します（しばしば、そういった方は”Jenkinsおじさん”と呼ばれます）。

“Pipeline as Code”というアプローチ

“○○ as Code”という言葉を聞いたことがあるでしょうか？
代表例としてInfrastructure as Code（※3）が挙げられますが、これは”○○の設定をコードで管理する”というアプローチです。このアプローチにより、ソフトウェア開発でのベストプラクティスが適用可能となり、以下のようなメリットがあります。

• 設定の履歴が管理可能
• 設定の差分確認が容易
• 設定の再利用が容易

CI/CDツールにおいても同様に、”Pipeline as Code”（※4）が適用され始めています。SaaS系のCI/CDツール（Travis CI（※5）、Circle CI（※6） など）やJenkins2.0では、簡単なドメイン固有言語（DSL: Domain Specific Language）により、ビルドパイプラインを作成する機能が提供されています。

図2：DSLの一例（Jenkinsの場合）

Pipeline as Codeの今後の課題

Pipeline as Codeにより、ビルドパイプラインの履歴管理、差分管理、再利用が容易になりました。しかし、依然として、新たなDSL、言語、ジョブの書き方を覚える必要があるなど、まだまだ改善の余地があります。

サービス、プロダクトをユーザの元に継続的に届けるためには、CI/CDは欠かすことができません。今後も、CI/CDツールの進化は目が離せません。