CI/CD Conference 2021 MicrosoftとGitHubの連携をMSKKのアーキテクトが解説

CI/CD Conference 2021から、マイクロソフトのアーキテクトによるセッションを紹介する。これは「GitHubのエコシステム-GitHub Actions、CodespacesそしてCopilot」と題されたもので、セッションを担当したのは日本マイクロソフト株式会社のクラウドソリューションアーキテクトである服部佑樹氏だ。

GitHub Actionsを中心にGitHubエコシステムを解説

Microsoft Loves GitHub

40分のセッションのうち前半の20分を「MicrosoftとGitHubの歩み」としてMicrosoftによる買収、GitHub Actionsの開発がGitHub主体からMicrosoftのAzureチームに移ったという辺りを解説した。

Microsoft Loves GitHubを紹介

ここではGitHubとAzure DevOpsが同じチームで開発していることが紹介されており、Ruby on Railsの牙城だったGitHubの開発にMicrosoftが直接タッチしていることを表している。また後半で紹介されるGitHub Actionsについても、Microsoftが開発の主体となっていること、認証機能としてAzure Active Directoryとの連携が進んでいることを示している。

GitHub ActionsのV2はMicrosoftが書き直したと言える

ここではGitHub ActionsのV1とV2について解説を行っているが、V1はMicrosoftが開発したものではないことが明確に記載されており、Microsoftが開発主体となったのはV2からであることを明示している。ちなみにGitHub Actionsの最初のバージョンではワークフローを記述する言語として、HashiCorpが公開しているオープンソースソフトウェア、HCL（HashiCorp Configuration Language）が使われていた。これがV2ではYAMLに置き換わっているのも、Microsoftが開発の主体となったことが影響しているのだろう。

GitHub Actionsは、ソースコードリポジトリの機能だけに特化していたGitHubがデベロッパーのワークフローの領域に切り込んだ形となった製品だ。しかし発表当時は、CI/CDのためのツールとは説明していなかった。この辺りに関してはGitHubのカンファレンスであるGitHub Universeで当時のCTOのJason Warner氏にインタビューした記事を参照されたい。

参考：GitHub Universe開催、ActionsとPackagesの背景にある思想をCTOに訊いた

上記のインタビュー記事以前には「GitHub ActionsはCI/CDツールなのか？」という質問に曖昧に回答していたWarner氏が、GitHub Actionsを「エコシステムの中核」と説明している。それを踏まえた上で服部氏のプレゼンテーションを聞くと、2021年9月の段階でのMicrosoftの志向が見えてくる。それはMicrosoftがGitHub ActionsをCI/CDツールの中核として、VS CodeやブラウザーベースのIDEであるCodespacesに統合する方向で、デベロッパーのエコシステムの押さえていく意思があるということだ。

ブラウザーベースのIDEを統合

ここでは「統合」と書かれているが、Visual Studio CodespacesをGitHub Codespacesとして提供するということで置き換わったと考えるのが妥当だろう。

そしてGitHub Actionsについてロードマップが公開されたことが画期的であるという市場や業界、コミュニティの反応に対して「Azure DevOpsは前からロードマップを公開していた」として、ここではGitHubに対する「上から目線」を感じる内容となった。

Copilotの紹介

人工知能がコードを書いてくれるということで話題となったGitHub Copilotについても「MicrosoftとOpenAIが協力して開発した」ペアプログラミング機能であると紹介した。

ここまでMicrosoftがGitHubの買収以来、やってきたことを説明した形になったが、Copilotの前に説明したGPT-3のAIモデルのライセンス取得に関しては、CI/CDには直接関係のないトピックであり、Microsoftとして人工知能に関して精力的に取り組んでいるという人工知能を使ったCopilotを格付けするための前宣伝といったところだろう。特にCI/CDに関心のある運用担当者にとっては、奇異に感じた瞬間だったかもしれない。

GitHub Actions

CI/CDということでは、ここからやっとGitHub Actionsの解説が始まるということになった。実にここまでの約20分間をMicrosoftとGitHubの関わりに費やしたことになる。

GitHub Actionsの解説

ここではGitHub Actionsの持つ機能を挙げ、CI/CDのワークフローの自動化、YAMLで記述できること、ワークフローの実行ログや監視ができることなどを挙げた。

次のスライドではGitHub Actionsがカバーする領域について説明を行った。

GitHub Actionsがカバーするソフトウェアライフサイクルの領域

ここで興味深いのはテスト～リリース～デプロイという順番となっている点だろう。前回レポートしたトレジャーデータのエンジニアによるセッションでは、リリースとデプロイメントを切り分けており、デプロイメントは機能を本番環境に入れること、リリースはその機能をエンドユーザーに公開することであり、これらを別のものとして扱うためにフィーチャーフラグを使って柔軟に機能のオンオフを実施していた。つまり、デプロイが先でユーザーが使い始めることを可能にするのがリリースという順番だ。

一般的にはデベロッパーが開発を終えてソフトウェアを運用側に渡すことをリリース、運用側が本番環境に配備することをデプロイという順番として、デベロッパーと運用のカバーする領域の境界線として作用するのがリリースとデプロイだ。しかし多数のデベロッパーが絡む巨大なシステムでフィーチャーフラグを利用する場合は、デプロイをして確認してからリリースという順番になるのだろう。

このセッションでは一般の例に従って開発した機能をテストの後にリリース、次に本番環境にデプロイするという順番になっている。エンドユーザーとして実際に開発を行ってきたトレジャーデータと、ベンダーとして機能を解説するソリューションアーキテクトの認識の差が現れたとも言えるだろう。

手動によるトリガーを説明するスライド

GitHub Actionsの特徴的な機能の解説において、あまり注目されていないが使いやすい機能として手動のイベントトリガーを解説したのも興味深い。CI/CDにおいては、極力マニュアルの操作を排除し属人化を避けるのは、インフラストラクチャーの構成などにおいて構成ファイルに書かれているコードだけが常に正しいというSingle source of Truthを実現するためには必須の考え方だ。

マニュアルでの操作は一般的には避けるべき方法論だが、GitHub Actionsにおいては推奨される発想なのかもしれない。

またGitHub Actionsのコード共有についてマーケットプレイスの解説を行った。

GitHub Actionsのコードを公開、共有できるマーケットプレイス

ここからはWebブラウザーベースのIDEであるCodespacesを使ってデモを行うフェーズとなった。ここではCodespacesがデベロッパーの書きたいコードを補完する機能を説明。

Codespacesのデモ

最後にまとめとして、CI/CDがGitHubのエコシステムで身近になる、GitHubの中で開発プロセスのすべてが連携するという将来の構想も含んだ内容を説明してセッションを終えた。

あくまでもGitHubを主体とした開発から運用に至るまでを説明した形だが、実際にはすでに使われているツールや開発スタイルを想定して、そこからの移行についての言及がなかったのは残念と言える。もう少し、企業内のデベロッパーが抱える問題点にフォーカスした内容を聞いてみたかったと思う。

セッションのまとめもMicrosoft Loves GitHub調