BLOG

2022-01-31 テクニカル

CI/CDとは

どうも、畜産ペンギンです。

 

あっちゅー間にもうすぐキャンプインですね。

今年も優勝して欲しいですが、2年は最下位でも生きていけそう位には今の所落ち着いています。

 

今回は、CI/CDという物について語って行こうと思います。

目次は以下の通り。

 

目次

・CI/CDとは

・メリット

・アンチパターン

・CI/CDツール

・まとめ

 

CI/CDとは

CI/CD(Continuous Integration / Continuous Delivery)とは、日本語に訳すと「継続的インテグレーション / 継続的デリバリー」という意味で一般的にはビルド、テスト、デプロイを自動化し、短期間で品質管理を行う手法の事を指すようです。

 

CIがコードの変更時に自動的にビルドとテストを行うのに対し、CDは更に加えてデプロイを行う発展形となります。

 

何となく言葉の本質的にはもっと広義の物なんじゃないのって思いましたが、調べてもあまりこれ以上言及している人が居ない。

AWSの中の人が言うには「継続的インテグレーションという用語が最もよく使われるのは、ソフトウェアのリリースプロセスのビルド段階または統合段階を指す場合で、オートメーションの要素 (CI やビルドサービスなど) と啓発の要素 (頻繁に統合する必要性を学習することなど) の両方が含まれます。」だそうです。

参考:継続的インテグレーションにについて

 

メリット

まぁ直接的なメリットで言うとビルド、テスト、デプロイが自動化出来るで終わりなんですが、これの影響は単純にボタンを押す回数が減るという事だけでは無いです。

 

例えば、デプロイ時にエラーが発生したとしましょう。

CI/CDを行っていなければある程度まとめた修正を行った後にデプロイを行うのが一般的だと思うので、原因箇所の特定に時間がかかります。

CI/CDを行っていれば少し直したらすぐデプロイという事が可能なので、修正箇所が少なくエラーの特定も容易になるという事です。

 

ある程度大きな規模の開発ですと同じアプリケーションに対し複数の人が機能毎に分かれてコーディングを行います。

まぁまだ明確に機能毎に分かれていて他機能に影響が無い作りになっていれば良いのですが、中々そんな綺麗なソースは存在しません。

大体がこっちを直したら何故かあっちがバグってるって作りになっています。

そんな感じで各自の修正が全て終わってから機能を統合してみるとバグだらけじゃんってなり、そこからの作業は大変です。

何でバグったのかの原因究明も他機能のあらゆる改修箇所に一度目を向ける必要があり、バグ修正も複数行っている内に一度直したバグが復活していたり。。

小まめに統合(インテグレーション)してればこうはならないよって事ですね。

で、小まめに統合するには自動化が必要だと。

 

アンチパターン

とは言え自動化できたら良かった良かったで終わりでは無く、運用にもある程度気を遣う必要があります。

運用する際のアンチパターンとして、以下があります。

 

・ローカルで長時間開発し過ぎ

折角ビルドからデプロイまでを自動化しているのに、一度に行う変更が多き過ぎると自動化してない時と変わりません。

 

・ビルドの実行頻度が低い

1日1回とかで自動化しちゃってるケース。折角自動化してるのだからコミットの度に実行するようにして問題を早期発見しましょう。

本番環境へのデプロイは当然タイミングがあるとは思いますが。

 

・ビルドの失敗が放置される

ビルド失敗しているのに誰も気付かない、あるいは失敗時の対応手順が整備されていなくて誰も対応しないケース。

まぁビルド失敗したら通知は来るようにしておきましょう。その際の手順の標準化も含めて。

 

・ビルドの時間が長すぎる

ビルドの時間が長すぎて確認に時間がかかってしまうケース。

自動で行うテストを厚くしすぎると陥りやすい。自動で行うテストの役割を見直しましょう。

 

CI/CDツール紹介

そろそろ古いと言われるかもしれませんが有名所はやはりJenkinsでしょうか。

OSSであり、無料です。オンプレで使用出来るというのも逆に強みになったりするようなしないような。

プラグインも豊富でやろうと思えば大抵の事ができます。

 

後は最近クラウド上での実行環境を提供しているサービスだと大体使えたりするのかな?

AWSだとAWS Codeとかですかね。

 

まとめ

導入ハードルが最近は下がっているので結構な開発現場で適用されているのかなと思います(たぶん)。

でも未だにされていない所も(たぶん)結構あって、そんな時にどうすれば良いのかと言うと、まずは自動化されていない事に対するリスクを把握しておく事。

 

放っておけば、ぐっちゃぐっちゃな順番で修正された物がコミットからデプロイまでされます。

なので尚更手順を明確化しておく必要があります。

 

で、少しずつで良いので自動化を進めていきましょうと言った感じですかね。

 

今回はここまでです。

 

さようなら。

The following two tabs change content below.

畜産ペンギン

主にネットワーク系、開発系を経験しているエンジニアです。 技術系を気まぐれに書いて来たけどそれ以外も気まぐれに書いていこうかなぁと。