見出し画像

CI/CDのススメ

たるたる



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ツールがこの変更を検知し、自動的にビルドプロセスを開始します。
ビルドプロセスのステップについては下記などになります。

  1. ソースコードの取得: バージョン管理システムから最新のソースコードを取得します。

  2. 依存関係の解決: プロジェクトで必要とされるライブラリやフレームワークをダウンロードします。

  3. コンパイル: ソースコードを実行可能な形式（バイナリやバイトコード）に変換します。

  4. パッケージング: コンパイルされたコードをアプリケーションとしてパッケージ化します（jarなど）。

  5. アーティファクトの保存: ビルドされたアプリケーションをアーティファクトリポジトリに保存します。

自動テスト

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

  1. ユニットテスト: 個々のコンポーネントや関数が期待通りに動作するかをチェックします。

  2. 統合テスト: 複数のコンポーネントが連携して正しく機能するかを検証します。

  3. システムテスト: 完成したアプリケーションが全体として要件を満たしているかを確認します。

  4. 回帰テスト: 新しいコードが既存の機能に影響を与えていないかをチェックします。

CI/CDの導入

ツールの選定

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

  1. プロジェクトの要件と互換性: プロジェクトの規模、複雑さ、使用しているプログラミング言語やフレームワークとの互換性を考慮して、適切なツールを選ぶ必要があります。また、既存の開発環境やワークフローとの統合のしやすさも重要な要素。

  2. 機能と性能: 必要な機能（バージョン管理の統合、ビルド自動化、テスト自動化、デプロイ管理など）を提供しているかどうかを確認し、それらがプロジェクトのニーズに合致するかを評価します。また、システムのパフォーマンスやスケーラビリティも考慮する必要があります。

  3. ユーザーインターフェースと使いやすさ: ユーザーフレンドリーなインターフェースは、チームメンバーがツールを効率的に使用するために不可欠です。簡潔で直感的な操作が可能なツールを選択することで、学習曲線を緩和し、チームの生産性を向上させることができます。

  4. コストとライセンス: プロジェクトの予算内で利用できるツールを選ぶことが重要です。オープンソースのツールは費用を抑えることができますが、サポートやカスタマイズに制限がある場合があります。一方、商用ツールはより高度な機能とサポートを提供することが多いです。

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

CIの構築

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

  1. バージョン管理システムの設定: CIプロセスの基盤となるバージョン管理システム（例：Git）を設定します。これにより、開発者はコードの変更を追跡し、共有リポジトリに安全に統合することができます。

  2. CIサーバのセットアップ: Jenkins, Travis CI, CircleCIなどのCIサーバを選定し、セットアップします。CIサーバはコードの変更を検出し、ビルドやテストのプロセスを自動的に開始できるようにする。

  3. ビルドスクリプトの作成: プロジェクトに応じたビルドスクリプトを作成します。このスクリプトはCIサーバによって実行され、ソースコードをコンパイルし、アプリケーションをビルドさせる。

  4. 自動テストの統合: （ここが大変）単体テスト、統合テスト、その他の自動化テストをCIプロセスに組み込みます。これにより、新しいコード変更が既存の機能に悪影響を及ぼしていないかを確認します。ちなみにそもそもテストコードがないとCIの意味がないす。

  5. ビルドの自動化: コードの変更がリポジトリにプッシュされるたびに自動的にビルドとテストが実行されるようにCIサーバを設定。

  6. 通知システムの設定: ビルドやテストの結果に関する通知（Slackとか）を設定します。これによって、ビルドの成功や失敗、テストの結果をリアルタイムで把握できます。

CDの構築

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

  1. リリースプロセスの定義: CDを成功させるためには、明確で一貫性のあるリリースプロセスを定義する必要があります。これには、ビルド、テスト、デプロイメントの各ステップと、これらの間の移行条件が含まれます。

  2. 自動化されたデプロイメントパイプラインの設定: 自動化されたデプロイメントパイプラインを構築し、コードがプロダクション環境に安全にリリースされるようにします。このパイプラインは、ビルド、テスト、承認プロセスを自動的に実行します。

  3. 環境管理の最適化: 開発、テスト、ステージング、プロダクションなど、異なる環境間での一貫性を保証するための環境管理が重要です。これには、構成管理と環境の自動化が含まれます。

  4. 品質保証戦略の統合: CDプロセスには、厳格な品質保証戦略が必要です。これには、自動化されたテスト（単体テスト、統合テスト、システムテスト、負荷テストなど）の統合が含まれます。

  5. リリースの自動化: 手動の介入を最小限に抑えるために、リリースプロセスをできるだけ自動化します。これには、コードのマージ、ビルド、デプロイメントの自動化が含まれます。

  6. ローリングアップデートとロールバック戦略: プロダクションへの影響を最小限に抑えるために、ローリングアップデートやロールバック戦略を計画します。これにより、新しいリリースに問題がある場合に迅速に対応できます。

CI/CDの課題

ビルドやテストの実行時間が長い

CI/CDを導入した際にビルドやテストの実行時間が長いという課題に直面することはしばしばあります。この問題を解決するためには、以下のようなアプローチを検討すると良いと思います。

  1. パラレル実行: ビルドやテストのプロセスを並列化して実行することで、全体の実行時間を短縮できると思います。テストケースを複数のグループに分割し、同時に実行させるイメージです。ただし、同時に実行するとテストが落ちてしまうということもあると思うので、そのようにならないようなテストコードを書くように注意する必要があります。

  2. キャッシングの利用: 依存関係のダウンロードやビルド成果物（Docker imageなど）のキャッシュを利用することで、同じ操作を繰り返し行う時間を削減する。一度ダウンロードまたはビルドした内容をキャッシュし、次回以降のビルドで再利用する。

  3. 不要な処理の削減: ビルドやテストプロセス中に不要または冗長なステップがないかを見直し、最適化します。例えば、変更されていないコンポーネントの再ビルドや再テストを避けるなどです。

  4. リソースの最適化: CI/CDサーバのハードウェアリソース（CPU、メモリ、ストレージ）を見直し、必要に応じて強化することで処理能力を高めます。（お金の許す限り。。。）

  5. テストの優先順位付け: 重要度や変更の影響を受けやすい領域に基づいてテストを優先順位付けし、最も重要なテストから実行します。これにより、重要な問題を早期に発見し、修正に注力できます。

  6. インクリメンタルビルドの採用: 変更された部分のみをビルドするインクリメンタルビルドを採用することで、ビルド時間を大幅に短縮することが可能です。

この記事が気に入ったらサポートをしてみませんか？