- 講演資料：CI/CDを使い倒して数段上のソフトウェア開発をしよう!
- CircleCI Japan金洋国氏のCodeZine連載：「エンジニアのためのCI/CD再入門」
CIを導入するために知っておきたいこと
近年、ソフトウェア開発において「テストコードを書くこと」が重要だと提唱されることが多くなった。
人間はコンピューターとは違い、同じ手順を100％正確に行うことはできない。何度も同じことをしていると、必ず見落としやミスが発生する。それを避けるために、テストコードを書いてテストを実施することが重要なのだ。そして、テストを自動的に実行し続けるために有効な仕組みがCIである。
では、なぜテストコードを書くだけではなく、CIを行う必要があるのか。その答えは、テストコードがアプリケーションの品質を保証し"続けられる"状態を保つためである。
「テストはあるけれど実行し忘れた。過去にテストを書いたけれど、いまは動かない状態になっている。テスト結果が環境依存で、ある環境では動くけれど別の環境では動かない。こういった問題を経験したことのある方は多いでしょう。CIを導入することで、これらの問題を防ぐことが可能になります。
CIはテストを常に自動で実行することで、開発者に環境やテストコードのメンテナンスを強制します。そうすることで、テストの信頼性を高められるのです」
金氏は次に、CIを導入するにあたって乗り越えるべき問題とその解決策について解説した。CIの導入を妨げる主な要因として「現在、テストコードがまったく書かれていない」という問題がある。これはCIを導入する上で最も厄介な問題である。この状態からCIを始めるには、以下の5ステップに沿って導入を進めるといいそうだ。
- 好きなCIツールを選ぶ。おすすめは、メンテナンスの負担が軽いCircleCIのようなクラウド型のCIツール
- ソースコードの構文チェックやカバレッジ計測、循環的複雑度のチェック、ドキュメントの自動生成など、テスト以外のさまざまなタスクをCI上で自動化する
- CIの実行結果を可視化する
- バージョン管理システムの機能を用いて、マージブロックを有効化する
- テストを追加していく
「何もない状態からテストを追加する場合、すでに動いているアプリケーションのユニットテストを書くのはメリットが少ないので、後回しで大丈夫です。代わりに、最も重要なビジネスロジックを検証するテストコードから追加していきましょう。
このフェーズで注意すべきは、無理は禁物だということです。テストしにくい処理に対して無理にテストコードを書こうとすると、燃え尽きてしまい継続し続けることが困難になります」
CDによって何が実現できるのか？
金氏は、なぜCDを導入すべきなのかについても解説した。
「みなさんは、検証環境で見つからなかったバグが本番環境で見つかる、アプリケーションを使ってみると仕様と違う動きをする、そもそも仕様が間違っていた、などの経験が一度はあると思います。
このような問題に対処するため、私たちはフィードバックループという手法を用います。これは、短いスパンでリリースして、なるべく早く他者からのフィードバックを得ることで、改善のサイクルをうまく回していくという概念です。
ソフトウェア開発の世界では、リリースの自動化がなければフィードバックループが回りません。リリース作業そのものに多大な工数が必要になるからです。つまり、フィードバックループを実現するにはCDが必要不可欠なのです」
ただし、CDの導入にあたり考慮しておくべきことがある。CDに向いていないアーキテクチャも存在するということだ。CDはそもそも、OSSのツールを用いて開発されたWebアプリケーションを素早くリリースするために進化してきた手法だ。そのため、メインフレームを使って運用しているエンタープライズ向けサービスなどは、CDに不向きだという。
サービスが密結合しているレガシーなアーキテクチャもCDには不向きだ。さまざまな機能が1つのアプリケーションに集約されているため、リリース作業そのものが非常に複雑なためである。この解決策は、「時間をかけてアプリケーションを少しずつ疎結合化・マイクロサービス化していくこと」「なるべくOSSを使いモダン化していくこと」だと金氏は解説した。
CDを使いこなせるようになると、リリース作業において、いくつもの利点が生まれる。まず、アプリケーションの迅速なロールバックが行えることだ。git revertコマンドによって問題のあるコミットをrevertし、その変更をgit pushすれば、CDツールが変更差分を自動リリースしてくれるようになる。つまり、ロールバックにかかる負担そのものが大幅に軽減されるのだ。
さらに、CDを活用することで本番環境でのテストも可能になる。多くのエンジニアが知るように、アプリケーション開発では「開発環境や検証環境では検証しきれず、本番環境にリリースしなければ確認できないもの」が山ほどある。だからこそ、本番環境にリリースしてテストをするのは理にかなった手法だ。
しかし当然ながら、本番環境でのテストはユーザーに影響が及んでしまうリスクがある。その課題を解決するため、本番環境でのリリースや検証作業を"安全に"かつ"効率的に"行うためのさまざまな手法が生まれてきた。その手法の根幹を支えているのがCDツールなのだ。
「手法の一つとして有名なのが、カナリーリリースです。この手法では、変更を本番環境の一部にのみ適用し、しばらくモニタリングします。正常動作していることが分かった後、システム全体に同じ変更を適用することで、障害発生のリスクを最小限にするというものです。
もう一つ有名な手法は、ブルーグリーンデプロイです。この手法では、本番環境を（ブルーとグリーンの）2つに分けます。まず、ブルーに対してアプリケーションの変更を適用し、ルーターやロードバランサーで本番環境のトラフィックをブルーに移します。ブルーで問題なく動いていればそのままブルーを新しいバージョンの本番環境として運用しますが、もし問題があればトラフィックをグリーンに戻すことで迅速にロールバックできます。
もし問題が起きても、すぐに既存のアプリケーションが乗っているグリーンに切り替えられるので、本番環境の障害を軽減できます」
副次的な効果として、CDによるリリース作業の最適化はエンジニアに"心理的安全性"をもたらしてくれるという。多くのエンジニアは、プログラミングは好きでもリリースはそれほど好きではない。なぜなら、失敗が障害に直結するという恐怖感があるからだ。しかし、簡単にリリースをやり直せる保証をCDがしてくれることで、心理的な負担が軽減されるのだ。
最後に金氏は、「CI/CDの未来」についてこう述べた。
「CI/CDは常に『何かの作業を自動化すること』で進化してきました。ということは、次の進化を知りたければ『いまは何を手動でやっているのか』を考えればいいことになります。例えば、CI/CD自体の設定やリリース後のモニタリングの設定、デプロイ環境の構築は手動でやっているチームが多いはずです。
近い将来、こういった領域すらCI/CDが自動化してくれる未来がやってくると、私は考えています」
お問い合わせ
CircleCI Japan
