早めのテスト、手軽なコラボレーション、こまめなデプロ イ
現在、最も魅力的で最先端を行くアプリケーションは、最新の開発手法に従って 構築され、デプロイされています。このような手法には、開発者の生産性や効率性、開発速度を向上させるだけでなく、アプリケーションの品質を高めるように最適化されたプロセスやワークフローが組み込まれています。現在、アジャイル開発手法と分散バージョンコントロールシステムの採用は広がりを見せていますが、これらを補うために、チームのアプリケーションリリースプロセスを効率化する新しい手法として、継続的デリバリー（CD）が登場しました。
継続的デリバリーの特徴としては、短いリリースサイクル、自動化、ソースコー ドリポジトリへの直接接続などが挙げられます。また、チームが本番環境のアプリケーションを、すばやく、安全に増分アップデートできるように設計されています。CD プロセ スが成功すると、組織のテクノロジー、関係者、文化の足並みが揃い、デプロイが効率化され、アクティビティが自動化されます。また、企業やエンドユーザーには、新しい機能の配信が早まり、アプリケーションの品質が上がるというメリットがあります。
Heroku Flow
Heroku プラットフォームは、アプリケーションの最初のビルドから、運用、さらにその先まで、開発者の生産性を最大化し、すばらしい経験を提供することを目的に設計されています。この一環として、Heroku は、継続的デリバリなど、最新の開発習慣をサポートするさまざまなツールでプラットフォームを強化しています。
Heroku Flow は、構造化されたデプロイワークフローです。GitHub、視覚的に表現されるパイプライン、使い捨ての「レビューアプリケーション」、Heroku CI が緊密に統合され、視覚的かつ効率的で簡単な継続的デリバリを実現することにより、アプリケーションのリリースを無駄なく、合理化できるように設計されています。
Heroku Pipelines
同じコードベースを共有する Heroku アプリケーションを 1 つにまとめたデプロイパイプラインです。ビジュアルインターフェースを使い、次のステージへの昇格や管理を簡単に行えます。Heroku Pipelines 関連資料→
Heroku CI
Heroku CI は、Heroku Pipeline に統合された、セットアップの少ない、視覚的なテスト実行ツールです。GitHub へのプッシュのたびに、開発環境と本番環境の一致を保ちながら、使い捨てのアプリケーションを使ってテストが自動的に実行されます。Heroku CI 関連資料→
Heroku Review Apps
開発中、テスト用に一時的なアプリケーションを開発者が作成し、チームはこれを利用して、コードベースに変更をマージするかどうかをレビュー、検討、決定することができます。Heroku Review Apps 関連資料→
GitHub Integration
Heroku アプリケーションとその GitHub リポジトリを緊密に連携させると、GitHub と Heroku の両方に通知した上で、マージ後のブランチを自動でも、手作業でもデプロイできるようになります。GitHub Integration 関連資料→
Heroku ChatOps
Heroku ChatOps は、Heroku Pipeline と Slack を接続することによりチームの円滑なコラボレーションを促進します。Heroku ChatOps を使用すると、Slack からステージング環境にデプロイしたり、本番環境へ昇格させたりすることが可能になります。また、Slack チャネルで、プルリクエスト、マージ、CI のビルド結果を確認できるようになります。Heroku ChatOps 関連資料→
Release Phase
リリースフェーズでは、リリースを本番環境にデプロイする前に、データベース移行などのタスクを自動的に実行できます。これにより、手作業によるデプロイステップを省略し、それに伴うリスクを排除できます。Release Phase 関連資料→
継続的デリバリーのしくみ
継続的デリバリーという考え方の中心にあるのは、ブランチとマージを軸とした基本的なワークフローです。複数の開発者が、それぞれ独自のコードブランチで作業し、変更を共有して、同僚のレビュー、フィードバック、承認を受けて、更新したコードをメインブランチへシームレスにマージします。このプロセスはきわめて単純かつ効率的なので、チームのスピードについていくのも簡単です。
継続的デリバリーのメリット
継続的デリバリーとは、大太鼓を 1 回ドンと叩くのではなく、小太鼓を絶え間なく叩き続けるようにアプリケーションをリリースし続けるという考え方です。これにより、従来のリリースプロセスを途切れさせることなく、エンジニアリング組織、エンドユーザー、事業のステークホルダーに、絶え間なく利益がもたらされます。
継続的デリバリーの基盤
成功につながる継続的デリバリーの習慣は、チームが最高の結果を生み出せるように支援する 3 つのコアコンポーネントの上に成り立っています。
設定管理
継続的デリバリーを実践するには、開発チームがプロセスを確立し、アプリケーションのパフォーマンス、機能、ユーザーエクスペリエンスの整合性を保証する共通のツールセットに同意することが不可欠です。設定管理を行うと、ソースコードやデータベース、文書化、テストスクリプトやデプロイスクリプト、アプリケーションの設定情報など、CD プロセスのあらゆる部分のバージョンを管理できるようになります。開発者は、必要に応じて環境を再現し、その環境を再構築するために使用した依存関係ファイルをすべて追跡できます。情報源を 1 つだけに絞る、それも信頼できるものにすることで、円滑なデプロイパイプラインを構築するための確固たる基盤がもたらされます。
継続的インテグレーション
複雑なアプリケーションでは、シンプルで自己完結しているように見える変更が、実は、想定外の影響をもたらすことがあります。複数の開発者が相互に隔離された環境で複数のコードブランチに対して並行して作業を行うことは珍しくありません。このような場合、共通のメインブランチに変更をマージすると、予期しない結果が生じて、何回も回帰テストやバグ修正をする必要が生じることもあります。継続的インテグレーション（CI）は、開発者が作成した更新プログラムを、定期的にメインブランチに統合するために必要となる、継続的デリバリープロセスに欠かせないコンポーネントの 1 つです。CI では、統合の前と後に自動テストが実施され、バグが入り混んでいないことが検証されます。
テストの自動化
従来、テストはコードの「開発完了」後に手動で行われていました。これは、アプリケーションやシステムが、変更により壊されないようにするためです。しかし、手動による回帰テストは時間とコストがかかり、人為的なミスを引き起こしやすいものです。さらに、QA チームはかなりの時間と手間をかけて、テストマニュアルを最新の情報に保たなければなりません。継続的デリバリーでは、多種多様なテストがプロセス全体を通じて行われます。単体テストのように自動化されているものもあれば、ユーザビリティテストや受入テストのように現在でも手作業で行われるテストもあります。目標は、すべてのテストをデリバリーライフサイクルの最初から CD プロセスに組み入れ、定型的作業はできるだけ自動化することです。これにより、開発者はアプリケーションのコーディングと改善に集中できるようになります。
継続的デリバリーの成功要因
継続的デリバリーを組織の習慣として確立するには、アプリケーション開発の関係者全員が、円滑なプロセスに貢献する習慣やマインドセットを共有する必要があります。プロダクトマネージャーからデザイナー、開発者に至るまで、チームメンバー全員に本稼働までのあらゆる段階で、自分の役目を成功させる責任があります。ここでは、開始直後から、チームを正しい方向に向かわせるための CD のベストプラクティスをいくつかご紹介します。