こんにちは、サーバーワークス OSS探求部のくればやしです。（「部」は部活の部）

先日、AWS CDKに初めてコントリビュートしましたので、作業の流れをまとめておきたいと思います。

といっても、CDKは（CDK自体の）開発者向けのドキュメントが公式に書かれているので、実際に作業する際にはこちらを確認する必要があります。

本記事はあくまで執筆時（2023年6月）に、実際に行った作業の一例としてご覧ください。また、提出する Pull Request（以下PR）は feat （機能開発）を想定します。後述しますが、PRの種類によって提出の要件が異なります。

着手するIssueを決める

CDKのリポジトリにはすでに起票されているIssueがたくさん（現時点で1600以上！）ありますので、着手するIssueを決めます。もちろん、Issueが無くともPRを作成しても構わないでしょうが、起票されているIssueの多くはすでにリポジトリの管理者によってトリアージされており、優先度(pN)や難易度（effort/XXXX）のラベルが付与されています。したがって、初めてのコントリビュートの場合は、起票されているものから手頃そうなものを選択すると進めやすいと思います。

github.com

開発環境を構築する*1

ここが最初はなかなかに理解するのが大変でした 🥲

CDKは複数のパッケージやツール等がまとまった巨大なモノレポ構成となっており、 Lerna というツールを使って全体ないし一部をビルドできるようになっています。

言語はTypeScriptがメインとなっており、ビルドを行うとJavaScriptのファイルが生成されます。

例えば、リポジトリ全体をビルドするには以下のような手順になります。

git clone https://github.com/aws/aws-cdk.git
cd aws-cdk
yarn install
npx lerna run build

ビルド時にメモリのヒープエラーのようなものが出た場合は NODE_OPTIONS=--max-old-space-size=8192 のようにオプションを付与した上で実行するようにします。

github.com

ただし、全体をビルドするのは非常に時間がかかるため、一部のみ、例えばAWSの各サービスに関する実装のある aws-cdk-lib パッケージのみを対象とする場合は、以下のように --scope オプションを付与します。

npx lerna run build --scope=aws-cdk-lib

また、開発している際に、例えば TypeScript のファイルを変更して一々上記コマンドを実行するのは面倒な場合は、下記のように yarn watch を実行しておくと、変更を検知して自動でビルドしてくれます。

実際の作業においてはビルドはほぼこれでまかなえました。

cd packages/aws-cdk-lib
yarn watch

以上がローカル環境に構築する大まかな流れですが、簡単にビルドされた環境に触るのなら Gitpod も用意されているため、Gitpodを立ち上げても簡単にビルド環境に触ることができます。私も最初は Gitpod 上で作業していましたが、やはり自分でビルドしてみないとリポジトリの構成等、「なにがなんだか分からない･･･（L風）」という感じだったので、結局ローカルに作業環境を準備することとなりました。

Pull Request の要件の確認

開発に入る前に PRの要件を確認しておきます。

本記事執筆時では feat のPRを出すには README.md が更新されていることと、ユニットテストと結合テスト（ntegration test。本記事では結合テストと訳しておきます）関連のファイルを同時に提出する必要があります。

feat requires a change to a README.md.
feat requires a change to a unit test file and integration test files.

github.com

開発＆ドキュメントの更新＆テスト関連ファイルの準備

PRを出すのに必要な開発等を行います。上述の作業の中でも結合テストのファイルの準備が少し難しかったので記しておきます。

github.com

結合テストはCDKリポジトリで開発されている framework-integ を用います（したがって、このパッケージも事前にビルドしておく必要があります）。

実行すると指定したAWSサービスのデプロイ＆削除を実際に行います。その際の構成情報等が *.snapshot ディレクトリに出力されます。これらのファイルがPRの提出に必要です。

結合テストの実行は、例えば今回出したPRであれば、LaunchTemplateのファイルが対象なので、以下のように行います。事前に一時的なデプロイに用いるAWSの認証情報を登録しておく必要があります。

cd packages/@aws-cdk-testing/framework-integ
yarn integ integ.launch-template.js

実行が完了すると integ.xxxxx.snapshot ディレクトリに構成情報等のファイルが出力されます。

Pull Request を出す

さて、後はPRを出すだけです。LinterやValidatorに怒られるかもしれませんが、すべてを緑にしてレビュー頂くまで待ちます。

Approveされたら Mergify というツール（Bot）が自動でマージしてくれました。

Mergify - CI/CD pipeline optimizer

おわりに

今回、CDKに初めてコントリビュートしてみました。印象的だったのはCDKのリポジトリでは、大量のIssueやPRがありますが、優先度や難易度を表すラベルの他にも、コントリビュート初心者のPRには beginning-contributor ラベルが自動でついたり、PRの再レビューが必要な場合には pr/needs-review ラベルが自動で付いたりと、管理の自動化や見える化の工夫が非常にされていたことでした。

普段はほとんど業務のリポジトリでしか作業していないので、大きなOSSならではの工夫で活かせそうなものは持ち帰って活かしていきたいと思います 💪

*1:記事中では参考に執筆時の手順を記しますが、環境構築の手順は特に頻繁にアップデートがあるため、必ず最新のドキュメントを確認するようにしてください