アイデアを手元のラップトップから実際に使えるアプリケーションへ
すべてのアプリケーションは、誰かの頭の中にあるアイデアから始まります。気づいた問題を解決したいのか、チームから何か新しいものを作ってほしいと頼まれたのか。理由はどうあれ、ある時点でラップトップを開き、コードを書き始めます。
ラップトップ上では、すべてが簡単に感じられます。アプリケーションを実行し、インターフェースを確認し、いくつかの機能を試してみると、すべてがうまく動きます。何かが壊れたら、修正してもう一度実行します。それを見ているのは自分だけです。アプリがクラッシュしたりエラーを吐いたりしても、他の誰も影響を受けません。
しかし、アプリケーションを構築するというアイデアは、めったにラップトップだけで完結しません。他の人——友人、クライアント、オフィスの同僚、あるいは一般の人々——が使えるように作ったのです。誰か他の人がアクセスする必要が生じた瞬間、ごく基本的な疑問が浮かびます：このアプリケーションは、他の人が到達できるようにどこで実行すればいいのか？
ラップトップは適切な場所ではありません。ラップトップはシャットダウンしたり、バッテリーが切れたり、自宅に持ち帰られたり、外部からのアクセスをブロックするネットワークに接続されたりします。アプリケーションが自分のマシンでしか動かない場合、他の人が使えるのは、自分がその前に座っていて、ネットワークが外部アクセスを許可しているときだけです。それは実用的でも信頼性が高いものでもありません。
最初の本当のニーズ：実行する場所
アプリケーションは、常に稼働し、ネットワークに接続され続け、許可した誰もが到達できる場所に存在する必要があります。その場所をサーバーと呼びます。サーバーは、自分で管理する物理的なコンピュータでも、クラウドプロバイダからレンタルする仮想マシンでも構いません。重要なのは、サーバーがアプリケーションを実行し、ユーザーからのリクエストに応えることを主な仕事とするコンピュータであることです。
アプリケーションをサーバーに配置して他の人がアクセスできるようにするプロセスは、ソフトウェアデリバリーにおいて最初に現れる本当のニーズです。このニーズはしばしばホスティングと呼ばれます。アプリケーションをどこでホストするか、コードをそのサーバーにどう送るか、そしてアプリケーションがそこに到着したら実際に実行されるようにする方法を決める必要があります。
実際のユーザーが依存するアプリケーションを実行するサーバーは、本番環境と呼ばれます。「本番」という言葉は、これがテスト領域ではないことを示しています。ここはアプリケーションが正しく動作しなければならない場所であり、実際のユーザーがそれに依存しています。本番環境でアプリケーションがエラーを起こせば、ユーザーはその機能を使えません。完全にダウンすれば、ユーザーはサービスにまったくアクセスできなくなります。
ラップトップと本番環境の違い
ラップトップと本番環境の間にあるギャップは基本的なものです。ラップトップでは、完全に制御でき、アプリケーションが壊れても大きな結果は生じません。本番環境では、アプリケーションは稼働し続け、アクセス可能で、安定していなければなりません。障害の結果はユーザーが直接感じることになります。
ここで、多くの開発者が初めて重要なことに気づきます：自分のラップトップでアプリケーションを動かすことは個人的な問題です。他の人が使えるようにすることは、まったく別の課題です。実行する場所、そこに送る方法、そして到着後に正しく動作するという確信が必要です。
実際にどうやってアプリケーションをサーバーに送るのか？
サーバーを用意したら、次に自然な疑問は：どうやってアプリケーションをそこに送るのか？ファイルをコピーするだけで十分なのか？それとももっと何かあるのか？
答えは、どのような種類のアプリケーションを構築したかによります。単純な静的ウェブサイトであれば、HTMLファイルをコピーするだけでうまくいくかもしれません。しかし、ほとんどのアプリケーションはもっと複雑です。依存関係のインストール、設定ファイルのセットアップ、データベースの接続、環境変数の定義が必要です。コードをコピーするだけでは不十分なことがほとんどです。
ここでデプロイメントの概念が登場します。デプロイメントとは、アプリケーションをそのソース（通常はコードリポジトリ）から取得し、ターゲット環境で実行可能にするプロセスです。適切なファイルのコピー、依存関係のインストール、セットアップ手順の実行、そしてアプリケーションプロセスを起動してリクエストを受け付け始めることが含まれます。
単純なデプロイメントは次のようになります：
- リポジトリから最新のコードをサーバーにプルする。
- 新しい依存関係をインストールする。
- スキーマが変更された場合、データベースマイグレーションを実行する。
- アプリケーションプロセスを再起動する。
この単純な手順でさえ、うまくいかないことがあります。サーバーがラップトップと異なるオペレーティングシステムを実行していたら？依存関係のバージョンが既にインストールされているものと競合したら？データベースマイグレーションが予想より長くかかり、ユーザーがエラーを見ることになったら？
利用可能にすることと、動作させること
もう一つ、早い段階で区別しておく価値のあることがあります：アプリケーションをサーバーに置くことと、ユーザーが利用できるようにすることは同じではありません。
すべてのファイルをサーバーにコピーし、プロセスを起動しても、誰も到達できないアプリケーションになる可能性があります。サーバーのファイアウォールがポートをブロックしているかもしれません。ドメイン名が正しいIPアドレスを指していないかもしれません。アプリケーションがネットワークインターフェースではなくlocalhostにバインドしているかもしれません。SSL証明書が期限切れで、ブラウザが接続を拒否するかもしれません。
アプリケーションを真に使えるようにするには、デプロイメント以上のことが必要です。ネットワークが正しく設定されていること、DNSレコードが正しい場所を指していること、アプリケーションが正しいアドレスとポートでリッスンしていること、そしてサーバー再起動後もサービスが稼働し続けることを保証する必要があります。
これが、本番環境が決してコードだけの問題ではない理由です。ネットワーキング、システム管理、監視、そして多くの場合、インフラストラクチャを健全に保つ責任を持つ別のチームや担当者が関わります。
次に来ること
アプリケーションが本番環境で稼働し、ユーザーがアクセスできるようになっても、旅は終わりません。ユーザーはバグを見つけるでしょう。新しい機能を要求するでしょう。誰かがセキュリティの脆弱性を発見するでしょう。ビジネスは支払いフローを追加したり、ユーザーインターフェースを変更したりしたいと思うでしょう。
これらの変更のたびに、本番環境のアプリケーションを更新する必要があります。そして、すべての更新にはリスクが伴います。新しい機能が他の何かを壊すかもしれません。データベースマイグレーションがデータを破損するかもしれません。設定変更がアプリケーションを遅くするかもしれません。
ここで、信頼性が高く再現可能なプロセスの必要性が明らかになります。変更のたびに手動でファイルをコピーして、すべてがうまくいくことを願うわけにはいきません。アプリケーションを一貫してビルド、テスト、デプロイするシステムが必要です。
そのシステムこそ、この記事シリーズの残りの部分で探求するものです。しかし、そこに進む前に、現在のセットアップが基本をカバーしているかどうかを確認する価値があります。
簡単な実践的チェック
現在、他の人が使うアプリケーションを実行しているなら、自分自身にこれらの質問をしてみてください：
- どのサーバーがアプリケーションを実行しているか正確に把握していますか？
- 新しいバージョンを30分以内に自信を持ってデプロイできますか？
- サーバーがクラッシュした場合、アプリケーションとそのデータを復元できますか？
- サーバーを再起動したときに何が起こるか分かっていますか？
- 何か問題が発生した場合、以前のバージョンにロールバックできますか？
これらのいずれかに「いいえ」と答えた場合、あなたは一人ではありません。ほとんどのチームは手動プロセスから始め、時間をかけて改善していきます。重要なのは、これらのギャップを認識し、一つずつ埋めていくことです。
まとめ
人々が実際に使えるアプリケーションを作ることは、一つの単純な真実から始まります：あなたのラップトップは本番環境ではないということです。ローカルでコードを実行することと、実際のユーザーのために実行することの間にあるギャップに、ソフトウェアデリバリーの複雑さのほとんどが存在します。パイプライン、自動化、高度なデプロイ戦略を心配する前に、アプリケーションがどこで実行され、どのようにそこに到達し、稼働し続けるために何が必要かを理解してください。他のすべては、その基盤の上に構築されます。