DevOps のビルド自動化とは？
自動ビルドは、継続的インテグレーション（CI）自動化の中枢にあり、CI/CD パイプラインを実現する鍵でもあります。 これらは、最新の変更によって生じたコード内の課題をできるだけ早期に警告するために設計された一連の自動ステップの先頭にあります。
このコンテキストで「ビルド」といった場合、ソースコードをコンパイルしてリンクすることで実行可能ファイルを作成するという動作だけを指しているわけではありません。
自動ビルドプロセスでは一連のチェックが行われるだけでなく、プログラムの実行に必要なすべてのピースが組み合わせられます。インタープリター型言語を扱っている場合でも、ビルドステップは欠かせません。
ビルドステージで出力される「ビルドアーティファクト」と呼ばれるファイルは、CI/CD パイプラインと前進しながら、テストステージ、そしてステージングステージへと進みます。 ビルドがパイプラインのすべてのステップに合格すれば、公開へとリリースされる準備が整ったことになります。
ビルドとデプロイプロセスを自動化する理由とは？
ビルド自動化の内容を確認する前に、自動ビルド管理プロセスがなぜ重要なのかを考えてみましょう。
IDE で作業している場合、通常はキーボードショートカットを使ってビルドをトリガーできます。ではこのプロセスを自動化するのは何故ででょうか。
手始めに、作業内容をサニティチェックするか上司に簡単に実演して見せる場合にはローカルで構築する方が便利ではありますが、CI/CD にローカルビルド使用するのは好ましい実践ではありません。
専用のビルドサーバーを使用することで、クリーンな環境を確保できるため、出力がテスト環境にデプロイされた時に問題や遅延の原因となるような依存関係の欠落に早期にフラフを立てることができます。
パイプラインのほかのステージを開始する自動ビルドがなければ、CI/CD の信頼性は大幅に低下してしまいます。 ビルドサーバーにログインしてテストを含む各ビルドを開始し、何らかの失敗に備えてプロセスを常に監視し、成果物をテスト用にデプロイする目的でアーティファクトのリポジトリに移動する必要がある場合、この手順の中で問題が発生する可能性は高いと思われます。
テストする変更があと少し追加されるまでビルドの開始を延期するのは簡単ですが、そうしてしまうと、CI/CD のメリットが損なわれてしまいます。
最後に、CI/CD パイプラインの背後にある戦略は、早めに失敗させることです。
問題を早く発見できるほど修正が楽になり、ビルド自動化プロセスの効率性も増します。 ビルド段階の自動化は、ビルドに関わるさまざまなステップを手動でトリガーするよりも素早く行え、ファイルを手作業で実行中のテストに移動するよりも大幅に高速化できます。
ビルドを自動化することで、すべてのステップが適切な順序でコミットごとに実施されていることを保証し、迅速なフィードバックを得ながら時間を節約できるメリットを得ることができます。
CI/CD パイプラインのビルド自動化の仕組みは？
CI/CD にあまり詳しくない場合は、（すべてをバージョン管理に移動した後で）最初に、自動ビルドをセットアップしてチームが変更をコミットするたびにそれをトリガーすることが必要です。 ビルドスクリプトや定義ファイルは、IDE が提供するものか、独自に作成したものがすでに存在するかもしれません。
それらがない場合は、作業している言語に適切なビルド自動化ツールを選択し、コンパイルするファイル、リンク、およびパッケージを指定する必要があります。 その上で、CI サーバーを使用して、最初のトリガーからフィードバックの提供、および失敗条件の定義までのさまざまなステップを調整することができます。
ビルドをトリガーする
自動継続的インテグレーションではマスターへのコミットが発生するたびにビルドがトリガーされるため、それぞれの変更は完了した後すぐに統合されてテストされます。 ビルドが合格すると、プロセスの次のステップがトリガーされます。
ほとんどの CI ツールでは、ビルド用の追加トリガーを構成し、その後に続くパイプラインステージをカスタマイズすることができます。
たとえば、特定のディレクトリのブランチにコミットされた場合は同一の一連のステップをトリガーするなどです。 一方、デプロイツールを利用して、追加のテストレイヤーを通過し、ステージング環境をリフレッシュするナイトリービルドをスケジュールすることがあるかもしれません。 また、ビルドステージを手動で開始することも可能です。
ビルドを実行する
ビルドステップを開発マシンではなく専用のビルドサーバーで実行するのが適切な実践です。 クリーンな環境でビルドすると、依存関係の欠落にフラグを立てることができ、「自分のマシンでは動作するのに…」といった課題を回避することができます。
ビルドステップ自体はユーザーが選択したビルド自動化ツール（Maven、Ant、Gradle など）を呼び出し、ビルドスクリプトや定義ファイルに指定されたタスクを実行します。
ビルドの実行にどれくらいの時間が掛かるのかがわかれば、特定の期間に完了しないビルド向けに失敗条件を構成するためのデプロイツールを使用すると良いでしょう。 こうすることで、実行に長時間を要するビルドがリソースを占領しないようにすることができます。
テストを実行する
自動ビルド管理プロセスは、コードをデプロイ向けに準備するだけでなく、ユニットテスト、リント、および静的コード解析といったさまざまなコードチェックを行うのにも最適です。 デプロイツールを利用してこれらのチェックをビルドの一環として実行し、問題が生じた時点で解決することで、コードの品質が改善しやすくなります。
これらのチェックはビルドアーティファクトが生成される前に実行されますが、失敗時に必ずしも残りのパイプラインを中断する必要はありません。 たとえば、リントエラーが検出された場合でも、ビルドアーティファクトを公開して次のパイプラインステージに進むようにすることもできます。 品質のしきい値を構成しておけば、「小さな」課題が蓄積されていくのを防止することができます。
ビルドアーティファクトを公開する
自動ビルドプロセスの出力はビルドアーティファクトで、これには、インストーラー、WAR ファイル、ライブラリ、およびコンテナーが含まれることがあります。 これらのファイルをアーティファクトリポジトリに公開しておけば、理想的にはデプロイツールを使って、その場所を、ビルドを別の環境にデプロイする際の中央管理ロケーションとして利用することができます。
CI/CD パイプラインのビルドの後のステージには通常、自動機能テストがあります。これにはビルドが 1 つ以上のテスト環境にデプロイされていることが必要です（データベースやその他のマイクロサービスといったコンポーネントとともにデプロイされている必要がある場合もあります）。 これらのテストに合格したら、同じビルドを使用してステージング環境をリフレッシュし、最終的にライブにリリースすることができます。
メトリクスとフィードバック
ビルドが正しく作成されたかといったビルド段階の結果や、ユニットテストやその他のチェックの結果は、CI ツールから確認できます。 失敗を通知するアラートを構成しておくと、迅速に対応し、コードをリリース可能な状態に戻すことができます。
デプロイツールでは、パイプラインのデータを照合して、傾向を分析することも可能です。 ビルド履歴に加えてビルド所要時間、合格率、およびコードカバレッジといったメトリクスをレビューすることで、CI/CD プロセスを改善するためのインサイトを得ることができます。