この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、CX事業本部の若槻です。
今回は、CircleCIでトリガーに応じて直列になったり並列になったりするWorkflowを作ってみたのでご紹介します。
作成したもの
早速ですが、今回作成した.circleci/config.ymlファイルは以下となります。（jobsの内容は省略のため簡易化しています。）
version: 2
references:
omitted_process: &omitted_process
docker:
- image: circleci/hello
steps:
- run: echo 'hello'
jobs:
build_and_test_unit:
<<: *omitted_process
deploy_in_dev:
<<: *omitted_process
deploy_in_integ:
<<: *omitted_process
deploy_in_staging:
<<: *omitted_process
deploy_in_pre_prod:
<<: *omitted_process
deploy_in_prod:
<<: *omitted_process
workflows:
version: 2
deploy_workflow:
jobs:
- build_and_test_unit:
filters:
tags:
only: /v([0-9]+\.){2}[0-9]+/
- deploy_in_dev:
requires:
- build_and_test_unit
filters:
branches:
only:
- master
tags:
ignore: /.*/
- approve_for_integ:
type: approval
requires:
- deploy_in_dev
filters:
branches:
only:
- master
tags:
ignore: /.*/
- deploy_in_integ:
requires:
- approve_for_integ
filters:
branches:
only:
- master
tags:
ignore: /.*/
- approve_for_staging:
type: approval
requires:
- build_and_test_unit
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/
- deploy_in_staging:
requires:
- approve_for_staging
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/
- approve_for_pre_prod:
type: approval
requires:
- build_and_test_unit
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/
- deploy_in_pre_prod:
requires:
- approve_for_pre_prod
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/
- approve_for_prod:
type: approval
requires:
- build_and_test_unit
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/
- deploy_in_prod:
requires:
- approve_for_prod
filters:
branches:
ignore: /.*/
tags:
only: /v([0-9]+\.){2}[0-9]+/上記のconfigから構成されるWorkflowにより、以下のような開発フローを実現することができます。（デプロイ先の環境は「開発」「結合試験」「ステージング」「プレ本番」「本番」の5つです。）
- 開発フロー
masterブランチから作業用ブランチをCheckoutする- 作業用ブランチで作業を行い、作業内容をCommitしてPushする
- ブランチのPushをトリガーにして、「ビルド・単体テスト」を実施するWorkflowがCircleCIで開始される
- Pushされた作業用ブランチをもとにPull Requestを作成する
- Pull Requestに対するレビューが承認されれば、
masterブランチへMergeする masterブランチへのMergeをトリガーにして、「ビルド・単体テスト」「開発環境へのデプロイ」「承認」「結合試験環境へのデプロイ」を直列で実施するWorkflowがCircleCIで開始される- 結合試験環境をもとに最終レビューを実施する
- 最終レビューが承認されれば、承認されたCommitにタグ（例
v1.2.3）を付けてPushする - タグのPushをトリガーにして、「ビルド・単体テスト」の後に「承認」および「ステージング環境へのデプロイ」「プレ本番環境へのデプロイ」「本番環境へのデプロイ」を並列で実施するWorkflowがCircleCIで開始される
と言っても、実際のWorkflowの画面を見ていただいた方が分かりやすいかと思います。
ブランチPushで開始されるWorkflow
開発フロー3.にてブランチのPushをトリガーにして開始されるWorkflowの実行時の画面です。
build_and_test_unitジョブによるビルド・単体テストのみを実施することにより、Pushされた作業用ブランチが少なくとも単体テストをPASSすることをPull Requestでのレビュー前に確認できるようにしています。
masterブランチへのMergeで開始されるWorkflow
開発フロー6.にてmasterブランチへのMergeをトリガーにして開始されるWorkflowの実行時の画面です。
開発環境へ正常にデプロイされることを確認できた上で、承認を経て結合試験環境にデプロイを行いたいため、build_and_test_unit、deploy_in_dev、approve_for_integ、deploy_in_integと直列にジョブを実施するWorkflowとしています。
タグPushで開始されるWorkflow
開発フロー9.にてタグのPushをトリガーにして開始されるWorkflowの実行時の画面です。
基本的にはビルド・単体テストを実施した上で、ステージング環境、プレ本番環境、本番環境の順でそれぞれ承認を経た上でデプロイを行うのでWorkflowは直列でも良いのですが、デプロイ失敗時やhotfix適用時など「ステージングとプレ本番を飛ばしていきなり本番環境にデプロイしたい！」という状況を考慮し、build_and_test_unitの後にapprove_for_stagingとdeploy_in_staging、approve_for_pre_prodとdeploy_in_pre_prod、approve_for_prodとdeploy_in_prodと並列にジョブを配置したWorkflowとしています。
最後に、[Piplines]画面からの各Workflowの見え方はこんな感じです。
おわりに
今回のWorkflowを作るにあたっては、workflowsのfilters部分をどのように記載すれば良いかを悩みましたが、configの組み方によりWorkflowがカクカク変わるのを見ながら検証するのは結構楽しかったです。
7
