継続的デリバリーの原則

CD は、設計、製品、マーケティングなどの非エンジニアリング チームを含む、組織全体の包括的な方法論です。CD では開発者はエンド ユーザー製品のデリバリーに集中することを奨励しますが、非 CD 環境は「想定外の」動作を奨励します。その中で、QA チームは開発者が関係する主要なユーザー エクスペリエンスになります。次のセクションでは、CD ワークフローの基礎となる具体的な原則について説明します。

組織のプロセスには、独自の開発ライフサイクルがあります。通常、手動チェックリストまたは「プレイブック」として始まります。これらのプレイブックは、手動で実行されるタスクのリストです。その後、ソフトウェア ツールとスクリプトを使用して自動化できます。これらのプレイブックをソフトウェア スクリプトにコミットすることで、繰り返し可能であることが保証されます。チェックリストを再度実行する必要がある場合は、チーム メンバーはスクリプトを実行できます。これらのプレイブック スクリプトが環境間で一貫して実行されると、信頼性が向上します。たとえば、開発環境またはステージング環境にコードをデプロイするためのプレイブックは、できるだけ本番環境に近づける必要があります。環境と実行の間のこの信頼性の高い一貫性により、クラス全体の一貫性バグが排除されます。

自動化は CD の重要な価値です。人間の時間は高価であり、つまらないプレイブック タスクの実行ではなく創造的な活動に保守的に投資するべきです。手動プロセスは、コードにコミットされ、オンデマンドに自動で実行されるまで、本当の意味で繰り返し可能で信頼性が高いとは言えません。自動化タスクをまとめて構成して、さらに高度な自動化を実現できます。テスト、リリース、構成の変更などを可能な限り自動化します。

CD の基礎であるバージョン管理は、重要なソフトウェア プロジェクトには不可欠です。バージョン管理によって、開発者のチームは共有コードベースで効率的に共同作業できます。最も広く使用されているバージョン管理システムである Git は、CD にも最適です。バージョン管理は、以前のリリース候補へのロールバックを可能にすることで、「元に戻す」機能を有効にします。コードに加えて、履歴全体の編集を追跡するために、設定、スクリプト、データベース、ドキュメントのすべてのバージョン管理が必要です。

CD では、品質は QA チームに丸投げされません。品質は、リリース パイプラインのあらゆるステップで洗練されます。CD の中心的なフィードバック ループは、エンド ユーザーにデリバリーされる品質の継続的な再検査です。新機能は、新しいコードにバグがないことを確認し、品質の期待を満たすことを保証する一連の自動テストで提供されます。新機能リリースのプロジェクト計画には、分析、パフォーマンス監視、自動テスト インストゥルメンテーション タスクに関する考慮事項を含める必要があります。

面倒くさい、時間がかかる、エラーを起こしやすいタスクは、時間がたつほど複雑になります。面倒な作業は、エネルギーの雪だるま式な損失を防ぐために、できるだけ早く対処する必要があります。1 回に 20 分かかる週に 5 回実行される面倒な作業を想像してみてください。それは週 100 分の忍耐に及びます。1 か月なら約 400 分です。このような作業に対処して、面倒な作業を完全に防ぐために最適化できると想像してみてください。どう考えても取り組まない手はありません。

「最も難しいところこそ先に」は、組織プロセスの弱点を特定する上でも有効です。先延ばしや積極的に回避されているタスクがある場合、それは改善できる領域である可能性があり、積極的に追求すべきであるという指標です。チームは定期的に難題に触れて理解を維持し、それを計画の検討の最前線に置く必要があります。

エンド ユーザーの成果物が可能な限り高品質であることを保証するために、組織全体が集中していて、インセンティブを与えられている必要があります。プロダクト マネージャーは、デプロイと品質保証に注意を払って計画する必要があります。セキュリティ チームは、リリース プロセスに積極的に関与する必要があります。QA チーム メンバーは、最終的なリリースの前に障害を検出するために、本番環境と同じ厳格さで開発環境とステージング環境をテストする必要があります。開発者は積極的に本番リリースを計画する必要があります。

ソフトウェア企業は、エンド ユーザーにソフトウェアを提供するためにビジネスを行っています。アプリが 1 人の開発者のマシンでのみ動作する場合、ビジネスはありません。「自分はこれでいい」は、全体的なビジネス目標に対する意識とエンド ユーザーへの共感の欠如を示す一般的な危険信号を表した言葉です。CD は、エンド ユーザーへのソフトウェアのリリースに完全に焦点を当てています。さらに、「完了」は、個々のチーム メンバーの貢献が完了したときではなく、チームの貢献全体が完了したことを意味します。

前のセクションで、CD にいかに価値があるかをご理解いただけたと思います。マクロ レベルでは、CD は、実行効率、チーム間のコミュニケーション、製品の市場適合性、アジャイル性、組織全体の透明性を促進します。

ミクロ レベルでは、明示的な追跡指標の測定値を使用して CD を計測できます。価値がある CD 指標は次のとおりです。

• 新機能の設計段階から本番リリースまでの時間
• ユーザーが遭遇した本番環境でのバグの数
• 新機能に対するユーザー エンゲージメントのレベル
• 新機能リリースの頻度

さらに、CD は KPI などの組織パフォーマンス指標を構築するための基盤として使用できます。最終的には、営業収入と財務健全性が組織の慣行の影響を測定するのに最適な方法です。

CD のメリットと理念を理解できたら、次のステップはその実装です。良い出発点は、継続的なインテグレーションです。継続的なインテグレーション (CI) は、CD の先駆けです。CI はコード リリースのワークフローの自動化に焦点を当てており、自動化されたコード テスト ツールと品質保証タスクを使用して実行されます。CI が導入されたら、その上に CD プロセスを構築して、エンド ユーザーにコードをデプロイし、将来のリリースを進めるフィードバック ループを開発できます。