自動的にデプロイ
どんなアプリケーションであれ、
世の中に価値を提供するためには、デプロイメントを行う必要があります。
そして、
アプリケーションを一度作ったら終わりということは稀で、
継続的に、かつ頻繁に改修を加えていくことが多いので、
必然的にデプロイも継続的に、かつ頻繁に行うことになります。
いわゆるCI/CDですね。
GCPが提供するフルマネージドなCI/CDサービスがCloud Buildになります。
[blogcard url=”https://cloud.google.com/cloud-build/?hl=ja”]
Cloud Build
CI/CDの処理をフルマネージドな環境で実現できるという点でも魅力的ですが、
このCloud Build、毎日120分以内であれば、無料で使えます。
また、今までデプロイの話をしてきましたが、
名前の通りDockerコンテナのビルドなどもできます。
デフォルトで用意されているDockerイメージを使用してステップ（Cloud Buildでは個々のタスクをステップと呼びます）を定義することや、
自前のDockerイメージを使ってステップを定義することができるので、基本的になんでもできます。
GCP上のサービスと連携する上で、GCPの権限管理のシステムであるIAMとも連携できるのも嬉しいポイントです。
そして、現時点(2018/08)で、
- GitHub
- BitBucket
- Cloud Source Repositories
のPushをフックして、起動させることができます。
デプロイパイプラインの自動化
そこで今回から数回に分けて、
Slack上でmasterブランチにマージするとCloud BuildでGAE/Goをデプロイ
というパイプラインを組んでみたいと思います。
登場人物は
- Slack
- BitBucket
- Cloud Source Repositories
- Cloud Build
- GAE/Go
となります。
構成図：
Slack上のBotのMergeボタンを押す(1)と、
BitBucketのmasterブランチにマージされる(2)と同時に、
Cloud Source Repositoriesにミラーリング(3)され、
Cloud Buildが起動(4)してビルドを行い(5)、
GAE/Goにソースがデプロイ(6)される
※()内数字は構成図内の処理番号に対応
といった流れになります。
なお、
BitBucketとCloud Source Repositoryと両方使っている理由は以下になります。
- BitBucketにはプルリクエストのマージをSlack上で行うSlackBotが提供されています。
- Cloud Buildをgcloudコマンドから直接実行する際には、Cloud Source Repositoryにソースがあった方が都合が良いからです。
終わりに
というわけで、
次回以降、Slack上でマージしたらGAE/Goに自動でデプロイ!の仕組みを作っていこうと思います。
