アーカイブ動画
「GitHub Codespaces」の活用で多様な開発環境を統一化
株式会社電通国際情報サービス
Xイノベーション本部
ソフトウェアデザインセンター 山下 剛氏
今回登壇した山下剛氏は、2021年にISIDに入社。前職の大手メーカーではソフトウェア開発関連の研究機関に従事し、組み込みシステムやクラウド関連システムなどの開発に関する研究を行ってきた。現在は、GitHubやCI/CD関連のツールの紹介など、開発効率に関する業務推進を担っている。
まず山下氏は、新型コロナウィルスの台頭・蔓延により、多くの企業でリモートワークが導入されたことで開発環境が多様化したことに言及した。
「リモートデスクトップ」「開発環境もリソースも自宅PCに」「VPN接続」など、リモートワークの開発環境例を挙げ、現在のようにメンバーによって開発環境が異なる状況は快適ではない理由を次のように述べた。
「例えば開発用のPCが会社にある場合、そのPCにフリーズなどのトラブルが発生しても、会社には対応できる情シスのメンバーなどが不在だと考えられます。そのため、すぐに復旧することが難しく、開発が一時的に停止してしまうからです」（山下氏）
利用しているインターネット回線がWi-Fiか有線なのか、速度はどの程度なのかなど、ネットワーク環境もリモートワークでは異なると指摘。改めて、リモートワークでは開発環境が多様化していることを強調した。
新たなメンバーが加わった際にも、一同にオフィスに集まっていた以前とは異なり、セットアップに関するコストがかかってしまうケースが増えている。新しいメンバーと設定に関するオンボーディングを行っているが、実際に業務が始まってからも手順書どおりうまくいかないことも多い。
だが、これらの課題はリモートワークに限ったことではなく、フィジカルで業務を行っていた際から発生していたと山下氏は指摘する。リモートワークが浸透したことで顕在化しただけであり、多様な開発環境への対処が必要であることや、自らが望む開発環境を次のように話した。
「手順書の理解の違いなど関係なく、誰が起動しても同じ環境が保証されている。故障が発生しない、したとしてもすぐに新しい環境が手に入るような開発環境です」（山下氏）
そして山下氏のこのような願いを実現するのが、「GitHub Codespacesである」と続けた。
GitHub Codespacesはその名からもわかるとおり、GitHubが提供するブラウザベースの統合開発環境（Integrated Development Environment／IDE）サービスである。開発環境はクラウド上の仮想マシンに構築され、ブラウザを通して開発業務を行うことができる。そのため先述したように、自宅・会社どちらにも開発用マシンを設置する必要はない。
山下氏は実際のUIを「Visual Studio Code（以下、VSCode）がブラウザで起動しているような感覚です」と、紹介した。
GitHub Codespacesはクラウド上に構築されているため、故障しても新しい環境がすぐに手に入る。GitHubがダウンする可能性も相当低いと考えられる。さらにDev Containerを合わせて導入することで開発環境がコンテナで統一でき、開発環境の構築手順までコンテナに閉じ込めることができる。その結果、誰が起動しても同一の環境が手に入るという。Dev Containerに関しては、後半で改めて解説する。
GitHub Codespacesは、GitHubのインフラ上で起動する仮想マシンの中に、いくつかコンテナが同じく起動している。それらコンテナにアクセスすることで、開発環境を起動することができる。
起動方法は至って簡単だ。GitHubの画面「Code」タブをクリックし、「Codespacesを作成」をクリックするだけである。しばらくすると、GitHub Codespacesが立ち上がる。また、VSCodeやJetBrains Gatewayといった他のIDE関連のツールからも起動できる。山下氏はそれぞれのツールでの起動方法についても丁寧に紹介した。
ブラウザ経由で利用できるため、iPadでの利用も可能だ。起動した時点で開発向けの設定が行われていたり、ソースコードのcloneが実施されている。GitHubへのアクセス設定が行われているなど、GitHubとの親和性が高いところが、特におすすめポイントだという。
一方で、Linuxで動作するものしか開発できないため、iOSやAndroid、Windows関連アプリの開発は難しいと補足した。
課金体系は、GitHub Codespacesを起動している際に発生する「コンピューティング時間」だ。仮想マシンが使用する「ストレージ容量」に応じた2種類がある。ただし、ストレージ利用料は起動していない間も料金が発生するなどの注意点があるため、実際に利用を考えている人は公式ページで改めて確認することが勧められた。
山下氏は実際に先の手順に従い、GitHubからCodespacesを起動するデモも行った。「ブラウザ上でVSCodeを使っているような感覚です」と述べながら、実際にコマンドを操作してみせた。
リポジトリのソースコードがcloneされていること。ホストではなく専用の仮想マシンで、つまり独立した環境が構築され、その上で動いていることがわかることを示した。また、ローカルのVSCodeとの接続事例も示すと共に、「Hello World!」と表示してみせ、実際に使える環境であることを示した。
このように、ブラウザ経由のみで利用することもできるが、拡張機能を使いたい場合には、ローカルで動作することも可能だという。
続いて山下氏は、JetBrains Gatewayからもコネクト機能を使い、GitHub Codespacesに接続するデモを示した。先と同じく環境がcloneされていることや、仮想マシンがコンテナ内で稼働していることがわかった。
ブランチを指定して起動することもできる。例えば、プルリクエストがあった際に同機能を使えば、簡単に指定箇所のブランチの開発環境をCodespacesで起動できるので、レビューを行うといった使い方もできるのだ。
実際、デモでは指定されたブランチがcloneされた状態で、Codespaces上で起動していることが紹介された。デバック依頼があった際などにも、別の開発に従事していながらも簡単に着手できる、と具体的な活用例も挙げられた。
山下氏が「ぜひ、紹介したい」と強調したのが、テンプレート機能だ。Ruby on RailsやReactなど、各言語の雛形が収納されている機能の中でも「Blank」が特に便利だという。
Blank（空）との名称ではあるが、実際にはいろいろなツールが入っているからだ。具体的には、Python3.0、Java17、Ruby、Node.jsなどである。Blankテンプレートの効果的な利用方法についても、山下氏は次のように付け加えた。
「簡単に新しいファイルを作り、開発環境を起動することができます。これから何か新しく開発をはじめるとき、サンドボックス的な環境が欲しいときに効果的だと考えています。
Blank上でさまざまなファイルを作り、試行錯誤を行う。その上で最終的に決まったファイルをGitHubにプッシュするなど、便利に使うことができます」（山下氏）
Dev Containerを使えば、簡便に統一環境が構築できる
続いては、Dev Containerを使って開発環境を統一する方法が紹介された。Dev ContainerとはVSCodeの機能であり、コンテナをリモート接続の開発環境として利用することが可能になる。
GitHub Codespacesを導入すれば、アクセス環境などに依存しない開発環境が手に入ると紹介してきた。しかし、メンバーのスキルなどにより、実際の開発環境には差分があると、山下氏は指摘する。
しかしDev Containerを利用すれば、その差分も埋めることができる。どんなに構築に手間がかかる環境であっても、その内容をDockerfileに記述しておくことで、コンテナ内に閉じ込めることができるからだ。
開発の流れも従来と変わらない。リモートワークしているメンバーは、ローカル環境でVSCodeを使いソースコードを記述する。すると、そのソースコードがDev Containerに同期される。実行においても、ローカルで行ったものがDev Container内で実行される。動作確認も同様で、普段使っているブラウザで確認することができる。
利用に際してはVSCodeの画面からだけではなく、GitHubの画面からも設定が可能だ。山下氏は設定の詳細が記載された、Dev ContainerのJSONファイルの中身も紹介した。
devcontainer.jsonは、一般的なJSONファイルであり、起動するコンテナのイメージ名、VSCodeの拡張機能、コンテナに追加する機能（feature）などの指定が行える。
feature機能とはDev Containerに機能を追加する機能だ。Dev Container導入時にGUIもしくは、JSONファイルに記述することで、実行される。
さらに、template機能も紹介された。よく使う環境の構成を予め組み合わせ、テンプレートとしておく機能だ。
Dev Containerのデモも行われた。Dev Containerの設定から起動までのデモである。GitHub Codespacesのテンプレートで紹介したように、Dev Containerにもシンプルなサンプルが用意されている。
その中のひとつを使い、feature機能として、コンテナ内からDockerを利用可能にする「Docker Outside of Docker」、AWSをコマンドラインで利用するための「AWS CLI」、そして「Node」と、3つのfeature機能を指定している。
設定が終わった後はGitHub Codespacesを起動。feature機能をインストールしている画面を映し、同フローは保存しておくことで次回から省くことも可能だと説明した。さらに、feature機能を使わずとも、自らの手でAWS CLIをインストールし、環境を構築することも可能である。
山下氏は最後に、実際にGitHub Codespacesを導入した事例を2つ紹介した。1つ目の事例は、Mac、Windowsなど、複数の異なる環境下で開発が進んでいるプロジェクトだ。
GitHub Codespacesを導入したことで、まさに紹介してきたように全メンバーが確実に、同じ開発環境下で、業務に臨めるようになった。また、AWSのアクセス時に使う機密情報なども、GitHub Codespacesが隠蔽してくれるため、セキュリティ面でのメリットも大きかったという。
こちらの事例プロジェクトには山下氏も参加しており、まさにGitHub Codespacesの恩恵を受けたことを、次のように語っている。
「アドバイザーとして参加していたのですが、メンバーから相談されたその場で開発環境を構築することができたため、すぐに不具合箇所が共有でき、コード書き換えのアドバイスを迅速に行うことができました」（山下氏）
2つ目は、Python2の環境をPython3に移行するプロジェクトだ。長く続いたプロジェクトであったため、従来のPython2の環境を構築しようと思っても、手順書などが古く、参考にならなかった。また、同じPC内に両環境を構築することはトラブルが発生する可能性が高いため、避けたかった。
しかしDev Containerであれば、閉じ込めた環境を構築することは比較的容易だ。実際、そのような環境を構築。プロジェクトの全メンバーへの展開も同じく容易だったという。
最後に山下氏は以下のように述べ、セッションを終えた。
「Dev ContainerとPythonの環境構築については、自社のテックブログに参考となる記事があるので、気になる方はぜひご覧ください」（山下氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後はイベントを聴講した参加者からの質問に、山下氏が回答した。
Q．GitHub Codespacesで作業を停止する方法は？
ブラウザを閉じれば、自動的に停止されます。
Q．ローカルPCのスペックとの関連性は？
多くの処理がクラウド上のマシンで行われているため、VSCodeが起動できないといったほどのロースペックでなければ、ほとんど気になりません。具体的にはメモリ4GB程度のマシンで十分です。立ち上げ時間においてもロースペックでもハイスペックマシンでも基本的には変わりません。
Q．ブランチや特定のリポジトリから起動するに際しての条件などはあるか？
基本的にはありませんが、個人所有のリポジトリを他の人が開くのは制限をかけることができます。例えば、GitHub Organizationを導入している企業内では、個人のCodespacesは起動できないようになっています。
Q．コードレビューの効率を高めるためのGitHub Codespacesの利用方法・ポイントは？
統制が取れているVSCodeの拡張、lint環境の構築が実現可能になるので、より効率的にコードレビューが行えるようになると考えています。
Q．GitHub Codespacesを適切に活用するためのトレーニングや教育は必要か？
GitHub Codespacesに関しては、VSCodeが使える人であれば不要だと思います。一方、Dev Containerを十分に使いこなすためには、コンテナに関する知識が必要となってきます。
Q．GitHub ActionsでCIを動作しているCodespacesのテンプレートなどで同等の環境を構築できるか？
Codespacesの機能では難しいと思います。VSCodeが必要なく、Dev Container環境だけを起動する機能を備えているDev ContainerのCLIというツールを使えば可能だと思います。
Q．会社規模で開発環境をローカルからGitHub Codespacesに移行するメリット・デメリットは？
実際のマシンを保有するコストがかなり軽減できます。スペックも自由に変えられ、数の上下も容易なため、管理コストも大幅に減るでしょう。一方、リアルなマシンの場合は減価償却対象となりますが、GitHub Codespacesの場合は毎月費用を支払っていくといった違いもあります。
Q．ローカルPCと同等金額が発生すると、費用が二重負担になるのではないか？
個人的な考えですが、二重負担となる可能性は確かにあるでしょう。一方で、ローカルPCは買い替えや更新の手間が必要ですが、GitHub Codespacesであれば必要ありません。今回紹介したメリットも考慮すると、GitHub Codespacesの方が便利だと考えています。
Q．ISIDは全社的にGitHub Codespacesを利用していく方針なのか？
全員が利用するとは考えていません。Androidの開発メンバーもいますし、Javaの開発においては不安があるからです。希望するメンバーに使ってもらう。あるいは、新しいPCを購入する際や、新しいメンバーが入ったときなどに、GitHub Codespacesの導入を検討してもらうといったスタンスです。
株式会社電通国際情報サービス
https://www.isid.co.jp/
株式会社電通国際情報サービスの採用情報
https://career.isid.co.jp/
関連するイベント
