はじめに
この記事はCircleCI Advent Calendar 2020 - Qiitaの3日目の記事です。
自分のチームではLambdaを使って、バッチなどを動かしています。
LambdaはAWS SAMで管理していましたが、デプロイを自動化しておらず、手動で反映していました。
そんな状況をCircleCIを使って改善した話をしていきます。
改善前
改善前のデプロイフローが下記になります。
このデプロイは下記のような課題を抱えていました。
- ローカル上で依存解決して実行しないといけない
- 変更セットをレビュアーが隣で確認しないといけない
このような作業を行っているため、環境変数の書き換えがミスがあったりし、ダブルチェックに緊張感がある状態でした。
開発中はこの状態で進めていましたが、本番運用を始める前にはなんとかしたいという思いがあり、自動化の構築を始めました。
AWS SAMとLambdaという構成なので、AWS Code系のサービスにするか迷いましたが、下記2点からCircleCIを選定しました。
- 他のシステムでCircleCIを使っており、使い慣れている
- ツールの統一
改善後
改善後のデプロイフローは下記になります。
GitHubでリリースタグを作成したら、CircleCIがデプロイを動かす仕組みです。
意識したポイントをいくつか紹介していきます。
意識したポイント
依存解決をできるようにする
Node.jsを使っていたのですが、元々CDを想定しておらず、CircleCI化するに当たって対応が必要でした。
具体的には下記のように、アプリと環境変数のディレクトリに区分がなく、アプリが入っているディレクトリ内ごとに package.json が入っていました。
勿論monorepoにはなっていません。
├── アプリ1
└── package.json
├── アプリ2
└── package.json
└── 環境変数のディレクトリ
ここは下記のようにディレクトリ構造の変更と、シェルでディレクトリに cd してアップデートすることで解決しました。
├── apps
└── アプリ1
└── package.json
└── アプリ2
└── package.json
└── 環境変数のディレクトリ
monorepoも検討しましたが、時間の都合でシェルで解決することにしました。
変更セットを確認できるようにする
CloudFormationで --no-execute-changeset を付け加えると、事前に変更セットの確認ができます。
それは sam-cli でも同じでしたので、 --no-execute-changeset を事前に変更セットを見れるようにしました。
これにより、レビュアーに何が変更されるかわかりやすくなり、デプロイ承認のドキドキを減らすことができました。
sam deploy (略) --no-fail-on-empty-changeset
デプロイはワークフローを組んでおり、approvalの前に実行するようにしています。
これにより、承認前に変更セットを確認することができました。
ここは今回の改善で一番うまくできたと思っています。
まとめ
いくつかの工夫を取り入れ、Lambdaのデプロイを改善することができました。
どなたかの参考になれば幸いです。