CodePipeline で承認プロセスを設けて本番環境へリリースする #reinvent

おはようございます、藤本です。

先日、AWS re:Invent 2016 でリリースされた CodeBuild を CodeCommit、CodeDeploy、CodeCommit と組み合わせて、デリバリプロセスの自動化を試してみました。

• CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent

こちらは master ブランチにプッシュしたら、テスト、ビルドを通して、インスタンスにアプリケーションをデプロイします。リポジトリへプッシュするだけでデプロイまで全て自動化されていて、デプロイが簡単ですね。ただし、テストが全て自動で網羅されていることが前提となっています。

ユニットテスト、単一アプリケーション内のインテグレーションテストであれば、ある程度できるかもしれませんが、ペネトレーションテスト、他システムとの統合テスト、負荷テスト、UIチェックなど全てのテストを自動化できているケースはまだまだ少ないのではないでしょうか？

今回は、前回の続きじゃないですが、master ブランチにプッシュしたら、自動でデプロイされるのはステージング環境とし、ステージング環境で自動化できないテストを実施した上で、承認プロセスを設けて、本番環境へリリースするパイプラインを試してみました。

概要

先日は CodePipeline の Source（CodeCommit）、Build（CodeBuild）、Deploy（CodeDeploy）をご紹介しましたが、他には Test、Invoke、Approval というアクションカテゴリがあります。今回は Approval という任意のタイミングで処理を続行するアクションを利用して、承認プロセスを設けてみました。

前回の環境を利用します。リポジトリへのプッシュからインスタンスへのデプロイまでの処理は変わりません。デプロイ先がステージング環境だとお考えください。

こちらの詳細については下記エントリをご参照ください。

• CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent

今回のデリバリの流れは以下のようになります。

ポイントとしては以下となります。

• ステージングデプロイから本番デプロイの間に自動化できないテストを実施
  • 本番デプロイは任意のタイミングで実施
• リポジトリのコミットから本番リリースまで追いかけたい
  • CodePipeline の可視化されたパイプラインで処理状況を追うことが可能
• 本番デプロイはステージング環境でテストしたパッケージと同じものを利用したい
  • CodeDeploy でシステマチックにパッケージを選択
  • 注意点として、今回の構成では本番デプロイ前に master ブランチへプッシュすると、新しくプッシュされたパッケージが配布されます。ただ、アーティファクトを分けるなど対策は可能です。

試してみた

前回の CodeCommit、CodeBuild、CodeDeploy、CodePipeline の設定を流用します。前回の設定は完了しているところから始めます。

目次

• Step 1 : 承認用 SNS Topic の作成
• Step 2 : 本番用 Deployment Group の追加
• Step 3 : CodePipeline の設定追加
• Step 4 : 動作確認（リリース承認）
• Step 5 : 動作確認（リリース否認）

Step 1 : 承認用 SNS Topic の作成

承認プロセス（CodePipeline の Approval）になると SNS Topic への Publish します。

SNS の設定画面から Topic を作成します。

Topic 名、表示名を入力します。

SNS Topic は準備完了です。

Step 2 : 本番用 Deployment Group の追加

前回は CodeDeploy のアプリケーションに一つの Deployment Group しか用意しませんでした。本番用の Deployment Group を作成します。

本番用の Deployment Group が作成されました。

<

h3 id="step3">Step 3 : CodePipeline の設定追加 前回作成した CodePipeline のパイプラインに承認、および本番環境へのデプロイを追加します。

前回作成したパイプラインはこちらです。

パイプラインを編集します。

Stage を追加します。

まずは、承認アクションを追加します。

項目	説明
Action category	今回は承認プロセスを利用したいので Approval を選択
Action name	任意の名前
Approval type	Manual approval（現在は一択）
SNS topic ARN	Step 1 で作成した SNS Topic の ARNを選択
URL for review	パイプラインのレビュー用リンクに埋め込む URL
Comments	表示するコメント

次に、本番環境へのデプロイアクションを追加します。

項目	説明
Deployment provider	今回は CodeDeplooy を利用するため、CodeDeploy を選択
Application name	CodeDeploy のアプリケーション名を選択
Deployment group	Step 2 で作成したデプロイメントグループ名を選択

save pipeline changes をクリックして設定を反映します。

作成したパイプラインはこんな感じです。

Step 4 : 動作確認（リリース承認）

それでは、ソースコードをプッシュして、動作確認してみましょう。

$ git commit -am "approval test"
[master bc50ff3] approval test
 1 file changed, 1 insertion(+), 2 deletions(-)

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 442 bytes | 0 bytes/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote:
To https://git-codecommit.us-east-1.amazonaws.com/v1/repos/django-fujimoto
   e109fd6..bc50ff3  master -> master

ステージング環境へのデプロイまでSucceededとなり、承認の前でパイプラインが停止しました。

ここから最初のプロセスに記載したリリースに向けたテストやら、リリース判定を迎えます。

無事にリリースを承認されたら、本番環境へリリースします。リリースを開始する時は Review をクリックします。コメントを入力し、Approval をクリックします。

パイプラインの後続処理が開始されました。

本番デプロイまで完了すると、全てSucceededステータスになりました。

リリースプロセスがどこまで進んでいるのかがひと目見て分かるのは嬉しいですね。

Step 4 : 動作確認（リリース否認）

次に、リリースの否認を試してみましょう。ソースコードをプッシュして、動作確認してみましょう。

ステージング環境へのデプロイまでSucceededとなり、承認の前でパイプラインが停止しました。

リリースに向けたテストでバグが見つかったり、リリース判定の材料が足りずに、NG 判定となった場合、パイプラインの承認プロセスで否認することで中断するができます。

中断する時は Review をクリックします。コメントを入力し、Reject をクリックします。

Rejectedステータスとなり、ProductionDeploy は実施されませんでした。

まとめ

いかがでしたでしょうか？

CodePipeline は全てが自動化されたリリースプロセスだけでなく、手動で作業するところも、Approval を埋め込むことで待ちのステータスとすることができます。リリースプロセスを可視化することで関係者が増えてもパイプラインのステータスで管理するのは良さそうです。