【CI奮闘記】第1章：Jenkinsを使う事=CI/CDではない» CloudBees|テクマトリックス

はじめに

この記事は、CI/CDが定着していない会社に転職して、上司の溝⼝さんにCI/CDの重要性を説きながら、その会社にCI/CDを定着させていく形式で進んでいく連載記事です。

登場人物

吉田：転職したてのエンジニア。前職では積極的にCIやCDという事に取り組みながら開発をしていた。

溝口：入社20年のベテラン。現職の部署の開発経験しかなく、従来通りのウォーターフォールでの開発経験しかない。新しい取り組みには積極的だが、どうしても今までの成功体験に寄ってしまいがち。

連載内容の趣旨

CI/CDについての概要の説明はもちろん、時には実演を伴って一緒に読み進めていくことによりCI/CDを理解し、実践できることを目的としています。

背景

CIという単語が初めて言われたのが1991年頃だそうです。それから約30年、すでにCIやCDという概念や用語はある程度日本でも定着しています。
概念だけでなく、代表的なCIツールであるJenkinsについて、使ったことはなくとも少なくとも開発に携わったことがあれば耳にしたことはあるでしょう。他にも、DevOpsという用語であったり、アジャイルやスクラムといった生産性向上のための概念も次々に誕生し、用語や概念自体の浸透は十分にしていると思われます。

しかし、実業務として定着している企業は用語の浸透度より少ないのではないでしょうか。

もしかしたらこのブログをご覧いただいている方の中にもJenkinsを試しに導入してみたけど、あまり効果がでなかったからCIやCDは効果がないと結論付けてしまった方もいるかもしれません。また、正しく実践できておらず効果が出ないと判断してしまった方もいるかもしれません。そういった方も今一度読んでいただけると幸いです。

第1章：Jenkinsを使う事=CI/CDではない

あぁ、先日うちの部署に来た吉田さん。平気だよ

こんにちは溝口さん。いまちょっとお時間良いでしょうか

今日みんなソワソワしてどうしたんですか？

今日は開発締めだからね。みんなバタバタしてるんだよ

開発締めで開発者がソワソワするのはわかるんですが、評価の方々もソワソワしてますよね？

そりゃあtrunkへのマージと評価環境へのデプロイがうまくいかないと評価チームは動けないからねぇ、ヤキモキもするさ

毎日trunkへのマージや評価環境へのデプロイをしていないんですか？

そうだね、開発期間は評価環境へのデプロイはしていないよ。

この回答から吉田さんは、開発チームがソースコードを頻繁に統合していないことを察知します。開発期間の最後にマージやデプロイへの不安がある状態は、CI/CDが導入されていないことの現れです。

trunk
- バージョン管理ツールにおいて、開発のメインとなるディレクトリ。リリースバージョンなどの最終的な成果物が納められることが多い。
評価環境へのデプロイ
- 本番環境へリリースバージョンを反映する前に、開発チーム内に閉じた環境を用いてテストが行われる。評価環境はステージング環境と呼ばれることもある。

そうですか。この部署ではCIやCDという取り組みはしていないんですか？

あぁ、前にちょっとやってみようと思ってね。とりあえずオープンソースだしとJenkinsを使ってみたんだけど、あんまり効果がなかったからやめちゃったんだよ。

CDでリリースサイクルが早くなるとあったけど、うちのシステムのリリース3カ月単位だし早いリリースサイクルになっても意味が無いしなぁと。それからだんだんJenkinsも使われなくなってね。

確かにそういった見方もできますが、CIやCDをもっとうまく実現できればこの開発締め間際でも、もう少し気持ちのゆとりを作れる気がします！

吉田さんの前の会社ではCIとかCDの取り組みをしていたの？

そうですね。私自身もCCJEというJenkins関連の資格を習得したり、いろいろな施策を打っていたと思います。そして効果も出ていたと思いますし、開発締めはやっぱりバタバタはしますがここまで部署全体はソワソワはしていませんでした

なるほど、そっかぁ。自分ずっとこの部署で実際にCIやCDを実施して効果がでた経験をしていなくて、よかったらちょっと聞かせてもらってもいい？

了解しました！まずCIやCDの実現 = Jenkinsを利用するという事ではないということから説明させてもらいます

それでは、CI奮闘記初回となる今回はCIとCDについて説明をしていきます。
CIやCDは1つの技術やJenkinsといったツールを指すものでなく、小さなサイクルでソースコードを統合したり、ソフトウェアの変更を常にテストして自動で本番環境にリリース可能な状態にしておくソフトウェア開発の手法を意味します。

CI(継続的インテグレーション)とは

従来の開発手法では、この溝口さんの部署の様に開発期間と決めその期間中はひたすら開発を続け、開発の締め日に最新の環境にすべてのソースコードをtrunkにマージし、マージしたコードを評価環境に適用し評価をするという方法がとられていたことが多かったようです。

複数人数で1カ月や2カ月、長い期間では半年や1年といった期間、開発したソースコードを一度にマージすると、当然影響するソースコードの量が多いためマージが失敗するリスクは高くなってしまいます。コンフリクトが発生したり予期せぬトラブルが発生したりすることは容易に想像ができます。

そこで登場したのがCIという考え方です。CI(継続的インテグレーション)では、開発者が自分のコード変更を頻繁にtrunkにマージし、その度に自動化されたビルドとテストを実行します。

ここで重要なのが、頻繁にtrunkにコミットすることで影響範囲を狭めることができたり、マージのリスクを下げることができるという事です。
エラーが出たとしても変更点が少ないため、開発締めに一括でtrunkにマージすることと比較して修正するコストやリファクタリングのリスクは低くなります。
また、自分の誤ったコードについてのフィードバックが早く来るとコードの内容も把握しているため、修正もスムーズに行うことが可能になります。

このように小さなサイクルでインテグレーションを繰り返し行い、インテグレーションのエラーを素早く修正することによりチームは統合されたソフトウェアをより迅速に開発できるようになります。

CD(継続的デリバリー)とは

継続的デリバリー(CD)は、継続的インテグレーション(CI)を拡張した手法で、ビルドやテストだけでなく、デプロイに至るまでのリリースプロセス全体を自動化します。
すべてのコード変更は、ビルドとテストを実行した後、評価環境などにデプロイして、システムテストやUIテストを行います。そしてテストで問題がない事を確認し、承認をもって本番環境へデプロイされます。
CDを実現することで、ソースコードの修正をいつでもデプロイすることが可能となり、素早く市場からフィードバックをソフトウェアに反映させることができます。

CIで述べた問題点と同じで、開発締めのタイミングで初めて評価環境に適用して評価をした場合、一度に大きな変更が入ることになります。
例えばデプロイができなかった場合、どのソースコードが問題なのか特定が非常に困難ですが、日時でデプロイしていた場合どのコードが原因かの特定が容易になります。そしてその結果は開発者にすぐにフィードバックされ、開発者は記憶に新しいうちに問題のソースコードの修正が可能になります。

継続的デプロイメントという手法もあり、こちらはコミットから本番環境までのデプロイを自動で実施してしまうという手法になります。

継続的インテグレーション、継続的デリバリー、継続的デプロイメントのそれぞれの関係は以下の図のようになっています。

CIやCDで重要なこと

CIやCDのポイントは複数あるのですが、特に重要なポイントは「なるべく早く担当者にフィードバックする」という点です。そのためにはそれぞれのフローの自動化が必要不可欠です。

たとえばCIの実現をしようとして開発者が毎日trunkにコミット・マージしたとしても、そのソースコードの単体テストのフィードバックが開発締めのタイミングでしか来ないのであれば意味がありません。ただし、常に人が更新のたびにすべての変更について手動でテストするわけにもいきません。人の工数をかけずに自動でテストを行う環境があることが望ましいです。

テストに限った話だけではありません。たとえばCDの実現をしようとして評価者が評価環境にデプロイしてフィードバックしようとしても、自動化せずに毎日手動で評価環境にデプロイしていたのであれば、デプロイの工数がかさみ、デメリットのほうが多くなってしまうかもしれません。
デプロイ後のテストも手動テストしかないのであれば「なるべく早く担当者にフィードバックする」ことの実現はできません。

あくまでCIやCDというのは修正が容易な早期に問題を発見することが目的であって、Jenkinsで自動化することはその手段です。「Jenkinsを導入しさえすればCIやCDが実現される」といった銀の弾丸ではありません。例えば自動テストがない状態でJenkinsを導入してビルドだけしたとしても、そこまでの効果は出ないでしょう。

ただ、Jenkinsを正しく使えば、素早いフィードバックループを実現し、劇的に開発プロセスを改善する手助けをしてくれるツールであることは間違いありません。

次回は具体的にどうCIを実現するといいのかというポイントを説明していきます。

うちの部署にCIを導入するとどう変わっていくのか楽しみにしてるよ。

サービス紹介

弊社ではCI環境の構築をお手伝いするCI環境構築サービスを行っております。Jenkinsの認定エンジニアが相談に乗りながらCI環境の構築を支援します。
https://cloudbees.techmatrix.jp/ci-solutions/setu p/

また溝口さんが話していたような、「Jenkinsを導入してみたものの効果がでない」という場合は構築した環境を利用する中での課題を解決し、定着するための支援をするCI/CD運営支援サービスを行っております。
https://cloudbees.techmatrix.jp/ci-solutions/management-support/