Cloud Source Repositories と Container Builder によるサーバーレスでの自動デプロイ

デプロイを自動化する理由には、整合性、安全性、タイムリー性などがあります。ソフトウェアがビジネスにとって重要になればなるほど、これらの重要性も高まります。この記事では、Google Cloud Platform（GCP）ツールを使用すれば自動デプロイを簡単に始められることを示しつつ、デプロイ プロセスを堅牢にするうえで役に立つリソースを紹介します。

たとえば、Google Cloud Functions、Firebase、Google App Engine のいずれかのアプリケーションがあるとします。現時点では、おそらくローカル ワークステーションで gcloud コマンドを使用し、関数やアプリをデプロイすることが多いと思います。では、Google Cloud の Cloud Source Repositories と Cloud Container Builder を利用した軽量のワークフローならどうなるでしょうか。

この単純なパイプラインは、ソース コードが prod ブランチにプッシュされたときに、Cloud Container Builder のビルド トリガーを使って Cloud Functions に関数をデプロイします。

最初のステップは、コードをソース管理システムの管理下に置くことです。すでに GitHub や Bitbucket などのプロバイダーを利用しているのであれば、Cloud Source Repositories にコードをミラーリングするのは簡単でしょう。Cloud Source Repositories は 5 人までのプロジェクト ユーザーには無料で提供されるので、小規模のチームにはうってつけです。

以下ではコマンドラインを用いて説明しますが、こちらのドキュメントにはもっと詳しい説明があります。

まず、リポジトリを作成し、クローンを作ります。

そして、簡単な関数を作りましょう（サードパーティの依存コードがある場合は、package.json をインクルードしてください）。

次に、Container Builder のビルド定義を作ります。

この定義は次のコマンドを実行するのと同じです。

最初のビルドを始める前に、Container Builder 向けにプロジェクトをセットアップしてください。まず、Container Builder API と Cloud Functions API の 2 つの API を有効にします。Container Builder がビルドを行えるようにするには、プロジェクトへのアクセス権を Container Builder に与える必要があります。ビルド プロセスは、これらのビルドに関連づけられたサービス アカウントの認証情報を使います。サービス アカウントのアドレスは {numerical-project-id}@cloudbuild.gserviceaccount.com です。

サービス アカウントには Project Editor という IAM の役割を追加する必要があります。他のリソースのデプロイにもこのプロセスを使う場合は、他の役割が必要になることがあります。

それでは、次のコマンドを実行して、デプロイの構成とパーミッションをテストしてみましょう。

関数は、Cloud Container Builder 経由でデプロイされるようになっています。

ビルド トリガーは簡単に作成できます。リポジトリ、トリガー条件（この場合は prod ブランチへのプッシュ）、実行するビルド（この場合は deploy.yaml で指定されたビルド）を選択してください。

これで、prod ブランチをアップデートし、“master” の最新情報を与え、Cloud Source Repositories にプッシュすれば、関数はデプロイされます。

デプロイが失敗した場合は、ビルド履歴の画面に失敗ビルドとして表示されます。ログを見て何が問題だったのかを調べてください。Cloud Pub/Sub と Cloud Functions を使って、メールやその他の通知方法を設定することもできます。

上述のデプロイ パイプラインは、デプロイの自動化を実証するにあたって単純化された必要最小限のパイプラインです。このプロセスではいずれニーズに合わなくなるときが来ます。たとえば、本番システムを更新する前に、手作業の承認プロセスを入れたくなった場合です。そのようなときは、もっと複雑なワークフローを処理できるオープンソースのデプロイ自動化システム Spinnaker を試してみてください。

これは最初の一歩にすぎません。デプロイの自動化を進める過程で試せるツールやテクニックをいくつか挙げておきます。

• テスト ステップの追加（たとえば npm test）
  
• Cloud Functions ではなく、App Engine アプリのデプロイ（gcloud コマンドを変更するだけです）
  
• ブランチ名に基づいて関数名を変える変数値の置換（たとえば “my-function-dev”）
  
• IDE プラグインやエディタ サポートによる IDE もしくはエディタからのプッシュ ツー デプロイ（一般的なビルド設定ファイルの例はこちらをご覧ください）
  

* この投稿は米国時間 3 月 14 日、Developer Relations の Chris Broadfoot によって投稿されたもの（投稿はこちら）の抄訳です。

- By Chris Broadfoot, Developer Relations