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
