12.1 コードに変更を加える
さっきも言ったけど、現代の開発って基本的にコードに小さい変更を加えることなんだよね。数百万ものプログラマーが何十年もかけてこれをやってきたから、このプロセスはすっかり整って標準化されてるんだ。
まず、コードを管理するために特別なプログラムがあるんだけど、それがGitってやつ。Gitは分散型バージョン管理システムで、コードの変更履歴を追跡したり、プログラマーたちが共同でプロジェクトに取り組むのを助けてくれる。
Gitは開発者がプロジェクト内でブランチを作成できるようにしてくれて、しかも変更履歴が全部残るし、ファイルのどんな状態にも戻すことができる。このおかげで、変更のマージやコンフリクトの解決が効率的にできるから、Gitは現代のソフトウェア開発においてコラボレーションに欠かせないツールになってるんだ。
それから、コードに変更を加えるプロセスも標準化されてるんだ。普通は新しい機能ごとにGitで新しいブランチを作って、そこに変更をシリーズのコミットとして加えていって、チームリーダーかチームメイトにPull Requestを送って、Code Reviewをしてもらって、その変更を承認してもらう感じなんだよね。
すべてがうまくいけば、変更はdevブランチに統合されて、自動ビルドとテストが走るって流れ。テスト、たくさんやるんだ。
12.2 プロジェクトをビルドする
プロジェクトをテストしたりサーバーにアップロードする前に、プロジェクトをビルドしないとね。
プロジェクトのビルドってのは、プロジェクトのソースコードを実行可能なプログラムや他の起動可能な形式にコンパイルするプロセスで、テストやデプロイも含まれることがよくあるんだ。これはソフトウェア開発の重要な側面で、プログラムの使用準備を保証するんだよ。
ビルドっていうのはコンパイルとは違うけど、コンパイルがビルドプロセスの一部であることが多い。ビルドが終わると、たくさんのファイルをいろんなサーバーにアップロードしなきゃならないことがあるんだよね。
ビルドツールには低レベルのものがあるよ：
Maven と Gradle — これらはJavaのプロジェクトで依存関係とプロジェクトのビルドを管理するために広く使われてる。
Apache Ant — これもJavaのプロジェクト用のビルドツールで、ビルドスクリプトを書くのに柔軟性があるんだ。
MSBuild — これはMicrosoft Visual Studioを使って作成されたプロジェクトをビルドするために使われるんだ。
Make — 古典的なビルドツールで、Makefileを使ってビルドルールを定義するんだけど、特にCやC++のプロジェクトで人気なんだ。
Webpack — JavaScriptアプリケーションをビルドするのによく使われてて、依存関係やモジュールを管理してくれるんだ。
Gulp と Grunt — これらはウェブアプリの開発でよく行うタスク（例えばファイルの縮小とかSCSSをCSSにコンパイルするとか）を自動化するのを助けるツールだよ。
ビルドツールには高レベルのものもあるけど、それは下で話すね。
12.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、「継続的インテグレーション」と話に出たときに、それがどういうものか知っておくにはいいんだけどね。
12.4 プロジェクトをサーバーに届ける
プロジェクトを書くだけではなく、それがサーバーに配置されなければならないんだ。実際、プロジェクトをサーバーにデプロイするというのは、ウェブアプリケーションをサーバーに配置してアクティブにするプロセスで、ユーザーがインターネットを通じてアクセスできるようにすることなんだ。
このプロセスには、プロジェクトのファイルをサーバーに転送したり、サーバー環境、データベース、依存関係の設定、それにネットワーク設定とセキュリティの構成が含まれるんだ。
どうやってコードがサーバーに落とされると思う？誰かがそこにアップロードすると思う？それとも、SSHでサーバーに接続して、いくつかのファイルをアップロードして、すべてを設定すると思う？安心して：今では誰もそんな風にはやらないよ。今はDockerがあるからね。
Docker — これはコンテナ化を利用してアプリケーションを開発、配信、実行するためのプラットフォームなんだ。Dockerは、アプリケーションをその環境や依存関係と一緒に1つのコンパクトなオブジェクトにパッケージ化することを簡単にするから、開発、テスト、本番のすべての段階で環境の一貫性を保証できるんだよ。
DockerはプロジェクトをDockerコンテナにパッケージ化できるんだ。これは仮想マシンみたいなもんだけど、とっても軽量なんだよ。
そして、もしDockerのフォーラムでこれを仮想マシンだって言ったら、きっと激しく非難されるけど、仮想マシンが何か分かってるなら、Dockerコンテナを仮想マシンみたいに考えてもいいんだ。本当に軽量なんだけどね。
基本的に、Dockerコンテナも仮想「仮想マシン」なんだ。仮想マシンはオペレーティングシステムの完全なコピーとかOSのカーネル、仮想ハードウェアを含んでるけど、Dockerコンテナはホストのカーネルを共有して、もっと軽くて速くなることがあるんだよ。
で、Dockerを使ったプロジェクトのデプロイは、アプリケーションの展開プロセスを大いに簡素化して、速さと信頼性を提供してくれる。プロジェクトはDockerコンテナにパッケージ化されて、それがDockerをサポートする任意のシステムで簡単に移動して実行できるんだ。
これでサーバー環境の違いに起因するトラブルから解放されて、アプリケーションを簡単にスケールアップしたり、あるいはスケールダウンしたりできる。みんなDockerに移行してるんだ—これがすごく便利で簡単なんだよね。
GO TO FULL VERSION