こんにちは。AS部の兼安です。
秋になり少し涼しくなってきましたね。
この秋から冬にかけて、DevOpsまたはDevSecOpsを構成する技術に関してのブログをたくさん書こうと思います。今回は一発目としてCI/CDパイプラインの全体概要とその役割について記述します。
DevOpsを語るにあたり、いきなりCI/CDパイプラインの話をするのは、本当は正しくないと思います。なぜならCI/CDパイプラインを作ることがDevOpsの目的ではないからです。
そうなのですが、DevOpsの話のとっかかりとして、CI/CDパイプラインが話しやすいので、まずはCI/CDパイプラインの話をさせていただきます。
なお、本記事ではCI/CDパイプラインはAWS CodePipelineやGitHub Actionsで構築することをイメージしています。
CI/CDパイプラインの全体像
CI/CDパイプラインはこの図で表されるように、バージョン管理システムにソースコードを送信した後、デプロイまでの流れを自動化するための仕組みです。
なぜ自動化するかというと、現在のシステム開発におけるデプロイまでの作業でやるべきことに全力で向き合うと、手順が複雑で手動ではやりきるのは難しいからです。 この手順を人の手で行っていると、開発のスピードがあがりません。これがCI/CDパイプラインの存在理由です。
CI/CDパイプラインの自動起動
CI/CDパイプラインはバージョン管理ツールを監視することができます。
AWS CodePipelineなら、CodeCommitやGitHubのリポジトリなどを監視できます。
GitHub Actionsなら、GitHubのリポジトリを監視できます。
監視することにより、リポジトリに対してソースコードをプッシュしたら自動でCI/CDパイプラインが起動します。 しかし、プッシュする度に常にCI/CDパイプラインが起動してしまうと、事故のリスクが高くなります。 そこで、CI/CDパイプラインは監視対象を特定のブランチに絞ることができるので、 テスト済みのコードをマージしたdevelopブランチ、本番リリース用のコードをマージしたmainブランチなど、特定の意味を持ったブランチに対してCI/CDパイプラインを起動するように設定します。
例えば、機能開発はfeatureブランチで行い、開発が完了したらdevelopブランチにマージするという開発フローを想定します。CI/CDパイプラインの監視対象をdevelopブランチに設定すると、featureブランチでの開発作業では、CI/CDパイプラインは起動しません。開発が終わったfeatureブランチをdevelopブランチにマージした時点で、CI/CDパイプラインが起動します。
この、バージョン管理ツールをトリガーにしたCI/CDパイプラインの自動起動のメリットは以下の通りです。
- ソースコードの修正が発生した時に、やらなければならない各種チェックの実行漏れがなくなる
- ソースコードのプッシュをトリガーにCI/CDパイプラインが起動するので、コンソール操作が減る
現実的には、ブランチにマージするタイミングと、デプロイが許されるタイミングは一致しないことが多々あるので、完全な自動化はしないかもしれません。（デプロイOKになるまでマージを待ってと言われたらそれはそれで辛いですね。） 従って、 後者のメリットは享受しづらいかもしれませんが、前者だけでも大きなメリットがあります。
解析
CI/CDにおける解析とは、ツールによりソースコードを走査・解析し、潜在的なバグ、セキュリティ脆弱性、コーディング規約違反、使用されていない変数・関数、引数の誤りなどを検出することです。
ソースコードの解析は、全体で行うと時間がかかるので、各開発者に実行を任せるスタイルだとどうしても実行漏れが発生します。それゆえ、CI/CDパイプラインで自動化が有効です。1 潜在的なバグは、例外の隠蔽などが挙げられます。セキュリティ脆弱性は、XSSやSQLインジェクションなどです。これらは、目視や手動テストで見つけるのは大変な労力が伴います。また、リリース後に表面化してしまうと、多くの場合は類似調査を求められるので、チェックする仕組を確立して自動化しておくのに大きな価値があります。
使用されていない変数・関数、引数の誤りの検出は、バージョンの古いPHPなどのスクリプト言語だと、動作させないと問題を検出できないので、解析がなかなかの効果があります。
また、コードメトリクスを取得することもできます。コードメトリクスとは、コードの品質を測るための指標です。例えば、ループのネストの深さ、分岐の多さなどからくるコードの複雑さを測ることができます。
コードメトリクスも全体に対して取得すると時間がかかるので、CI/CDパイプラインでの自動化が有効です。
ここからは主観になりますが、コードメトリクスは、正直なところ活用するのが難しく、品質の向上に直結するとは言い難いと思います。しかし、長期的に計測し続けることで見えてくるものもあるので、まずは計測する仕組みを作っておくことをおすすめします。
ビルド
CI/CDにおけるビルドとは、必要なライブラリをインストールした上で、ソースコードを実行可能な形式に変換することです。コンテナを使っている場合は、コンテナイメージを作成することも含みます。 ビルドを自動化する意味は2つあります。
- 開発者がビルドを実行する手間を省く
- ビルド環境を固定化し、環境の差異による不具合を防ぐ
ビルド環境の固定化は、当たり前で自動化するほどではないように思えます。しかし、エンジニアは、多くの場合複数の案件を受け持っており、開発環境を複数持っていることが多いです。これにより、意図せず異なるビルド環境を使用してしまうことがあります。CI/CDパイプラインは、ビルド環境を固定化することで、この残念な事態を防ぐことができます。
コンテナを使っている場合は、ビルドで作成したコンテナイメージに対して、脆弱性のスキャンをかけることもできます。
テスト
CI/CDにおけるテストは、自動テストのことを指します。CI/CDパイプラインで自動テストを実行することは、以下のメリットがあります。
- 自動テストの実行漏れがなくなる
- ソースコードのマージのタイミングで確実に自動テストが実行される
ソースコードのマージのタイミングで確実に実行されるのが重要なのは、CI/CDの解析も同様です。しかし、ソースコードがマージされた後でバグが見つかるケースはより現実味が感じられると思います。通せばすぐにわかるような軽微なバグが、プロジェクト後半で見つかってしまったことはないでしょうか？このことを思い浮かべれば、ソースコードのマージのタイミングで確実に自動テストを実行することの重要さを感じていただけるのではないかと思います。
なお、自動テストの実装についてはそれだけでとても長くなるので、本記事では触れません。
デプロイ
CI/CDパイプラインにおけるデプロイの役割
デプロイとは、ビルドで作成した実行可能ファイルを特定の環境に配置する行為を指します。具体的なデプロイ作業としては以下のようなものが考えられます。
- 実行可能ファイルの配置
- パーミッションの設定
- 空フォルダの作成
- データベースのマイグレーション
- キャッシュのクリア
- システムの再起動
一つ一つは簡単な作業で、手順書の作成とリハーサルにより、確実に作業を完遂することはできるように見えます。 しかし、以下のようなことはないでしょうか？
- アプリ開発者とデプロイ担当者が異なる
- 本番へのデプロイが夜間や休日に行われる
- タイムスケジュールに余裕がない
- 頻繁に行われないため、練習の機会が限られる
これらの点から、デプロイは誤りが発生しやすく、属人性が高まる傾向があります。 そこで、これらの課題を解決するために、デプロイ作業の自動化が重要となり、CI/CDパイプラインの中でのデプロイの役割が強調されるわけです。
デプロイ戦略
ここからは、ツールの話になります。 デプロイの方法やアプローチはいくつか存在します。これらはデプロイ戦略またはデプロイポリシーと呼ばれます。
| デプロイ戦略 | ダウンタイム | ロールバックの容易性 | ユーザーへの影響度 | 複雑性 | コスト |
|---|---|---|---|---|---|
| Blue-Green デプロイ | なし | 高 | 中 | 高 | 高 |
| Immutable デプロイ | なし | 高 | 中 | 高 | 中 |
| Rolling デプロイ | 部分的 | 中 | 高 | 中 | 中 |
| In-place デプロイ | あり | 低 | 高 | 低 | 低 |
| Canary デプロイ | なし | 高 | 低 | 高 | 中 |
例えば「Blue-Green デプロイ」、こちらは2つの本番環境を持つことを意味します。 一方（ブルー）で新しいバージョンのコードをデプロイし、他方（グリーン）では古いバージョンのコードを実行します。 テストが終了したら、トラフィックを新しい環境に切り替えます。 もし何か問題が発生した場合は、すぐに前のバージョンに戻すことが可能です。
・・・と言うのは簡単ですが、これを手動で行うことを徹底するのは困難を極めます。 CodePipelineなどのCI/CDパイプラインのツールを使えば、現実的な工数で「Blue-Green デプロイ」を実現することが可能です。 このように、人の手で実現するには困難な作業を実現するのもCI/CDパイプラインの役割です。
Blue-Green デプロイについては、こちらの記事でそのメリットを詳しく書いています。
併せてご覧ください。
blog.serverworks.co.jp
トレーサビリティとロールバック
CI/CDパイプラインは、バージョン管理とデプロイを連携させることで、トレーサビリティを高めます。これにより、予期しないバージョンのリリースを未然に防ぐことができます。
また、過去のバージョンが保存されているので、問題が発生した場合に容易に前のバージョンに戻すことができます。
このトレーサビリティをさらに活用し、デプロイのタイミングや頻度を分析することで、デプロイの効率化や最適化のヒントを得ることも可能です。
まとめ
CI/CDパイプラインは、自動化によりミスの可能性と属人性を排除するとともに、人の手でやり切るのが難しい作業群を徹底させることができます。 これにより、製品を世に出す作業の心理的障壁を下げ、開発者が利用者からのフィードバックを受けやすくするのがCI/CDパイプラインの役割です。
サーバーワークスはDevOpsを支援するサービスを提供しています。
- 各開発者が自分でソースコードの解析をするのに適した、差分ファイルだけを解析する方法も存在します。こちらは別の機会に紹介します。↩
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS1課所属
AWS12冠。
広島在住です。
最近認定スクラムマスターになりました。今日も明日も修行中です。
