CI/CDのススメ

2024年1月6日 23:54

CI/CDについて

CIとは

CIとはContinuous Integration（継続的インテグレーション）のことで、ソフトウェア開発のプロセスで、開発者が頻繁に（一般的には日次または数時間ごとに）コード変更を共有リポジトリに統合するプラクティスです。このプロセスは、自動化されたビルドとテストを用いて、新しいコード変更が既存のコードベースとうまく統合され、問題がないかを確認します。CIの目的は、開発プロセスの早い段階でバグなどを発見し、修正することにより、ソフトウェアの品質を向上させ、リリースプロセスをスムーズにすることです。

CDとは

CDとはContinuous Delivery（継続的デリバリ）のことで、ソフトウェア開発のアプローチの一つで、ソフトウェアが常にリリース可能な状態に保たれることを目指します。ソフトウェアの変更（新機能、バグ修正、構成変更など）が自動化されたテストとビルドのプロセスを経て、本番環境にデプロイする準備が常にできていることが重要です。CDを採用することで、開発チームは迅速に新しい変更を顧客に届けることができ、フィードバックを速やかに取り入れることが可能になります。また、リリースプロセスの自動化により、手作業によるエラーやデプロイの遅延を減らすことができます。

CI/CDがなぜ必要なのか？

CI/CDとよく聞くけど、CI/CDがなぜ必要なのかについてですが、CI/CDを導入することで、品質を担保しつつ、リリースサイクルを短縮することができるためです。
ソフトウェアを開発する上で、機能の追加は頻繁に起こると思います。その中で、スピーディに開発するにもテストがおろそかになってしまうこともしばしばあると思います。
そういった時にCI/CDを導入すると下記のようなメリットがあります。

ただし、CI/CDツールを導入しただけでは品質の担保はされません。テストコードは開発者たちが書く必要がありますし、テストケースが漏れていたら不具合が出てしまうので、その点は勘違いしないようにしておきましょう。

品質担保とヒューマンエラーの回避

CI/CDを導入することで、コードを変更するたびに自動でテストが実行されるようになります。（もちろんテストコードを書く必要があります）
つまりは、誰がやっても同じように同じテストが実行されるわけなので、そもそもテストが漏れてしまったり、テストの内容が人によって異なってしまうなどの問題が回避できるかと思います。

また、例えばコードのコミットをトリガーにテストを実行するようにすることで、開発段階（プルリクエスト）やmasterブランチにマージされた段階でコードのバグを見つけることができます。

あとは製品が大きい場合は、リグレッションテストなども手動でやっていると膨大な時間がかかってしまいますが、自動で実行されていればテストのコストも下げることができます。

リファクタリングがしやすい

機能を追加していると、時にはリファクタリングしたくなることが多いと思います。そこで、単体テストなどがなかったり、テストがメンテされていない場合は手動でテストするケースが増えることであったり、修正してもこれであっているのか（正常系テストが落ちているので正しい挙動がわからなくて不安）などの懸念があり、リファクタリングを避けてしまうケースがあるかと思います。
そういった面ではCI/CDが導入され、しっかり単体テストが常にグリーンな状態になっていることが担保されていれば、気軽にリファクタリングして、テストが落ちたら修正…という流れで攻めのリファクタリングが可能になると思います。

スピーディなライブラリのバージョンアップやEOL対応

製品に使っているライブラリなどのバージョンアップ対応や脆弱性対応も日頃からたくさんあると思います。ライブラリのバージョンを上げただけなのに、全てのテストを手動でやったりするのはかなり大変です。

CI/CDでできること

自動ビルド

自動ビルドは、ソースコードから実行可能なアプリケーションやソフトウェアを自動的に生成するプロセスです。通常、開発者がソースコードをGitなどのバージョン管理システムにプッシュすると、CIツールがこの変更を検知し、自動的にビルドプロセスを開始します。
ビルドプロセスのステップについては下記などになります。

ソースコードの取得: バージョン管理システムから最新のソースコードを取得します。
依存関係の解決: プロジェクトで必要とされるライブラリやフレームワークをダウンロードします。
コンパイル: ソースコードを実行可能な形式（バイナリやバイトコード）に変換します。
パッケージング: コンパイルされたコードをアプリケーションとしてパッケージ化します（jarなど）。
アーティファクトの保存: ビルドされたアプリケーションをアーティファクトリポジトリに保存します。

自動テスト

自動テストは、ソフトウェアの品質を保証するために、コード変更のたびに自動的にテストを実行するプロセスです。自動ビルドが成功した後、CIツールは様々な種類のテストを自動的に実行します。
テストの種類については下記に例をいくつか載せておきます。

ユニットテスト: 個々のコンポーネントや関数が期待通りに動作するかをチェックします。
統合テスト: 複数のコンポーネントが連携して正しく機能するかを検証します。
システムテスト: 完成したアプリケーションが全体として要件を満たしているかを確認します。
回帰テスト: 新しいコードが既存の機能に影響を与えていないかをチェックします。

CI/CDの導入

ツールの選定

CI/CDを導入するためにはまず、ツールを選定する必要があります。
CI/CDツールの選定は、ソフトウェア開発プロセスの効率化と最適化において重要なステップです。適切なツールを選定する際には、以下の点を考慮してみるといいと思います。

プロジェクトの要件と互換性: プロジェクトの規模、複雑さ、使用しているプログラミング言語やフレームワークとの互換性を考慮して、適切なツールを選ぶ必要があります。また、既存の開発環境やワークフローとの統合のしやすさも重要な要素。
機能と性能: 必要な機能（バージョン管理の統合、ビルド自動化、テスト自動化、デプロイ管理など）を提供しているかどうかを確認し、それらがプロジェクトのニーズに合致するかを評価します。また、システムのパフォーマンスやスケーラビリティも考慮する必要があります。
ユーザーインターフェースと使いやすさ: ユーザーフレンドリーなインターフェースは、チームメンバーがツールを効率的に使用するために不可欠です。簡潔で直感的な操作が可能なツールを選択することで、学習曲線を緩和し、チームの生産性を向上させることができます。
コストとライセンス: プロジェクトの予算内で利用できるツールを選ぶことが重要です。オープンソースのツールは費用を抑えることができますが、サポートやカスタマイズに制限がある場合があります。一方、商用ツールはより高度な機能とサポートを提供することが多いです。

このような要素を総合的に評価し、チームのニーズに最も合致するCI/CDツールを選択してみてください。CI/CDツールはいろいろありますが、下記の記事にまとまっているので参考に見てみてください。

CIの構築

CIの構築に必要な工程の例を以下に書いてみました。

バージョン管理システムの設定: CIプロセスの基盤となるバージョン管理システム（例：Git）を設定します。これにより、開発者はコードの変更を追跡し、共有リポジトリに安全に統合することができます。
CIサーバのセットアップ: Jenkins, Travis CI, CircleCIなどのCIサーバを選定し、セットアップします。CIサーバはコードの変更を検出し、ビルドやテストのプロセスを自動的に開始できるようにする。
ビルドスクリプトの作成: プロジェクトに応じたビルドスクリプトを作成します。このスクリプトはCIサーバによって実行され、ソースコードをコンパイルし、アプリケーションをビルドさせる。
自動テストの統合: （ここが大変）単体テスト、統合テスト、その他の自動化テストをCIプロセスに組み込みます。これにより、新しいコード変更が既存の機能に悪影響を及ぼしていないかを確認します。ちなみにそもそもテストコードがないとCIの意味がないす。
ビルドの自動化: コードの変更がリポジトリにプッシュされるたびに自動的にビルドとテストが実行されるようにCIサーバを設定。
通知システムの設定: ビルドやテストの結果に関する通知（Slackとか）を設定します。これによって、ビルドの成功や失敗、テストの結果をリアルタイムで把握できます。

CDの構築