CodeGym /コース /JAVA 25 SELF /サーバーへのコードのデプロイ

サーバーへのコードのデプロイ

JAVA 25 SELF
レベル 10, レッスン 6
使用可能

1. コードに変更を加える

以前にも述べたように、ソフトウェア開発とはコードに小さな変更を積み重ねていくことに尽きます。このプロセスは何千万人ものプログラマーが数十年にわたり取り組んできた結果、あらゆる方法で丹念に洗練され、標準化・形式化されてきました。

コードを保存するための専用のツールが Git です。Git は分散型バージョン管理システムです。単にコードを保存するだけでなく、そのすべての変更を追跡し、開発者同士が互いに干渉せずに共同作業できるよう支援します 🤝。

Git を使えば、開発者はプロジェクトのさまざまなバージョン(ブランチ)を作成し、変更履歴を完全に保持し、過去の任意の時点に戻ることさえできます。まるでコード用のタイムマシンのようなものです!Git は変更の統合やコンフリクトの解決を助けるため、現代の開発におけるチーム作業の主要ツールとなっています。👩‍💻

2. プロジェクトをビルドする

プロジェクトをテストしたりサーバーへアップロードしたりする前に、まずビルドする必要があります。

🏗️ プロジェクトのビルド とは、プロジェクトのソースコードを実行可能なプログラムやその他の実行可能形式にコンパイルするプロセスであり、しばしばテストやデプロイも含みます。これはソフトウェア開発の重要な側面であり、アプリケーションを利用可能な状態にするものです。

ビルドは単なるコンパイルではありません(もっとも、コンパイルはしばしばビルドの一部です)。ビルドが完了すると、数十、場合によっては数百ものファイルが生成され、それらをさまざまなサーバーへ配置(アップロード)する必要が出てくることがあります。

ビルドツールには、次のような低レベルのものがあります。

  • ☕ Maven と Gradle — Java プロジェクトで依存関係管理とビルドに広く使われます.
  • 🐜 Apache Ant — もう一つの Java 向けビルドツールで、ビルドスクリプトの記述に大きな柔軟性を提供します。
  • 🖥️ MSBuild — Microsoft Visual Studio で作成されたプロジェクトのビルドに使用されます。
  • ⚙️ Make — Makefile でビルドルールを定義する古典的なビルドツールで、特に C および C++ のプロジェクトで人気です。
  • 🌐 Webpack — JavaScript アプリケーションのビルドに用いられ、依存関係やモジュールを管理します。
  • 📜 Gulp と Grunt — Web アプリ開発で頻繁に行う作業(ファイルのミニファイや SCSS を CSS にコンパイルするなど)を自動化します。

また、高レベルのビルドツールもあります。これについては後述します。

3. CI/CD

🔄 CI/CD (Continuous Integration/Continuous Delivery) は、すべての開発ブランチからの変更を継続的にメインブランチへ統合し、さらにそれらの変更を自動でテスト・デプロイするという方法論です。これにより不具合を素早く検出・修正でき、開発の効率と速度が向上します。

最も一般的で、やや古さはあるものの広く使われている CI/CD システムの一つが Jenkins です。小規模な会社で働いているなら、80%の確率でそれが使われているでしょう.

🤖 Jenkins は継続的インテグレーション/継続的デリバリー(CI/CD)のために用いられる人気の自動化システムです。Jenkins はソフトウェア開発のさまざまな段階(ビルド、テスト、デプロイなど)を自動化し、コード品質の向上と開発プロセスの高速化に寄与します。

大企業に入ると、次のような別の選択肢がさらに 5 つあるかもしれません:

  • 🚦 TeamCity — JetBrains 製の強力な商用システム。さまざまな開発・テスト環境と深く統合できます。
  • 📝 GitLab CI — GitLab に組み込まれており、YAML ファイルによる設定で継続的インテグレーションとデリバリーを提供します。
  • ☁️ CircleCI — クラウド型の CI/CD サービスで、多くのプロジェクトのテストとデプロイを自動化できます。
  • 🦑 Travis CI — クラウド CI の草分け的存在の一つで、多数のオープンソース・プロジェクトで利用されています。GitHub と相性が良好です。
  • 🎍 Bamboo — Atlassian の製品で、Jira や Bitbucket など同社の他ツールと密接に統合されています。

これらをすべて知り尽くして使える必要はありません。通常、企業にはこれらのプロセスを設定する DevOps エンジニアがいます。会話の中で Jenkins、CI/CD、あるいは「continuous integration」(コンティニュアス・インテグレーション)といった用語が出てきたときに、何の話か分かる程度に存在を知っておけば十分です。

4. プロジェクトをサーバーにデプロイする

プロジェクトを書くだけでは不十分で、それを自分たちのサーバー上で動かせるようにしなければなりません。一般に、サーバーへのプロジェクトのデプロイ(deploy)とは、ウェブアプリケーションをサーバーに配置して有効化し、インターネット経由でユーザーが利用できるようにするプロセスのことです 🚚。

このプロセスには、プロジェクトのファイルをサーバーへ転送すること、サーバー環境・データベース・依存関係の設定、さらにネットワークやセキュリティの構成が含まれます 😅。

では、どうやってあなたのコードはサーバーに届くのでしょうか。誰かが手でアップロードするのでしょうか。それとも、あなたが SSH でリモートサーバーに接続し、いくつかのファイルを上げて一つ一つ設定していくのでしょうか。安心してください。いまはもう誰もそんなやり方はしません。いまは Docker があります。

🐳 Docker は、コンテナを用いてアプリケーションを開発・配布・実行するためのプラットフォームです。Docker はアプリケーションを、その依存関係や実行環境とともに一つのコンパクトな単位にパッケージ化し、作成・デプロイ・実行を簡素化します。これにより、開発からテスト、本番まで各段階で環境の一貫性が保たれます。

Docker を使えば、あなたのプロジェクト(群)を Docker コンテナにパッケージ化できます。これは仮想マシンのようなものです।

もちろん、Docker のフォーラムなどでそれを「仮想マシン」と呼ぶと突っ込まれるでしょうが、概念的には Docker コンテナを仮想マシンだと考えて構いません。ただしはるかに軽量です。

本質的には、Docker コンテナは「仮想マシン的な存在」と言えます。仮想マシンはオペレーティングシステムの完全なコピーや OS カーネル、仮想ハードウェアを含みますが、Docker コンテナはホストのカーネルを共有するため、より軽量かつ高速に動作します ⚡。

Docker を使ったプロジェクトのデプロイはプロセスを大幅に単純化し、高速かつ信頼性の高い運用を可能にします。プロジェクトは Docker コンテナにパッケージ化され、Docker をサポートする任意のシステム上で容易に移動・実行できます 🚢。

これにより、サーバー環境の違いに起因する問題から解放され、負荷に応じてコンテナを追加・削除するだけで容易にアプリケーションをスケールできます。多くの現場が Docker に移行しており、とても便利で、とても簡単です。

コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION