CodePipeline のトリガーで不便なポイントは？
Solution Architect の t_maru です。
今回から数回に渡って CodePipeline や CodeBuild など、CI/CD を AWS 上に構築する際に利用するであろうサービスについての記事をお届けします。
初回の今回はワークフロー全体を制御する役割の CodePipeline のトリガーについて、便利な点、使いにくい点について考えてみたいと思います。
CodePipeline とは
CodePipeline はソフトウェアの自動テストや継続的な配信 (デプロイ) に必要な手順をステップ化し、実行状況を可視化することができるマネージドサービスです。
テストからリリースまでのプロセスをワークフローとして定義し、決められた条件に従って自動的に実行することができるため、リリース時の手順間違いをなくし迅速なリリースを実施することができるようになります。
CodePipeline の詳細な説明に関しては下記、公式ドキュメントをご覧ください。
https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/welcome.html
CodePipeline は複数のステージを構成し、その間をアーティファクトで連携するような仕組みとなっています。ステージのアクションとして指定できる処理については Action category として下記の 6 種類があり、各 Action category の中にも複数の action provider (連携できる AWS サービスや外部サービス) が存在しています。
Source
Build
Test
Deploy
Approval
Invoke
Action provider のリストが掲載されているドキュメントの URL は下記になります。(日本語ドキュメントは Action category が翻訳されて表示され実際に設定する値がわかりにくいため、英語のドキュメントの参照をおすすめします。)
今回は CodePipeline のワークフローを起動するトリガーについてお話したいので、上記の Action category で言うところの Source に該当する動作の話となります。また、今回は GitHub との連携に関してお話しますが、トリガーに関しては Bitbucket や AWS が提供しているソースコードリポジトリである CodeCommit でも同様ですので、普段使っているサービスに置き換えてイメージして頂ければと思います。
GitHub との連携ですが、現在推奨されている CodeStar を使った version 2 の他に、以前は GitHub の OAuth トークンやパーソナルトークンを使用した方法もありましたが、現在は非推奨となっておりますので今回も version 2 の CodeStar を使った場合を例にして説明します。
便利な点と改善されると嬉しい部分
まず先に CodePipeline を使うメリットについてですが、以下のようなものが挙げられるともいます。
ワークフローとして定義できるので、リリースまでの間の処理が自動化されヒューマンエラーが介在しにくくなる
連携できるプロバイダが豊富で、特に AWS のサービスとの連携が充実しており用途に応じて必要な設定ができる
処理状況が可視化される
1 点目のメリットとして挙げた事項で、`ヒューマンエラーがゼロになる` と記載しなかったのは、そもそもワークフローの構築ミスや、手動承認プロセスで間違えて Approve / Reject する可能性などがありますので、介在しにくくなるという表現に留めさせて頂きました。
次にもう少し改善されると嬉しいな・・・と思う点についてですが、この点を上げる前に CodePipeline を CloudFormation で設定する際のテンプレートを見てみようと思います。
詳細なテンプレートのリファレンスは下記の公式ドキュメントを確認して頂きたいですが、概要レベルで説明すると下記のようになります。
Stage と呼ばれる複数の処理を塊にしたものを連結しワークフローとする
各 Stage には複数の Action を設定することができる
Action には Action type ごとに必要な設定が異なり、使用するものに合わせた設定を行う
今回は GitHub からのトリガーの話をするにあたり、ActionType については下記のような設定となります。
※ 以降、CloudFormation template のうち説明に必要な一部のみを抜き出して記載しています。
Stages:
- Name: "Source"
Actions:
- Name: "Fetch"
ActionTypeId:
Category: "Source"
Owner: "AWS"
Version: "1"
Provider: "CodeStarSourceConnection"次にこの Action type に対する設定を Configuration に記載していくことになりますが、設定すべきパラメータについては下記を参照して設定していくことになります。
必須で設定が必要なパラメータは下記となります。
ConnectionArn
FullRepositoryId
BranchName
先程の CloudFormation のテンプレートに設定値を追記すると下記のような形となります。
Stages:
- Name: "Source"
Actions:
- Name: "Fetch"
ActionTypeId:
Category: "Source"
Owner: "AWS"
Version: "1"
Provider: "CodeStarSourceConnection"
Configuration:
ConnectionArn: "CodeStar connection の ARN"
FullRepositoryId: "GitHub のリポジトリ名"
BranchName: "ブランチ名"設定値については先程のドキュメントを参照して頂ければと思いますが、今回 CodePipeline の使いにくさの要因となり得るパラメータは `BranchName` です。
このパラメータは名前の通り GitHub 上でのブランチ名となりますので、例えば stable なブランチとして main を運用していれば main を指定することで、main ブランチに変更があった際に CodePipeline をトリガーしてワークフローを起動できます。
なぜ、これが問題なのか？と思われるかもしれませんが、開発のブランチ運用の方針によってはこれでは下記のように不便なことが出てきます。
ブランチ指定なので feature ブランチなど、一時的に生成されるブランチの CI をトリガーできない
Pull Request をトリガーとして指定できない
ブランチ戦略については GitHub-flow や Git-flow がよく使われる戦略かと思いますが、どちらの戦略をとっても上記のデメリットには遭遇するのではないかと思います。
これらは CodeBuild や Step Functions などを活用することで、やりたいこと自体を実現することは可能なのですが、正直なところこのような部分に労力を割きたくないというのが本音だったりはします。
本音は一旦棚に上げ、これらを解決する手段については次回の記事でご紹介できればと思います。
まとめ
CodePipeline はそのまま使った場合、feature ブランチなどの一時的なブランチへの commit や、Pull Request をトリガーとしたワークフロー実行が現時点では行えませんので、サービス選定の際にはご注意ください。
今回は CodePipeline の概要と、Source stage として利用した場合に少し不便だなと感じる点についてご紹介しましたが、課題として挙げた
ブランチ指定なので feature ブランチなど、一時的に生成されるブランチの CI をトリガーできない
Pull Request をトリガーとして指定できない
これらを実現するためのカスタマイズ方法については次回ご紹介できればと思います。