あけましておめでとうございます。ソフトウェア開発をめぐる環境は相変わらず日進月歩です。この変化に伴って、ソフトウェア開発そのもののあり方も変化を続けています。本稿では、少し大きな視点から継続的インテグレーション（CI⁠）⁠・継続的デリバリ（CD）の最近の動向を紹介します。

CI/CDの大きなうねり

筆者がJenkinsに携わって12年になります。かつて、CI/CDの取り組みは、現在の機械学習やスケールアウト技術のような将来の可能性が注目される若い技術でした。ここ数年、この若い技術は、広く産業界で大規模に組織がかりで展開される成熟した技術に変貌してきました。

この背景にあるのは、ソフトウェア開発・運用全般における自動化のさらなる浸透です。このような自動化の進展は2つの側面から考えることができます。一つは、ソフトウェア開発に必要な様々な作業それぞれの「部品の自動化」という側面です。もう一つは、それら全体の順序や組み合わせを自動化する「流れの自動化」という側面です。

部品の自動化と流れの自動化は相互に利点を強め合い、ソフトウェア開発の省力化・効率化・品質改善へとつながっていきます。これがCI/CDが多くの企業で大規模に取り組まれるようになった原因です。

この2つの側面から昨年を振り返り今年を見据えるときに時に、何が言えるでしょうか。

「部品の自動化」のサービス化

部品の自動化の第一の目的は、ビルドやテストを実行して結果をどこかに保存するというものです。これに加えて、Jenkins、Bambooなど、伝統的なCI/CDツールでは、開発者に何がおきているのかをフィードバックをするのが機能の主眼の一つになっています。例えば、リッチなweb UIや、テストレポートの解析・表示、メールやチャットなどを通した結果の通知といった機能がこれに当たります。

その一方、最近登場した新しいツールやサービスの中には、部品の自動化の一義的な目的に特化して、開発者に「見せる」機能を始めとした他の機能を省略して他のサービスに任せる、というものが多く見られるようになってきました。これら「見えない」ビルドサービスという思想はUnix的とも言えます。Travisにも若干この傾向が見られるのを始めとして、LambCIやAmazon CodeBuildなどがこの例に当たります。

これら単機能特化型ビルドサービスの隆盛の一助になっているのが、GitHubのpull request（PR）です。PRによって、GitHubは目に見える必要の薄いサービスから開発者が常時インタラクトする場に変貌しました。例えば、Jenkinsの開発ではすべてのコード変更がPRを経由して行われますが、このような環境ではビルドサービスの仕事はPRの内容を検証してその結果をPRにフィードバックするのが主な仕事になります。結果がGitHubで見えさえすればよければ、自身が見える必要性は薄まります。GitHubには2016年にビルドが成功しないとPRがマージできない機能が追加されましたが、このような傾向の反映と言えます。

他方で、CDの仕事の幅は多岐に渡ります。特に「流れの自動化」にあたっては可視化が再び重要になります。伝統的なCI/CDツールではこの両方を一つに統合していますが、単機能特化型ビルドサービスは流れの自動化を誰かに任せる必要があります。この分野がどのように発展していくのかが注目されます。

「流れの自動化」とパイプライン

「部品の自動化」的な考え方は、ナイトリービルドやCruiseControlに始まる歴史の長い分野です。それに対し「流れの自動化」は、十分な数の部品の自動化が可能になって初めて視野に入ってきた比較的新しい分野です。最近のCI/CDに関する発展の多くもこれに関連しています。流れの自動化にもいくつかの側面があり、それぞれに様々な取り組みが行われています。

一つ目は、複数のマシンやツールにまたがる複雑な作業を順序化し実行する側面です。自動化が複雑になるにつれ、可視化・並列性といった観点から単純なスクリプトではやりづらいことを簡単にします。Jenkins Pipelineはこの側面を主軸にしており、並列実行、繰り返し実行、エラーからの復帰、タイムアウトなどをテキストで記述できるようになっています。

2つ目は、上流の環境から下流の環境へとアプリケーションをテストしつつプロモートしていく、というプロセスを補助する側面です。このような場面では、本番環境へのプロモーションのように人間が意思決定を下すのをソフトウェアが支援し、その記録を残したり、どの意思決定とどの自動化された作業がどのように結びついているかを可視化したりする役割が重要になります。伝統的には「リリース管理」と呼ばれている商用ツールの多い分野ですが、自動化の進展に伴ってその速度・頻度が大幅に増えてきており、裾野も広がっています。オープンソースのツールがこの裾野をどう埋めるのかに筆者は注目しています。Jenkinsでも2017年はこの取り組みが重要になると思っています。

3つ目に紹介したいのが、Netflixが主導しているSpinnakerというツールです。Spinnakerでは、まず、VMやロードバランサをひとまとまりのグループとしてまとめます。次に、特定のアプリケーションの特定のバージョンをグループに結びつけ、新しいバージョンがどのような手順を踏んで古いバージョンを駆逐していくのかを定義・実行することを可能にします。また、キャパシティの操作やVMのリサイクルなど運用作業もここから行います。Opsの側からスタートして流れの自動化へアプローチする面白い取り組みです。一方、このようなIaaS資源のグループ化は本来IaaS側が行うべきことであるという考え方もあって、実際PaaSやserverlessといった昨今の「IaaS軍拡競争」はこのような方向に技術を進めるものです。この2つの異なる考え方の「戦い」がどのように進展するかも見どころの一つです。

コンテナ実行環境とCD

Dockerなどコンテナ技術と、Kubernetes, Mesosなどのコンテナ実行環境は、2016年に技術者の世界を賑わした重要技術の一つです。これら実行環境技術を使うと、アプリケーションを頻繁に更新したり、テスト等で使うためにアプリケーションを一時的に配備して削除する、といった使い方が可能になります。しかし、こうした利点を十分に活用するためには、開発者の加えるコード変更を次々と実行環境へ送り込む上流部分、すなわちCI/CDが存在していなくてはなりません。

こうした背景から、コンテナ実行環境技術に取り組む各社がCI/CDとの連携に力を入れてきたのが2016年でした。例えば、Amazon Web Servicesは彼らの実行環境であるElastic Container Serviceを活かすためにCodeBuild, CodeDeployといったサービスを投入しました。Red Hatは実行環境技術であるKubernetesをOpenShiftとして製品化したのちに、Fabric8というプロジェクトを打ち上げて、JenkinsをCD技術に使ってOpenShiftの利点を拡大しています。一方、PivotalはConcourse.ciというソフトウェアを開発しています。

コンテナのビルド、テスト、リリース、また環境の間をプロモーションする手順の自動化など、このあたりの連携は今後も様々な発展が予想されます。

まとめ

現代においては、金融・流通・輸送など広範な産業でソフトウェアが一番重要な柱になりつつあります。このようにソフトウェアの役割が拡大するにつれ、より簡単に、より早く、より多くの優れたソフトウェアを作ることが求められています。もちろん、このような飽くなき機械化・改善への要求はもちろんソフトウェアに限った話ではなく、経済のあらゆる分野で行われていることです。

コンテナついでに、『コンテナ物語』という本では、同じような機械化・改善が海上運送にもたらした革命的な影響が語られます。つい1950年頃までは沖仲仕と呼ばれる港の荒くれ者たちが荷物を肩に担いで積み下ろしをしていたのが、2000年の現在では全長数百メートルという巨大船から岸壁のクレーンがコンテナを積み下ろしする世界になりました。同書の著者は、港の景色が一変しただけでなく、何十分の一にもなった輸送コストによって世界の経済の構造は一変したと説きます。

CI/CDを始めとするソフトウェア開発の技術の進歩が何十年というタイムスパンで見た時にどのような影響を及ぼすのか、新年を機会に心躍らせてみようではありませんか。