今年のTechnology Radarは継続的ナントカまわりの技術動向が面白い

マーティン・ファウラー先生が在籍することで有名なThoughtWorksのTechnology Radarを斜め読みしてみました。今回は特に継続的インテグレーション/デリバリ周りの「検証やトライアルはおしまい。採用だ！」になっている技術が面白かったです。

デプロイのリリースからの分離

継続的デリバリを実現するうえで、「デプロイのリリースからの分離」のような利便性の高いテクニックが明瞭になり、その重要性が再確認できた。 — Decoupling deployment from releaseより

そもそも「リリース」と「デプロイ」の違いがわかりにくいんですが、リリースの中にデプロイを含めている人もいたり、デプロイはリリースと違うという人もいたりするので、こうやって改めて言われると「確かに」ってなります。説明を読んでみるとこんな感じでしょうかね。

• デプロイ期間： アプリやインフラの変更を確認する期間。
• リリース期間： エンドユーザに対して、変更したフィーチャを出すタイミング。ここからビジネスインパクトが発生するはずだから、「リリース後、１週間はビジネスインパクトをモニタリングする」とかになるはずだから、リリースは一点を指すのではなく、「期間」と考えるのがたしかによさそう。

フィーチャトグル（feature toggle）は牛尾さんの訳がわかりやすいです。ひとことで言うと「動的なオンオフ」かしら。オンオフのコントロールは、リリースタイミングをコントロールできないiOSアプリ開発で身にしみて理解できました。

ダークローンチ（dark launches）はAgile Testingというブログ（2009年の記事だから結構古い）を読む限りだと、Facebookでやってる「一定範囲のユーザに向けてのリリース（subset of your users）」を指しているみたいです。Facebookの継続的デプロイメントだとユーザがより狭義となり「本番にリリースしたけど開発者しか使えない機能」とのこと。

フィーチャとグルやダークローンチを使って、リリースなしで本番に頻繁にリリースが可能になり、変更に対するリスクを減らす。さらには、ビジネス関係者もリリースを（ビジネス視点で）コントロールできるようになると。

開発パイプラインとしてのJenkins

CruiseControlやJenkinsといったCIツールには価値があるが、CIを超える何かを求めた場合（例えば、開発パイプライン）、複雑になってしまう。 — Jenkins as a deployment pipelineより

JenkinsにPipelineプラグインを入れたときに感じた「できるっちゃできるけど、無理矢理感あるな」ってのが、今回のステータス「Hold」になって納得した感じがあります。全世界がむずむずしていたのかもしれない。

Jenkinsでがんばるのではなく、専用のパイプライン構築ツール（ConcourseCI, LambdaCD, Spinnaker, Drone やGoCD）を使ったほうが良さそう。

 

プロジェクトよりもプロダクトへ

予算ベースや決められた期間ベースの開発といった、長い間支持されてきたプロジェクトベースのソフトウェア開発の考え方が最近のビジネスニーズにマッチしない。 — Products over projectsより

2015年5月のステータスは「トライアル」だったのが「採用」になりました。世界的にもプロジェクト型からプロダクト型の開発が増えていきそうですね。

一回作ってしばらく何もしなくてもいいソフトウェアであったり、同じようなシステムをいろんな企業にコピペ構築する（パッケージソフトとかこれに近い？）のであれば「プロジェクト型」が効率良さそうです。

でも、そうでないなら、予算や期間に向かって開発するのではなく、プロダクトに向かって仕事したほうが、ユーザニーズを探らなければならなかったり、リリース後の軌道修正が必要だったりする「イマドキのビジネス」にマッチするのはイメージしやすいですね。

そもそも、上で紹介したような「継続的ナントカ」な開発をしていると、プロジェクト型開発より、プロダクト型開発のほうが親和性が高そうです。