最先端DevOps開発環境から学ぶ「基本動作」の大切さ
次に、牛尾氏が企画し2017年2月初旬に行われた「DevOps EBCツアー」の様子が紹介された。牛尾氏は日本の顧客を米マイクロソフト本社に招き、先進的にDevOpsに取り組むチームや、自動化テストに熱心に取り組むチームなど、DevOpsの最先端を行く開発現場を共に見学した。このツアーを企画した意図を、牛尾氏は次のように語る。
「初めて米国で仕事をしたとき、日本の開発チームと比べて集中力やパフォーマンスが全然違うことに衝撃を受けた。しかも、彼らは特に目新しいことをやっているわけではなかった」
このような体験から、日本の開発者にも米国の開発現場の空気を実際に感じてほしい、と考えたのだ。
牛尾氏はツアーを通じて「基本動作の大切さ」を痛感したという。「DevOpsなどできない」と主張する現場ほど、そもそもアジャイルに対して真摯に取り組んでいなかったり、単体テストを自動化していなかったり……基本ができていないことが多いのだ。
DevOpsは何度もテストを行うことになるので、「回帰テストの自動化」といった基本的な作業をきちんと行うことが重要だ。米マイクロソフトのBing開発チームでは、単体テストはもちろんのこと、その上位層のテストや環境別のテストに関しても自動化している。それだけでなく、長いテスト時間を短縮するため、キューに投げて負担を分散させる仕組みを自分たちで作成し、不要なテストケースを発見して停止させる仕組みを作ったという。効率化にこだわった、これらの工夫には驚かされるばかりだが、彼らとて最初からできていたわけではない。徐々に単体テストの割合を上げ、エンドツーエンド（E2E）テストを減らしてきた。時間と手間をかけて文化を変え、素晴らしいDevOps開発環境を少しずつ実現してきたのだ。
米マイクロソフトにおける、先進的な取り組みを目の当たりにした牛尾氏は「日本ではどうだろうか。難しさを口実に工夫しない。変化を嫌うあまり、進化もしない状況に陥っているのではないだろうか」と、苦言を呈する。テストコードも書かないようでは、アジャイルもDevOpsもマイクロサービスもあり得ない。だからこそ「まずはテストコードを書くこと」を勧めるという。そして「テスト駆動開発（TDD）についてしっかり勉強をするべきだ」と力説する。
- 牛尾氏が作成した動画「6 Minutes DevOps: テスト駆動開発」
牛尾氏はさらに、CI/CDの究極のコツについて言及。「PowerShell」を開発したジェフェリー・スノーバーが「Remove Windows＝マイクロソフトのサーバーからWindowsを取り除いた」ことを紹介した。ウィンドウ、つまりGUIでの操作を自動化するのは難しい。そこで彼は、PowerShellを作ってGUIを使わずにコマンドラインだけで操作ができるようにした。自動化のコツは非常にシンプルで「コマンドラインで動かすこと」なのだ。
DevOpsを快適に推進する「Visual Studio Team Services」
DevOpsを推進しつつ、「ベンダーロックインが嫌い」という牛尾氏は、気に入っているツールとして「Visual Studio Team Services」を紹介。開発者はサム・グッケンハイマー氏だ。彼はAgile Conference 2014のキーノートスピーカーとしても知られ、マイクロソフトのDevOpsをリードした人物ともいわれている。
Visual Studio Team Servicesは、SaaS版であれば3週間ごとにアップデートされ、衝撃的なスピードで使いやすさが増しているという。「なぜ、日本で使われていないのか分からない。過小評価されている」と、牛尾氏が憤るほどだ。標準機能だけでも、自動化ツールや情報共有ツールなど、DevOpsに必要な機能がほぼ網羅されている。
Visual Studio Team Servicesの特徴的な機能の1つとして、牛尾氏は「Hosted」を例に挙げた。自動化に必要なビルドマシンが用意できない状況でも、この機能を使えば自らサーバーを立てる必要がない。さらに、OSはWindowsとLinuxがいずれかを選択できる。Macを使用したい場合は、エージェントを入れることによって対応が可能だ。
そして、牛尾氏はDevOpsプラクティスの1つである「継続的インテグレーション」に触れた。アプリケーション開発中、「ブランチを切ってメインラインにマージする」過程の時間、つまり結合までの時間が長ければ長いほど、コンフリクト発生の可能性が高くなる。この問題を解決すべく、アジャイルマニフェスト起草者の1人であるケント・ベック氏は「常に結合し続ければ問題が減るのでは？」と考えた。コードに変更があればすぐにビルドして結合する。そこで問題が生じたとしても、すぐに解決し、再び結合することで問題の影響範囲を最小限にとどめることができる。このように変更と結合のサイクルを小さく回す仕組みにすれば、コードへの変更が多い環境でも大きな手戻りがない。加えて、自動テストを行えば安全に開発を進めることができる。これが「継続的インテグレーション」だ。逆に言うと、ブランチを切ってマージするまでの時間が長ければ、どんなに素晴らしいツールを導入しても“ひどい目”に遭う可能性は高い。つまり、考え方をチームでシェアしていかなければツールを活用することはできない。
さらに、プラクティスの1つである「リリースマネジメント」の中で、環境を作ったり、負荷テストを行ったりする際にも自動化は必要だ。パイプラインの基本的な作り方に、ビルドした成果物をそのままリリースに使用し、さまざまな環境にデプロイしていく手法がある。というのも、どんなに開発環境側でビルドやテストを行っても、リリース側でビルドやテストを行う際にパッケージが変わる可能性もあるため、同じものである保証はできないからだ。
ここで、Visual Studio Team Servicesがさまざまな環境にデプロイしていくデモを行おうとしたものの、ネットワーク不調のため接続できず、断念することに。そして、デモの中で披露されるはずだったDockerのオーケストレーションツール、Kubernetes（キューバネイティス）の機能に触れつつ、タスクを書いたのが牛尾氏自身であることが明かされた。タスクは隠蔽されて使用者からは触れないと思われがちだが、ソースは全て公開されている上に、自作することも可能だ。
デモ動画［1］
ネットワークの不調で当日実施できなかったデモを、牛尾氏は動画で公開している。
