他者が書いたコードをリリースする: Next 2020 のデモを大規模に配信

※この投稿は米国時間 2020 年 12 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

今年は、最大の年次カンファレンスを対面で開催することが叶わず、すべてをオンラインに移行しました。でも大丈夫。Google はウェブサイトでどうするか熟知しています。デモもアプリもお任せください！

ところが結果的には、いくつかの問題が発生しました。お好きなドリンクを片手に、そのいきさつをお読みください。

Cloud Next 2020 の準備を進めていた春頃、Terry Ryan（@tpryan）と Google Cloud マーケティング チームは、完全にオンライン開催となった Next カンファレンスがどのようになるかについて相談していました。Next の重要な部分であるデモは、Google のプロダクト チームにとっては新しいプロダクトと機能を大勢の参加者に披露する機会です。こうしたデモはたいていインタラクティブで人目を引き、楽しみと学びの両方を提供できるよう作られています。参加者にデモの説明をして、複雑な部分を解説するスタッフもデモの一部です。対面でもやるべきことが数多くあるのに、これを完全にオンライン化するとなるとさらなる困難が伴います。

これらすべてを実現するために、Terry がチームを先導し、27 件のデモに取り組んで、夏の公開に間に合うようにプロジェクトのビルド、テスト、Next OnAir サイトへのデプロイを監督しました。以下では、その過程から学んだことと、Terry がどのようにこの仕事を成し遂げたかをご紹介します。

デモごとに異なる Google チーム（またはエージェンシー）が担当し、それぞれがコーディングやビジュアル開発を行いました。各チームがアプリケーションを所有して、自分たちにとって使いやすいまたはユースケースに最適なフロントエンド フレームワークを使用しました。チームには柔軟な選択肢が与えられ、最終的に Google がホストするウェブアプリを配布すればいい状態でした。すべてのデモは App Engine で提供されました。App Engine を選んだのは、使いやすく、素早いスケールアップやスケールダウンが可能で、組み込みのセキュリティ機能が備わっているためです。

次に、実装に進みました。実装では、デザイナーが想定したものをデベロッパー チームが作り出します。ここで Google 側に、最初の課題が発生しました:

1. どのような方法でエージェンシーからコードを入手するか？

以前は、すべてのデモが準備を整えて展示会場で問題なく提供できることに焦点を合わせていました。そのためにはメール、ZIP ファイル、GitHub リポジトリ、ドライブのフォルダから伝書鳩まで、あらゆる形式とコミュニケーション手段を使うことが可能でしたが、今回は、これが成り立たないことはわかっていました。そこで、Terry はデモごとに GitHub リポジトリをセットアップしました。そこにエージェンシーがコードを push して、すべてのデモのコードを単一のコントロール プレーン（およびロギング システム）で管理できるようにしたのです。これだけでも大きな改善となり、管理が非常に容易になりました。

さらに、あらゆるデモが GitHub を経由するので、既存の継続的インテグレーション ツールと継続的デプロイ（CICD）ツールを使用して自動化が可能です。自動化がなければ、Terry はすべてのステップにおいて各ビルドやデモを手動で push して公開する羽目になるところでした。楽しみのない手作業です。

それでは、次は変更を加える作業についてです。

2. コードが変更されたとき、本番環境のデモをどのように更新するか？

Cloud Build と GitHub 間の強力な統合のおかげで、GitHub でマスター ブランチが（デモを作成しているチームによって）更新されるたびに、新しいビルドをトリガーできました。さらに新しいビルドが自動的に App Engine にデプロイされるようにして、作業をスピードアップできました。

Google がホストするすべてのコードは、厳しいセキュリティとプライバシー審査を通過する必要があります。これはあらゆるケースに当てはまりますが、コードがサードパーティによって作成された場合はさらに重要です。ところが、こうしたプロジェクトは、関係者からのリクエストに対応するため、土壇場になって緊急の更新が必要になることが多々あります。

3. どのようにデプロイを制御して、審査されたコードのみが push されるようにしたか？

ほとんどの場合、サードパーティのコードは、Google がホストするサイトに Google 社員が push しなければなりません。そのため、Terry が単独でその役目を果たす必要がありました。Terry は、GitHub ツールを使って pull リクエストが承認なしに統合されるのを防ぐことができました。自分自身を必須の審査担当者として設定してから、コードを承認して App Engine アプリの本番環境バージョンへの push をトリガーしたのです。これで、あらゆるコードは本番環境に上がる前に、必ず Terry による迅速な認可を得ることになりました。

このシステムを用意した結果、Terry は納期が近づくにつれて急増する更新を管理できるようになり、すべてスマートフォンで用が済みました。しかし、さまざまなことが同時に発生しているなかで、また別の課題がありました。

4. こうしたシステムを継続的に進めていくには、どうすればよいか？

対応策として、Terry はスクリプトを作成しました。数多くのスクリプトを用意したのです。そしてスクリプトを使って、個々のサービスとサービス アカウントをアクティブ化しました。スクリプトを使って各プロジェクトで Cloud Build を App Engine 管理者としてバインドし、GitHub に共有する前に最初の Git commit を行い、さらに Cloud Build パイプラインに機能を追加して、ビルドが完了したかどうか報告されるようにしました。

すべてのプロジェクトとアプリの保護については？

各プロジェクトに Identity-Aware Proxy を設定して、アプリケーションへのアクセスを制限するスクリプトを使用しました。GitHub 側では、リポジトリにユーザーを追加してマスター ブランチをロックダウンするスクリプトです。

これを使って、デフォルト プロジェクトを設定して Cloud Build を開始します。

[gcloud のデフォルト プロジェクトを設定して、Cloud Build セッションを開始する]

ここでは、使用する必要がある必須の API を確立し、セキュリティのためにアクセス ポリシーを追加して、最初の commit を行って GitHub プロジェクトを開始します。

[デモを実行するのに必要な API を起動して、GitHub プロジェクトを初期化する]

次に、ビルドが完了したのかエラーが発生したのかを Terry が知ることができるように、メールツールを手に入れる必要があります。

[メール送信ツールを Cloud Functions の関数にデプロイして、ビルドの完了または問題を通知する]

ここではまだ IP を一般公開しないので、Identity-Aware Proxy を追加してウェブアプリのアクセスを制御し、適切なユーザーのみに限定します。

[IAP を設定して破棄し、組織のログイン済みユーザーだけがアプリを表示できるようにする]

ディレクトリが確立されたので、テンプレートを使うことで、手動でファイルを作成する時間を省けます。

[プロジェクトのディレクトリを設定して、大変なそこにテンプレートをコピーするスクリプト]

すべてが動き出したら、次に進みます:

5. どのようにして、すべての作業を追跡するか？

どうすると思いますか？さらにスクリプトを使い、通知も活用します。Terry は全体の統計データを収集するスクリプトを作成しました。これで、281 件の commit、312 件の審査対象のコード、公開済みの 27 件のデモがあることが明らかになりました。適切な通知のセットを設定することで、新しいコードが push されたとき迅速に対応でき、Terry は急な変更にも確実に対処できました。外部のパートナーと迅速に共同作業を進めるには、スピードが重要になります。こうしたプロジェクトでは、コードが承認されてからアプリケーションが本番環境に push されるまでの平均時間は 5 分です。新しいコードの push が失敗すると、Cloud Build からの通知が Terry と開発チームに届き、問題を知らせてくれます。

このプロジェクトには、多くの流動的な要素、アクセスと認可の課題、リモートでの共同作業の難点などがありました。それでもなお、巧みな工程設計（および膨大なスクリプト）のおかげで、Terry はすべての作業を間に合わせて大イベントで公開することができました。お疲れさまでした。

-Google Cloud、Cloud デベロッパー アドボケイト Max Saltonstall