はじめに
この記事はCircleCI Advent Calendar 2020の24日目の記事です。
CircleCIでカスタマーサクセスをしている鈴木と申します。
CircleCIには、ワークフローを一時停止し、手動承認のジョブを経て、ワークフローを再開する機能があります。この承認ジョブの機能を利用することで、他のチームや責任者が承認したうえで本番環境へのデプロイを行うといったことが可能です。
承認ジョブの承認を実行するApproveボタンはCircleCIのUIで以下のように表示されます。
この機能にはそのリポジトリのWrite権限を持っているCircleCIユーザーなら誰でもこのApproveボタンを押すことができるという大きな注意点があります。
誰にでも承認できてしまうのでは利用にふさわしくないという場面もあるでしょうが、承認ボタンを特定のユーザーにのみ表示させる方法はありません。そこで、特定のユーザーが承認した場合はワークフローの処理が継続され、それ以外のユーザーが承認した場合には処理が失敗するという制御によってこの問題を回避します。この方法ではGitHub OrganizationのTeamsと、CircleCIのコンテキスト（Context）という機能を利用します。
※ そのため、BitbucketでCircleCIを利用している場合には適用できません。(T T)
GitHub上で公開しているサンプルのリポジトリとともに以下の説明をご参考ください。
GitHub OrganizationでTeamsを設定する
GitHub OrganizationでTeamsを作成する方法の説明は割愛します。今回のサンプルではAdminというTeamを作成し、そこに承認者としてふさわしいメンバーを登録しています。
コンテキストを設定する
CircleCIのコンテキストは、Organizartion内の複数のプロジェクト（リポジトリ）で共通して利用する環境変数を登録する機能です。コンテキストの設定画面はCircleCIのサイドメニューにあるOrganization Settingsをクリックすると表示できます。
今回のサンプルでは以下の画面のようにapproversという名前のコンテキストを作成しました。
コンテキストの一覧画面にSecurityという項目が見えますが、作成したばかりのapproversにはAll Membersと表示されています。これはOrganizartion内のCirlceCIユーザーであれば誰でもこのコンテキストを利用することができることを意味します。（のちほど消しましょう。）
リンクになっているコンテキスト名をクリックすると以下の画面に遷移します。
↑この画面では、Security Groupの設定と環境変数(Environment Variables)の登録を行うことができます。今回のサンプルでは環境変数は必要ないので空のまま進め、Security Groupの設定を見ていきます。
Add Security Groupのボタンをクリックすると以下の画面が表示されます。
GitHub OrganizationのTeam名が一覧に表示されるので、ふさわしいグループを選択します。今回のサンプルでは事前に設定したAdminというチームを選択します。このようにSecurity Groupを設定したコンテキストを**制限付きコンテキスト(restricted context)**と呼んでいます。
なお、初期状態で選択されているAll Membersというグループを削除することを忘れないでください。All Membersが含まれたままでは承認者を限定できません。
config.ymlを記述する
それではconfig.ymlの記述を見ていきます。
サンプルリポジトリの.circleci/config.ymlでは以下のように書いています。
version: 2.1
jobs:
build:
docker:
- image: cimg/node:lts
steps:
- run:
command: echo "Hello!"
deploy:
docker:
- image: cimg/node:lts
steps:
- run:
name: Deployment
command: echo "Success!"
workflows:
build-hold-deploy:
jobs:
- build
- hold:
type: approval # 承認ジョブを表示。
requires:
- build
- deploy:
context: approvers # ここでコンテキストを参照。そのセキュリティグループに属するユーザーが実行可能。
requires:
- hold
このサンプルのbuild-hold-deployというワークフローでは以下の3つのジョブを実行します。
buildジョブ : 承認前に実行されるジョブです。
holdジョブ : 承認ジョブとなります。type: approval により承認用のUIを呼び出します。
deployジョブ : 承認後に実行されるジョブです。ここで呼び出したコンテキストのSecurity Groupを参照します。そのSecurity Group内のメンバーがこのジョブを実行できます。
Security Groupに指定したGitHub OrgaizationのAdminチームのメンバーが実行したビルドの結果は以下のように表示されます。
一方、Adminチーム外のメンバーが実行したビルドの結果は以下のようにdeployジョブが失敗し、ビルドのステータスはUnauthrizedと表示されます。
その他の承認ジョブ利用例
ここでは詳細に触れませんが、承認ジョブに関する他の利用例を紹介します。
APIによるApprove
2020年は承認ジョブをApproveするAPIを公開しました。承認者がCircleCIのUIにアクセスしてApproveボタンを押すのは面倒でしょうという方はぜひこちらをお試しください。
多段階承認
制限付きコンテキストと承認ジョブを増やすことで、複数の承認者による承認フローを実現できます。以下のような二段階承認のワークフローのサンプルリポジトリはこちらです。
さいごに
承認ジョブとSecurity Groupを設定した制限付きコンテキストを組み合わせることで、特定のユーザーが承認した場合はワークフローの処理が継続され、それ以外のユーザーが承認した場合には処理が失敗するという制御を行いました。
一点、注意事項があります。GitHub OrganizationでOwner権限をもつユーザーはコンテキストのSecurity Groupに含まれていなくても承認を進めることができるのでご留意ください。
さて、2020年を振り返りますと、2019年に比べてCircleCIに触れる機会を増やすことができました。色々と要因はあるのですが、『CirlceCI実践入門』の出版が大きかったと思います。『CirlceCI実践入門』は本当に良書でわかりやすく、非技術職の私がCircleCIに参加したときにこの本があったらどんなに楽だったかと思います。
2021年はCircleCIコミュニティのもくもく会の時間を使ってセットアップした個人ブログが塩漬けになっているので、少しずつ日常の記録を残してみようかなと思っています。
これからもCircleCIをよろしくお願いします！
追記
ついでながら、承認ジョブに関するFAQを付記しておきます。
Q. 承認ジョブで承認したユーザーはPerformanceプランのActiveユーザーとしてカウントされますか？
A. はい。カウントされます。
Q. 承認ジョブで承認を待っている間もCircleCIのクレジットを消費しますか？
A. いいえ、承認を待っているHoldステータスの間はクレジットを消費しません。