CI/CD Conference 2021 MicrosoftとGitHubの連携をMSKKのアーキテクトが解説
CI/CD Conference 2021から、マイクロソフトのアーキテクトによるセッションを紹介する。これは「GitHubのエコシステム-GitHub Actions、CodespacesそしてCopilot」と題されたもので、セッションを担当したのは日本マイクロソフト株式会社のクラウドソリューションアーキテクトである服部佑樹氏だ。
Microsoft Loves GitHub
40分のセッションのうち前半の20分を「MicrosoftとGitHubの歩み」としてMicrosoftによる買収、GitHub Actionsの開発がGitHub主体からMicrosoftのAzureチームに移ったという辺りを解説した。
ここではGitHubとAzure DevOpsが同じチームで開発していることが紹介されており、Ruby on Railsの牙城だったGitHubの開発にMicrosoftが直接タッチしていることを表している。また後半で紹介されるGitHub Actionsについても、Microsoftが開発の主体となっていること、認証機能としてAzure Active Directoryとの連携が進んでいることを示している。
ここでは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に統合する方向で、デベロッパーのエコシステムの押さえていく意思があるということだ。
ここでは「統合」と書かれているが、Visual Studio CodespacesをGitHub Codespacesとして提供するということで置き換わったと考えるのが妥当だろう。
そしてGitHub Actionsについてロードマップが公開されたことが画期的であるという市場や業界、コミュニティの反応に対して「Azure DevOpsは前からロードマップを公開していた」として、ここではGitHubに対する「上から目線」を感じる内容となった。
人工知能がコードを書いてくれるということで話題となった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の持つ機能を挙げ、CI/CDのワークフローの自動化、YAMLで記述できること、ワークフローの実行ログや監視ができることなどを挙げた。
次のスライドではGitHub Actionsがカバーする領域について説明を行った。
ここで興味深いのはテスト~リリース~デプロイという順番となっている点だろう。前回レポートしたトレジャーデータのエンジニアによるセッションでは、リリースとデプロイメントを切り分けており、デプロイメントは機能を本番環境に入れること、リリースはその機能をエンドユーザーに公開することであり、これらを別のものとして扱うためにフィーチャーフラグを使って柔軟に機能のオンオフを実施していた。つまり、デプロイが先でユーザーが使い始めることを可能にするのがリリースという順番だ。
一般的にはデベロッパーが開発を終えてソフトウェアを運用側に渡すことをリリース、運用側が本番環境に配備することをデプロイという順番として、デベロッパーと運用のカバーする領域の境界線として作用するのがリリースとデプロイだ。しかし多数のデベロッパーが絡む巨大なシステムでフィーチャーフラグを利用する場合は、デプロイをして確認してからリリースという順番になるのだろう。
このセッションでは一般の例に従って開発した機能をテストの後にリリース、次に本番環境にデプロイするという順番になっている。エンドユーザーとして実際に開発を行ってきたトレジャーデータと、ベンダーとして機能を解説するソリューションアーキテクトの認識の差が現れたとも言えるだろう。
GitHub Actionsの特徴的な機能の解説において、あまり注目されていないが使いやすい機能として手動のイベントトリガーを解説したのも興味深い。CI/CDにおいては、極力マニュアルの操作を排除し属人化を避けるのは、インフラストラクチャーの構成などにおいて構成ファイルに書かれているコードだけが常に正しいというSingle source of Truthを実現するためには必須の考え方だ。
マニュアルでの操作は一般的には避けるべき方法論だが、GitHub Actionsにおいては推奨される発想なのかもしれない。
またGitHub Actionsのコード共有についてマーケットプレイスの解説を行った。
ここからはWebブラウザーベースのIDEであるCodespacesを使ってデモを行うフェーズとなった。ここではCodespacesがデベロッパーの書きたいコードを補完する機能を説明。
最後にまとめとして、CI/CDがGitHubのエコシステムで身近になる、GitHubの中で開発プロセスのすべてが連携するという将来の構想も含んだ内容を説明してセッションを終えた。
あくまでもGitHubを主体とした開発から運用に至るまでを説明した形だが、実際にはすでに使われているツールや開発スタイルを想定して、そこからの移行についての言及がなかったのは残念と言える。もう少し、企業内のデベロッパーが抱える問題点にフォーカスした内容を聞いてみたかったと思う。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- GitHub Universe 2022、キーノートで見せた多角的にデベロッパーを支援する機能とは?
- GitHub Universe開催、ActionsとPackagesの背景にある思想をCTOに訊いた
- GitHub Universe開催。ワークフローを実現するActionsなど多くの新機能を発表
- 米GitHub Kyle Daigle氏インタビュー:セキュリティからSBOM、コーディング支援まで、開発者に恩恵をもたらすGitHubの最新アップデートとは
- GitHub Universeで製品担当VPが語ったGitHub Actionsのインパクト
- GitHub Universe開催。βユーザーたちが語るActions導入の容易さ
- GitHub Universe 2023で、GitHubのCSO、Mike Hanley氏にインタビュー
- CI/CD Conferenceレポート トレジャーデータのCI/CDのポイントはリリースリスクの最小化
- 写真で見るGitHub Universe 2023、狭いスペースを最大限に使った展示ブースなどを紹介
- CI/CD Conference 2023から、コストをかけずにGitHub Actionsを実行するノウハウを紹介