Continuous integration icon

早めのテスト、手軽なコラボレーション、こまめなデプロ イ

現在、最も魅力的で最先端を行くアプリケーションは、最新の開発手法に従って 構築され、デプロイされています。このような手法には、開発者の生産性や効率性、開発速度を向上させるだけでなく、アプリケーションの品質を高めるように最適化されたプロセスやワークフローが組み込まれています。現在、アジャイル開発手法と分散バージョンコントロールシステムの採用は広がりを見せていますが、これらを補うために、チームのアプリケーションリリースプロセスを効率化する新しい手法として、継続的デリバリー(CD)が登場しました。

継続的デリバリーの特徴としては、短いリリースサイクル、自動化、ソースコー ドリポジトリへの直接接続などが挙げられます。また、チームが本番環境のアプリケーションを、すばやく、安全に増分アップデートできるように設計されています。CD プロセ スが成功すると、組織のテクノロジー、関係者、文化の足並みが揃い、デプロイが効率化され、アクティビティが自動化されます。また、企業やエンドユーザーには、新しい機能の配信が早まり、アプリケーションの品質が上がるというメリットがあります。

Heroku Flow

Heroku プラットフォームは、アプリケーションの最初のビルドから、運用、さらにその先まで、開発者の生産性を最大化し、すばらしい経験を提供することを目的に設計されています。この一環として、Heroku は、継続的デリバリなど、最新の開発習慣をサポートするさまざまなツールでプラットフォームを強化しています。

Heroku Flow は、構造化されたデプロイワークフローです。GitHub、視覚的に表現されるパイプライン、使い捨ての「レビューアプリケーション」、Heroku CI が緊密に統合され、視覚的かつ効率的で簡単な継続的デリバリを実現することにより、アプリケーションのリリースを無駄なく、合理化できるように設計されています。

Heroku Pipelines

Heroku Pipeline ドキュメントを読む

同じコードベースを共有する Heroku アプリケーションを 1 つにまとめたデプロイパイプラインです。ビジュアルインターフェースを使い、次のステージへの昇格や管理を簡単に行えます。

Heroku CIg

Heroku CI

Heroku CI Read docs

Heroku CI は、Heroku Pipeline に統合された、セットアップの少ない、視覚的なテスト実行ツールです。GitHub へのプッシュのたびに、開発環境と本番環境の一致を保ちながら、使い捨てのアプリケーションを使ってテストが自動的に実行されます。

Heroku Review Appsg

Review Apps

開発中、テスト用に一時的なアプリケーションを開発者が作成し、チームはこれを利用して、コードベースに変更をマージするかどうかをレビュー、検討、決定することができます。

Heroku GitHub Integrationg

GitHub Integration

Heroku アプリケーションとその GitHub リポジトリを緊密に連携させると、GitHub と Heroku の両方に通知した上で、マージ後のブランチを自動でも、手作業でもデプロイできるようになります。

Heroku ChatOps
g

Heroku ChatOps

Heroku ChatOps は、Heroku Pipeline と Slack を接続することによりチームの円滑なコラボレーションを促進します。Heroku ChatOps を使用すると、Slack からステージング環境にデプロイしたり、本番環境へ昇格させたりすることが可能になります。また、Slack チャネルで、プルリクエスト、マージ、CI のビルド結果を確認できるようになります。

Heroku Release Phaseg

Release Phase

リリースフェーズでは、リリースを本番環境にデプロイする前に、データベース移行などのタスクを自動的に実行できます。これにより、手作業によるデプロイステップを省略し、それに伴うリスクを排除できます。

継続的デリバリーのしくみ

継続的デリバリーという考え方の中心にあるのは、ブランチとマージを軸とした基本的なワークフローです。複数の開発者が、それぞれ独自のコードブランチで作業し、変更を共有して、同僚のレビュー、フィードバック、承認を受けて、更新したコードをマスターブランチへシームレスにマージします。このプロセスはきわめて単純かつ効率的なので、チームのスピードについていくのも簡単です。

継続的デリバリーのメリット

継続的デリバリーとは、大太鼓を 1 回ドンと叩くのではなく、小太鼓を絶え間なく叩き続けるようにアプリケーションをリリースし続けるという考え方です。これにより、従来のリリースプロセスを途切れさせることなく、エンジニアリング組織、エンドユーザー、事業のステークホルダーに、絶え間なく利益がもたらされます。

アプリケーションの品質向上

プロセスの繰り返しにかかる時間が短くなるということは、開発者が品質の高いコードの記述により多くの時間をかけ、集中できるようになるということを意味します。これは、バグやトラブルの本質的な削減につながります。規則正しいペースでリリースすれば、製品チームは、リリースとリリースの間に、ユーザーのフィードバックを取り込むことができ、アプリケーションの機能セットやユーザーエクスペリエンスに磨きをかけ、顧客満足度を向上させることができます。

市場投入までの期間の短縮

継続的デリバリーにより、企業はアプリケーションの新しい機能や更新プログラムを迅速にカスタマーのもとへ配信し、競争力を保ち続けることができます。また、エンジニアリングチームは、ビジネスニーズや市場トレンドの変化を敏感に捉え、未実装の機能に上手く対応して、必要なときにすぐアプリケーションの修正プログラムをリリースする能力が高まります。

チームの生産性向上

プロセスや環境を自動化することで、従来、手作業のテストにかかっていた時間や費用が削減されます。これにより、アプリケーション開発者は、一番得意とするもの、つまり開発に集中できるようになります。また、チームの作業ペースが加速し、会社にもたらされる価値が増え、より効率的に協力して問題を解決できるようになります。さらに、設計から、製造、マーケティングに至るまで、プロジェクトのあらゆるメンバーが、すばやく変化を確認し、プロセスの各ステップで、意思決定に参加できるようになります。

リリースのリスクを低減

リリースの頻度を高めることで、開発プロセスの早い時期に問題を発見し、解決できるようになります。つまり、コードの欠陥が本番環境まで残る可能性が低くなります。コードベースはきれいなまま、いつでもリリース可能な状態に保たれます。また、継続的デリバリーでは、デプロイプロセスやスクリプトのテストも、早い時期から、本稼働が始まる前に繰り返し行われます。

継続的デリバリーの基盤

成功につながる継続的デリバリーの習慣は、チームが最高の結果を生み出せるように支援する 3 つのコアコンポーネントの上に成り立っています。

設定管理

継続的デリバリーを実践するには、開発チームがプロセスを確立し、アプリケーションのパフォーマンス、機能、ユーザーエクスペリエンスの整合性を保証する共通のツールセットに同意することが不可欠です。設定管理を行うと、ソースコードやデータベース、文書化、テストスクリプトやデプロイスクリプト、アプリケーションの設定情報など、CD プロセスのあらゆる部分のバージョンを管理できるようになります。開発者は、必要に応じて環境を再現し、その環境を再構築するために使用した依存関係ファイルをすべて追跡できます。情報源を 1 つだけに絞る、それも信頼できるものにすることで、円滑なデプロイパイプラインを構築するための確固たる基盤がもたらされます。

複数環境の管理の詳細はこちら >>

継続的インテグレーション

複雑なアプリケーションでは、シンプルで自己完結しているように見える変更が、実は、想定外の影響をもたらすことがあります。複数の開発者が相互に隔離された環境で複数のコードブランチに対して並行して作業を行うことは珍しくありません。このような場合、共通のマスターブランチに変更をマージすると、予期しない結果が生じて、何回も回帰テストやバグ修正をする必要が生じることもあります。継続的インテグレーション(CI)は、開発者が作成した更新プログラムを、定期的にマスターブランチに統合するために必要となる、継続的デリバリープロセスに欠かせないコンポーネントの 1 つです。CI では、統合の前と後に自動テストが実施され、バグが入り混んでいないことが検証されます。

CI 用の Heroku アドオンを見る >>

テストの自動化

従来、テストはコードの「開発完了」後に手動で行われていました。これは、アプリケーションやシステムが、変更により壊されないようにするためです。しかし、手動による回帰テストは時間とコストがかかり、人為的なミスを引き起こしやすいものです。さらに、QA チームはかなりの時間と手間をかけて、テストマニュアルを最新の情報に保たなければなりません。継続的デリバリーでは、多種多様なテストがプロセス全体を通じて行われます。単体テストのように自動化されているものもあれば、ユーザビリティテストや受入テストのように現在でも手作業で行われるテストもあります。目標は、すべてのテストをデリバリーライフサイクルの最初から CD プロセスに組み入れ、定型的作業はできるだけ自動化することです。これにより、開発者はアプリケーションのコーディングと改善に集中できるようになります。

テスト用の Heroku アドオンを見る >>

継続的デリバリーの成功要因

継続的デリバリーを組織の習慣として確立するには、アプリケーション開発の関係者全員が、円滑なプロセスに貢献する習慣やマインドセットを共有する必要があります。プロダクトマネージャーからデザイナー、開発者に至るまで、チームメンバー全員に本稼働までのあらゆる段階で、自分の役目を成功させる責任があります。ここでは、開始直後から、チームを正しい方向に向かわせるための CD のベストプラクティスをいくつかご紹介します。

品質に重点を置く

単体テストの範囲から、lint の実行、同僚によるコードのレビュー、コードのスタイリング、ルール違反や複雑さの測定に至るまで、品質の定義に時間とリソースを十分に費やすことが大切です。問題やバグを発生と同時にすばやく解決できるように、フィードバックループはできるだけ短くしましょう。これにより、開発されるコードの品質がプロセス全体で高まり、解決が難しく、コストがかかるようになってから見つかる問題が少なくなります。

常に本稼働可能な状態を保つ

機能は、本番環境に到達して初めて「完成」します。つまり、プロジェクトがユーザーの手に渡り、適切に動作するようになるまでは、プロジェクトチームがプロジェクトの所有者であり続けます。バージョン管理システムにコードをチェックインしたら終わりではありません。製品のリリース準備ができていなくても、コードをリリース可能な、本稼働できる状態に保ちましょう。

可能な限り自動化する

ソフトウェアのリリースプロセスが、繰り返し可能で、信頼できるものになるように、繰り返し可能なテストやタスクの自動化に投資することが大切です。どんなに注意深く準備され、実施されたとしても、手作業によるプロセスを信頼できるということはまずあり得ません。複数の環境で 1 日に複数回さまざまなタイプのテストを実行した上で行われるビルド(またはビルドのセット)は、手作業では何時間もかかるか、CI プロセスで自動化しなければ実施不可能なワークフローです。

絶え間ないフィードバックで改善する

絶え間なくフィードバックを入手し、技術的な指標、ユーザーエクスペリエンス、アプリケーションのライフサイクルを構成する主要なすべての段階を監視し続けましょう。これにより、プロセスの早い段階で、時間やエネルギー、費用を掛けずに、さまざまな改善を行うことが可能になります。スマートモニタリングや定評のある連続改善プロセスを採用することにより、リスクを抑え、品質の良いリリースを短いサイクルで実現できるようになります。

  • 当社では Heroku Pipeline をリリースと同時に使い始め、今ではあらゆるマイクロサービスの継続的デリバリーに活用しています。

    ZeroCater Rob Adams ZeroCater 社エンジニアリングマネージャー お客様事例を読む >>
  • Heroku Pipelines によって私たちの小さいチームの生産性は向上しました。それぞれのプルリクエスに Review App が生成されるので、同一のアプリについて、全ての開発者はそれぞれのテスト環境で、お互いの干渉がずっと少ない状態で、取り組むことができます。

    The Information Jane Philipps The Information 社エンジニア