2018年12月19日水曜日
circleciでビルドしたあとにnetlifyへデプロイしてみた
こんにちは!
シタテルでエンジニアをしている建山です。
主に工場向けのマイオペというシステムの開発を行っています。
マイオペでは、インフラとして本番、ステージング、開発、feature環境を用意して開発していますが、新機能をテストする環境としてfeature環境を使用しています。
そして、feature環境にnetlifyというサービスを使用しています。
netlifyとは
Netlifyは静的なサイトをすばやく提供できるWebサービスです。フロントエンドのビルド、デプロイ、ホスティングのすべてを行ってくれます。
今回の概要
デプロイの流れとしては、github -> circleci ➔ netlify
となっています。netlifyにはビルドする機能が備わっているので、github -> netlify
が可能なのですが、マイオペでは、ビルドの際にjavaを使用していて、netlifyのビルドで対応されていないので、circleciでビルドを行ったあと、netlifyにデプロイすることにしました。
今回の前提
- ビルドはcircleciでおこなう
- ビルドが終わったものをnetlifyにデプロイする
- 指定のサイトURLにデプロイする
「それ、netlifyじゃなくてAWS S3でよくない?」っていうツッコミはあるとおもいますが、まずは使ってみたということでご容赦ください。
方法
事前にnetlifyにサイトを作成してください。(画面やcliを使って作成できます)
netlify cliをインストールします。今回は、プロジェクトにnpm install --save netlify-cli
でいれました。circleciのconfig.ymlのstepsにnpm install -g netlify-cli
でインストールしてもいいと思います。
次に、circleciのconfig.ymlでデプロイの設定をします。
こんな感じで、インストールされたnetlify cliを使って、デプロイします。
<<他省略>>
# run deploy
- run:
name: deploy
command: |
if [[ "$CIRCLE_BRANCH" =~ ^.*-netlify.* ]]; then
node_modules/netlify-cli/bin/cli.js deploy --site-id $NETLIFY_SITE_ID -p ${SC_DIR}/ --access-token $NETLIFY_ACCESS_TOKEN
fi
${SC_DIR}
にはデプロイしたいディレクトリをいれてください。$NETLIFY_SITE_ID
と $NETLIFY_ACCESS_TOKEN
はcircleciの環境変数にセットしてお使い頂いたほうがいいかと思います。
上の例だと、ブランチ名に"-netlify"が含まれているとnetlifyにデプロイされるようにしています。
実際には、利用状況にあわせてカスタマイズしてください。
たとえば、"abcd-netlify"というブランチでgithubにpushすると、
デプロイされます!
今回は同じURLにデプロイしていますが、デプロイのたびに違うサイトURLを発行してデプロイもできるようです。
netlifyの中で、ビルドもいろいろできるようになっているので、今回のように限定的な使い方ではなく、もっと活用できると思います。
とりあえず使ってみましたということで、またいい感じのCI/CDを実現できたら紹介します!
詳しくは公式ドキュメントをご覧ください。https://www.netlify.com/docs/
2018年11月14日水曜日
リリース作業を少し楽にした開発(Slack+Lambda+Golang)
こんにちは、シタテルの鶴巻です。
devops&インフラ担当です。
シタテルのプロダクトのリリース作業を少し楽にするために、
Slack+Lambda+Golangを用いて開発した話をします。
リリースの流れ
シタテルでは、GitフローやGitHubフローを採用しています。
また、本番環境へのデプロイは、以下の流れで実施しています。
- developブランチからreleaseブランチを作成
- ステージング環境でreleaseブランチをデプロイ&動作確認
- 本番環境にデプロイ
ちなみに、1.でreleaseブランチを作成すると、CircleCIによって2.のステージング環境へのデプロイは自動で行われます。
地味に面倒なリリース作業
ステージング環境へのデプロイは自動化されているとはいえ、小さな手作業が合間に発生し、地味に面倒でした。
具体的には以下のような作業です。
- developブランチからreleaseブランチの作成
- ローカルPCでdevelopブランチを最新の状態にpullして、releaseブランチ作成してGitHubにpush
- releaseブランチのプルリクエスト作成
- GitHubのUIをポチポチ
- リリースタグの作成
- 前回のリリース以降でマージされたプルリクエストを見て、リリース内容を記述
手作業はSlackからコマンドを叩くだけにしました
Slackから以下のコマンドを叩くだけで、地味に面倒くさかった作業を自動で行うようにしました。
/release <repository> <release branch>
実際には、以下の内容を実施するGolangプログラムをLambdaで実行しています。
- 対象のリポジトリをクローンし、developブランチからreleaseブランチを作成し、GitHubにpush
- releaseブランチのプルリクエストを作成
- 前回のリリース以降にマージされたプルリクエストのタイトルのリストを記述したリリースタグのドラフトを作成
構成
Slack -> API Gateway -> Lambda01(同期) -> Lambda02(非同期) -> GitHub
- Slackからコマンドを叩くと、Lambda01にリクエストを送信します。
- Lambda01は、Lambda02に対象レポジトリとブランチ名を付与してリクエストを送信します。
- Lambda02で作業を実行します。
Lambdaを2つ使用している理由
Slackはリクエスト送信後3秒でタイムアウトするためです。
実行したいプログラムは3秒以上かかるため、実際の作業は非同期で実施する必要がありました。
そのため、Lambda01はLambda02に処理を投げて、Slackに200を返し、実際の処理はLambda02で実施します。
Lambda01はLambda02を非同期実行で呼び出すので、リクエストをキューに入れた後は、Lambda01は関数を終了することができます。
Lambdaの呼び出しタイプ(同期・非同期)
Lambdaは、呼び出しタイプ(InvocationType)を指定することで、同期実行や非同期実行を選択することができます。
例:InvocationTypeで"Event"を指定することで、非同期実行でLambdaを呼び出せます。
input := &lambda.InvokeInput{
FunctionName: aws.String("xxxx"),
Payload: jsonBytes,
InvocationType: aws.String("Event"),
}
※同期実行は"RequestResponse"を指定します
今回使用したGitHub操作のためのGoライブラリ
- go-git https://github.com/src-d/go-git
- インメモリでgitクローンするために使用
- go-github https://github.com/google/go-github
- google製
- プルリク作成やリリースタグ作成に使用
その他ハマったポイント
- APIGatewayの統合リクエストのマッピングテンプレートを使いこなせず。デバッグのやり方もわからず、使うのを諦めました。
まとめ
- 少しの手間が自動化されるだけで、すごく楽になります。これからももっとやっていきたいです。
- GitHub操作のライブラリはとても便利でした。
- シタテルのサービスはRails + vue.jsが主ですが、自分の好きなGo言語を使えたので楽しかったです。