AWS CodePipelineの概要整理とCI/CD パイプラインでSlack通知するまで
概要
SHIFTグループ会社のシステムアイに出向中の斎藤です。
CI/CDについては本SHIFT Group 技術ブログでも何度も取り上げられていますが、本記事ではCI/CDとはなにかというところだけでなく、AWSのCI/CDツールであるAWS CodePipelineを説明したいと思います。そして、実例の１つとして、パイプラインの途中のある一定のタイミングでSlack通知を行う方法を紹介します。
CI/CDとは？なぜ重要？
AWS CodePipelineについて説明する前に、そもそもCI/CDとはなんなのか、そしてそれぞれのメリットについて簡単に説明します。
CI (Continuous Integration 継続的インテグレーション)
上記のAWSの記事によると、CIの定義は以下のようになり、CIはDevOpsの文脈での開発手法であることがわかります。
継続的インテグレーションは、開発者が自分のコード変更を定期的にセントラルリポジトリにマージし、その後に自動化されたビルドとテストを実行する DevOps ソフトウェア開発の手法です。
CIが生まれた背景として、アジャイル開発の重要性が増してきたことが挙げられます。アジャイル開発では1、2週間程度の短いスパンで、実装→テスト→デプロイのサイクルを回していくことが特徴です。このサイクルをより早く円滑に回していくのを人手でいちいち行うのは大変です。そこでサイクルの一部（ビルド、テスト）を自動化していくというのがCIになります。CIを導入することで以下のメリットが得られます。
メリット
開発者の生産性を向上
開発者が手作業から解放されることで、アプリケーション開発に専念でき、生産性の向上が期待できます。短時間でバグの発見、対処
マージすることにテストが走るので、テスト頻度が上がり、バグの早期発見につながります。これにより品質向上が見込まれます。
CD (Continuous Delivery 継続的デリバリー)
上記のAWSの記事によると、CDの定義は以下のようになり、CIを拡張したものであるとわかります。（CDを継続的デリバリーの略ではなく、継続的デプロイの略とするものあります。継続的デリバリーと継続的デプロイの違いは運用環境への更新に手動での承認が必要か否かという点です。 継続的デプロイでは、明示的な承認が行われることはなく、自動的に本番環境にデプロイされます。 ）
継続的デリバリーとは、ソフトウェア開発手法の 1 つで、コード変更が発生すると、自動的に実稼働環境へのリリース準備が実行されるというものです。最新のアプリケーション開発の柱となる継続的デリバリーは、継続的インテグレーションを拡張したもので、すべてのコード変更が、ビルド段階の後にテスト環境または運用環境 (あるいはその両方) にデプロイされます。
CIではテストとビルドの段階までを自動化したのに対して、CDではそれだけでなく、テスト環境へのデプロイ、本番環境へのデプロイ、リリースの段階までを自動化してくれます。これにより、コードに変更を加えるたびに、それが反映されたアプリケーションの変更を常に確かめることができます。CDを導入することで以下のメリットが得られます。
メリット
リリースプロセスの自動化
リリースまでを自動化しているので、一連の流れをスムーズに行うことができます。開発者の生産性を向上
開発者が手作業から解放されることで、アプリケーション開発に専念でき、生産性の向上が期待できます。短時間でバグの発見、対処
マージすることにテストが走るので、テスト頻度が上がり、バグの早期発見につながります。これにより品質向上が見込まれます。
パイプラインファースト
パイプラインファーストとはプロジェクトでは一番最初にパイプラインを作るべきという考え方です。完璧なパイプラインでなくとも、必要最小限のものを作っておけば、開発が進むとともに最適化していくことができます。逆に開発が進んだ後でいざ導入としても後回しになってしまうことが多いです。なので、最初にパイプラインを作るべき、ということになるのです。つまり、パイプラインによる開発の加速を考慮すると長期的には低リスクな投資と言えます。
AWS CodePipelineとは？
上記のAWSの記事によると、CDの定義は以下のようになります。
AWS CodePipeline は、ソフトウェアをリリースするために必要なステップのモデル化、視覚化、および自動化に使用できる継続的な配信サービスです。ソフトウェアリリースプロセスのさまざまなステージをすばやくモデル化して設定できます。CodePipeline はソフトウェアの変更を継続的にリリースするために必要なステップを自動化します。
つまり、AWS CodePipelineを使用することで、リリースプロセスを自動化、可視化することができます。また、他のAWSサービスと相性が良く、簡単に連携ができます。なので、既にAWS環境を構築している、これから構築しようとしていてCI/CDパイプラインを作ろうとする場合、まずAWS Pipelineが候補に挙がってくるでしょう。
具体的にできること
AWS CodePipelineでできる主なことを紹介していきます。
CI/CD
パイプラインの各ステージでサービスを選択することで、CI/CDパイプラインを作成できます。主に選択できるサービスはAWSのものが多いですが、それ以外のサービスでも連携できるものもあります。各プロセスで使用できるサービスは現時点（2022年6月時点）では以下の通りです。
ソース
AWS CodeCommit
Amazon ECR
Amazon S3
BitBucket
GithHub
ビルド
AWS CodeBuid
Jenkins
デプロイ
AWS AppConfig
AWS CloudFormation
AWS CodeDeploy
AWS ElasticBeanstalk
AWS OpsWorks
AWS Service Catalog
Alexa Skills kit
Amazon ECS
Amazon S3
AWS CodePipelineで使われる主な用語としてはアクションやステージ、アーティファクトというものがあります。
アクション
アクションとはアプリケーションコードに対して行われる操作の単位です。例えば、テストやデプロイなどです。アクションタイプは以下のものがあります。
source
build
test
deploy
approval
invoke
ステージ
ステージは処理を実行する環境の単位です。複数のアクションから構成されます。
アーティファクト
アーティファクトはアクションによって処理されるアプリケーションソースコード、構築されたアプリケーションなどのデータの集合です。アクションにより生成、消費されます。
CodePipelineを使うのが初めての場合、AWS公式のハンズオンがわかりやすいのでおすすめです。
※これより先の内容を自身の環境で試す場合、既にパイプラインを作成していることを前提としているので、紹介したハンズオンをもとにパイプラインを作成する、もしくは自身で適当なパイプラインを作成しておく必要がありますので、その点をご注意ください。
手動承認
リリースプロセスを完全に自動化するのではなく、承認プロセスを設けることもできます。例として、デプロイプロセスの前に手動で承認を行いたい場合を紹介します。まず、デプロイステージの上の「ステージを追加する」を押します。
ステージ名を設定し、
「ステージを追加する」を押すと、ステージを作成することができます。
作成したステージの「アクショングループを追加する」を押し、アクションプロバイダーのトグルから「手動承認」を選び、「完了」を押すと、
デプロイステージの前に手動承認ステージが作成されていることが確かめられます。
実際にパイプラインを流してみると、手動承認のところで処理は止まり、承認を求められます。
「レビュー」を押し、「承認します」を押すことで、次のステージへと進めます。
成功すると↓のように表示されます。
通知
Amazon SNSやAWS Chatbotと連携することで、SMSやSlackに通知することができます。通知のタイミングは以下のようにアクションやステージの成功時、失敗時などから選ぶことができます。
通知の設定はとても簡単に行うことができます。一例として、ChatbotによるSlack通知を説明します。
まずは、Slackとの連携をしていきます。AWS Chatbotのコンソール画面から「新しいクライアントを設定」を押します。そこからSlackを選択し既存のSlack WorkSpaceとの連携を許可します。
連携が出来たら、「新しいチャネルを設定」からチャネルを作成します。
チャネルの設定画面では設定名を決め、どのSlack channelに通知をするかを選択します。パブリックチャネルの場合、チャネル名のトグルリストからslack channel名が表示されるので、選択できます。あとはロール設定、チャネルガードレールポリシー、SNSトピックを選択し設定を完了できます。（SNSトピックは事前に作成しておきます。タイプはスタンダードを選択し、名前を入力したら、オプションは何も設定しなくて大丈夫です。）
※Slack側でも設定することがあります。通知をしたいSlack channelに「AWS chatbot」というSlackアプリをインストールしておく必要があります。これを忘れてしまうと、AWS側で設定をしても通知がされないので注意が必要です。
最後の作業として、作成してあるCodePipelineの画面の「通知」というトグルから「通知の作成」をします。
そこで、「通知名」、「通知をトリガーするイベント」、「ターゲット」を設定します。今回の場合、Slack通知なので、ターゲットタイプはAWS Chatotを選択し、ターゲットは先ほど作成したチャネルを選択します。
以上の設定後、パイプラインを流してみると設定したタイミングでSlackに通知が来ることが確かめられます。（以下の例ではSource StageのSTRATとSUCCEEDのタイミングでの通知です。）
おわりに
本記事ではAWS CodePipelineについて紹介しました。CodePipelineを使用すると一連のリリースプロセスを自動化し、Slack通知もできることを紹介しました。CI/CDツールはこの他にもCircleCI、GitHub Actionsなどがあるので、技術要件、ビジネス要件に合わせた技術の選択ができるように知見を広げていきたいです。
参考文献
――――――――――――――――――――――――――――――――――
執筆者プロフィール：斎藤拓郎
大学院卒業後、IT関連会社にて、大手ベンダーに常駐し金融系の顧客に対し画面レイアウトや資料の作成などを行う。
独学でAWSを学びSAA、DVAの資格を取得。
AWSを学習していくうちに、インフラや自動化に興味を持ち転職。現在SHIFTから株式会社システムアイのRGA事業部に出向し、EKS環境の維持拡張の業務に従事している。
【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！
お問合せは以下の窓口までお願いいたします。
【お問い合わせ窓口】
窓口：rga@systemi.co.jp
URL：https://rg-automated.jp
