CIを回すとは?CIツールを導入すると何が嬉しいか?

Table of Content

昨今、システム開発の現場ではCI/CDという言葉がよく使われます。
しーあいしーでぃー、と発音するアレはいったいなんの話だろう?というのが本稿で解説するものです。

そもそもCIとは

Continuous Integration=継続的システム統合といったりします。
システム統合という表現は語弊しかないので、素直にインテグレーションと言われます。
なぜコンティニュアス(発語合ってますかね?)は継続的と呼ぶのかは正直分かりません。

CIの目的・導入理由

デベロッパーが受け持つシステム開発のフローを考えてみましょう。

  • システム設計
  • 実装
  • テスト
  • 納品

本当はもっと色々ありますが、ざっくりこの4工程に大別されます。
顧客が仕様変更や追加仕様を持ってきたら設計して、設計した通りに実装してテストし、問題がなければ納品というフローになります。

設計レビューは設計の段階で色々ありますが、この段階ではシステム化できないことが大半です。
ただし、実装はシステム化する作業ですし、テストもシステム化されたものを評価するので、この工程をなんとかできないの?ということで導入されるのがCIです。

たとえば、

  • 開発環境の構築を自動化する
  • 実装された結果、デグレ=過去に実装した機能に影響がない事を担保する

という大きな目標を達成するために使われます。

グチ

よく、QAの業務がオートメーションだと言われますが、それCIにすれば良くね?という発想でテストを自動化する、というアプローチがよくあります。
テストの評価をするのが別人なら、CIプログラマーといった方がいいような気もしますが、このあたりは線引きが難しいところです。

CDとは、その目的

Continuous Delivery=継続的デリバリーといったりします。
こちらは上記フェーズでいうところの納品部分です。
つまり、開発した内容を本番環境に移行するものと考えることができます。

先ほどのCIの例を取ってみても、

  • 本番環境を止める(メンテナンス情報を発信するなど)
  • 完成したコードを本番環境にコピーする
  • 本番環境で動作検証する
  • 本番環境を動かす(メンテナンス情報を発信するなど)

が大きな作業として考えられます。
本番環境に直接影響するため、責任はCI以上に重たいです。
あるいは、検証環境にデプロイするCDかもしれません。この辺りはプロジェクトの運用の仕方もありますが、大まかにはこの通りです。

やりたい事が違うだけで、アプローチというか考え方は同じです。
こういう事を人の手でやらないようにしよう、というのでCDを作ります。

明確に区分すると大変なので、まとめてCI/CDと言ったりします。

CI/CDツールの種類

昔はJenkinsを使っていました。
次に市民権を得たのがCircleCIでしょうか。
最近はGithubActionsとかが分かりやすいですが、CircleCIは今だにシェアが広いです。

その他多く採用されているCI

言語に依存します。

  • PythonならAnsible
  • RubyならChef
  • Nodeならnpm-ci

など、細かいのは色々ありますが、おおまかにはこのような形になります。
使い方によっては、DockerもCIと言えなくはないです。

どれがいいのか?

どれがいい、というより何を使っているか、でしょうか。
環境によって採用しやすいCIが異なります。
また、プロジェクトリーダーによって考え方も異なります。

とりあえずDockerやっとけ、というものもあれば、やりやすいからAnsibleなりChefなりnpm-ci使おうとなったり。
私はローカルで開発したいけど、運用はクラウドに丸投げしたいのでGithubActionsで使えるものに任せました。
GithubActionsでPythonとかをメインに使い始めるならAnsibleにするかもしれません。

基本的に考え方は同じで、やってる事も同じです。
やり方とか書き方が違うぐらいの差なので(そうでなければ冪等性=べきとうせい。「どんな状況でも同じ事を繰り返せば同じ結果になる事」を担保できない)必要になれば勉強するぐらいでいいと思います。

RPAとは違うのか?

RPAなどはユーザーオペレーションの自動化です。
目的は「これ人間の作業じゃなくね?楽しよう」という点では同じですが、システムを変えるのか操作を変えるのか、という違いがあります。
UWSCやiMacrosもRPAですね。
一番手っ取り早く分かりやすいRPA(のようなもの)はExcelマクロだと思います。
あるいはVBS(昨今のIEで使えるのかはまた微妙なところです)とかですね。

RPA開発については、私も昔は「そんなもの、AIで制御すればよくね?」と考えていましたが、AIの得意な領分とRPAの得意な領分が異なるので、同一視はできません。
AI幻想というか、ありがちですね。

シェアする