Close

継続的デリバリーの原則

これらのスタート ガイドで、継続的なデリバリーの背景にある基本原則を理解しましょう。


継続的なデリバリー (CD) は、多くの優れた過去のアジャイルと組織の、一連のベスト プラクティスです。CD は、合理化されて自動化されたソフトウェア リリース プロセスのビルドに重点を置いています。リリース プロセスの中心となるのは、反復的なフィードバック ループです。このフィードバック ループは、可能な限り迅速なエンド ユーザーへのソフトウェアのデリバリー、実際的なエクスペリエンスによる学習、次のリリースへのフィードバックの反映を中心に展開します。

継続的インテグレーション、継続的デリバリー、継続的デプロイ

常時稼働サービスを実現するには、チームの構造、価値、ツールを整合させることで、オペレーショナル エクセレンスがコア コンピテンシーになるようにする必要があります。記事を読む

継続的デリバリーのビジネス価値

継続的なデリバリーのビジネス価値は、テクノロジー ダーリン (投資家が好む企業) だけのものではありません。CD はソフトウェア開発チームのベロシティ、生産性、持続可能性を向上させます。記事を読む

バリューストリームマッピング

バリュー ストリーム マッピングは、継続的なデリバリー パイプラインの最適化に役立つ分析手法です。この手法の使用方法と採用理由をご確認ください。記事を読む


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

コンピューター コードと作業項目の継続的な流れを示す図。| Atlassian CI/CD

繰り返し可能な信頼性の高いプロセス

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

すべてを自動化する

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

バージョン管理

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

ビルドイン品質

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

最も難しいところこそ先に

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

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

全員が責任を持つ

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

チームはリリース前にコードの検査に協力している。| Atlassian CI/CD

「完了」とはリリース済みということ

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

継続的改善

継続的なデリバリーの価値

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

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

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

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

継続的なデリバリーの開始

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

Max Rehkopf
Max Rehkopf

自称「無秩序なタイプ」である私の毎日に秩序をもたらしてくれるのが、アジャイルの実践とリーン方式です。ここから学んだことを、アトラシアンの数々の記事や講演、動画を通して他の人と共有することが、私の喜びです。


おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

ブログを読む

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up