継続的デリバリーの実践

 in CI/CD by

（この記事は、CloudBees社 Blog 「Implementing Continuous Delivery」2017年4月27日 Sacha Laboureyの翻訳記事です。）

あなたはDevOpsへの転換の第一歩として継続的デリバリー（CD）を行おうと決断しました。あなたはCDの下準備として色々なことを行っています。

チームに目標を共有させることから始まり、あらゆるもの（アプリケーションとそれをサポートする環境の両方）を自動化およびバージョン管理し、アプリケーションを実稼働環境に出荷する準備が整っていることを確認しました。

さて、CDを実行に移す準備が整いました。どうやって始めましょう？

CDはプロセスであり、スイッチ1つで行えるアクションではありません。計画を立て、実装し、いくつかのステップを踏んで、再評価、改善、再試行のサイクルを回す必要があります。あなたは組織全体の文化を変えようとしており、優れたソフトウェアを提供するためのより良い方法論を約束しています。これだけ大きなことは1回の試行ですべてを達成するのは不可能です。しかし、ゆっくりと一歩一歩前進させれば、始めることができ、いずれ成功できるでしょう。今回はCDの実践に成功した企業が、どのようなステップを進めてきたかを紹介します。

小さな、管理可能なプロジェクトを選んで開始する

よくある間違いは、あまりにも急ぎすぎることです。CDの信奉者はこの方法論に絶大な信頼を置いており、組織のコミットメントを正当化するために早急に大きな利益を生み出そうとする傾向があります。そのため彼らは当たって砕けろとばかりに、複雑なプロジェクトに取り組み、多くの紆余曲折を繰り返します。このような「ビッグバン」アプローチは大きな利益を生み出す可能性がありますが、一方で大きな問題を生み出す傾向があります。

より良い方法は、組織がCDを試して新しい手順に慣れることができるよう、小規模な新規のプロジェクトから始めることです。古いデリバリーパイプラインや古い手順に縛られていない、新しくデリバリー予定の新しい領域を選択してください。アプリケーションに対する小規模で段階な変化をテストするのは簡単です。何か問題が生じた場合は簡単に対処できます。各変更は自動化されたパイプラインを通じてより迅速にリリースすることができ、組織は測定可能で肯定的な結果を生み出すことができます。小さなプロジェクトから始めることで、より短く、より速いパイプラインを実行することができるのです。

プロセスを定義する

最初のプロジェクトを選んだら、デリバリープロセスを定義する必要があります。これは、ホワイトボード上に手続を書き出す程度の簡単さです。Gene Kim著「The Phoenix Project」を読んだ人は、もうこの手順をよく知っています。この本で描かれた企業は、想像できるかぎり、ありとあらゆるITデリバリーの問題に直面していました――IT担当VPのBill Palmer氏が継続的デリバリーを実現するまでは。最初のステップは、各従業員にホワイトボード上にデリバリープロセスのステップを書き出させ、それらをリンクさせて、組み立てラインプロセスを作成する方法を考えさせることでした。その後、チームは一丸となって取り組み、ワークフローを作成し、自動化しました。

確かに、素晴らしいツールセットを購入し、積極的な目標を作り、チームをやる気にさせることはできます。しかし、プロセスを計画し、チーム全員がプロセスを理解し、役割を割り当てるまで、開始することはできません。

非難しない文化を確立する

CD実践の前提条件の1つは、開発、QA、および運用チームが目標を共有しなければならないという要件です。これは不可欠な要件です。しかし、それで「人間関係の仕事」は終わりではありません。CDを実践する際には、本当に非難しない文化が醸成されているかを継続的にチェックする必要があります。CDの実践では必ず問題が発生するものなので、互いに非難の指を突き付けあうことなくポジティブな方法で問題を切り分けできるようにする必要があります。うまくいっているDevOps文化は失敗を受け入れ、積極的にリスクを取ります。CDに移行することはリスクであり、プロセスを継続的に改善するには、チームが常に冷静に改善を続ける必要があります。

測定基準を設定し、成功を計測する

プロジェクトの価値を繰り返し定量化する必要性を説くオピニオンリーダーは、Forresterのアナリスト、Kurt Bittnerだけではありません。しかしBittnerは、誰にもまして明確に、ソフトウェアデリバリープロジェクトで何を測定するべきか、またどうやってプロセスのすべてのステップにそれらのメトリクスを適用するかを提示しています。測定しなければ、早期に頻繁に改善することはできません――これは事実です。したがって、あなたが継続的デリバリーに着手する際に重要な過程の一つは、何を改善するか、どうやって改善を測定するかを決めることです。次に、一連のベースライン測定値を設定します。それができたら、開始です。

コードとしての構成を採用する

継続的デリバリーの重要な側面の一つに、構成の自動化があります。このコードとしての構成というDevOpsプラクティスは、CDプロセスの一貫性を保証し、リリースを本番環境にプッシュするたびに構成を再構築した結果生じる可能性のある問題を解消します。

CDの実践にあたっては、Chef、Puppetなどの構成管理を可能にするツールを利用するとよいでしょう。これらのツールを利用するDevOpsも増えています。最近のCloudBees出資によるDZoneの調査によると、企業の49％が構成管理ツールを使用し、48％がインフラストラクチャの変更とシステム定義にバージョン管理システムを使用しています。しかしその一方で、73％の企業が、インフラストラクチャの変更の少なくとも半分で手動スクリプトを使用する必要があると答えており、まだ改善が進んでいる途中の企業が多いことが分かります。

プロセスオーケストレーション

パイプラインの定義が完了したとしましょう。次はそれをオーケストレーションする必要があります。代表的なツールがJenkinsです。これは長い期間を要するプロセスですが、Xebia LabsのAndrew PhillipsとCloudBeesの川口耕介によるホワイトペーパーに記載されている概要に従って、いくつかのステップを実行するとよいでしょう。

  • 再現可能なビルドを確実にする – ビルドシステムがビルドジョブのワークスペースに接続されたクリーンリポジトリを使用し、中央の共有リポジトリからビルド依存関係を取得するように構成します。
  • パイプラインを介してビルド成果物を共有する – リリース候補成果物がパイプラインのすべての後続ビルドで使用されていることを確認します。
  • 各ステージに適切な粒度を選択 – パイプライン内のすべてのステップを複数のステージに分散することで、ボトルネックをより簡単に特定できます。
  • パイプラインの視覚化 – ビルドパイプラインの明確でアクセス可能なビューを作成し、ビジネスマネージャーやその他のステークホルダーに円滑にプロセスのステータスを伝達し、透明性を確保します。

まとめ

継続的デリバリーは、初めは困難に見えても、実践する価値のあるチャレンジです。自由に利用できる多くのJenkinsプラグインを含め、自由に使用できるツールが用意されています。少しの大胆さと十分な慎重さをもってすれば、CDプロジェクトを開始し、最終的にはあなたにも、チームにも、会社にも、そして顧客のためにも、確かなメリットを生み出すことができます。

さあ前進！

Sacha