初めてAWS CDKにコントリビュートしてみました

こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。

「OSSへのコントリビュートかぁ。いつかはやりたいと思っているけどね・・・」

これは私のお気持ちでしたが、このように考えている人も結構多いのではないでしょうか？

日々お世話になっているOSSへの貢献をしたいなぁと思いつつも、日々の業務や学習を優先させちゃいませんか？私のことです。

そんな私ですが、先日業務中に見つけたちょっとした改善欲がきっかけでaws/aws-cdkのドキュメンテーション追記のPullRequest(以下PRと表記)を作成することになりました。

その後、高揚した私はもう1件aws-cdkにバグフィックスのPRを作成するなど、コントリビュートの味を覚え始めました。

そんな駆け出しのコントリビューターがPRを作成するまでの流れとその時の気持ちを併せて記事にしてみました！

• 「OSSにコントリビュートするのって強いエンジニアなんじゃないの？」
• 「簡単っていうけど本当ははまりどころがあるんじゃないの？」
• 「単純に怖い。英語だし。」

といった疑問をお持ちの方に少しでも参考になれば幸いです。

筆者のレベル感について

筆者はITエンジニア4年目ですが、その内訳はアプリケーションのバックエンド・バッチ処理開発・IaCとさまざまです。

aws-cdkも業務で触り始めたのは数ヶ月であり、深ーく細部まで理解している訳ではありません！

また普段の業務はお客様に最適なAWS環境構築・要件定義・ヒアリング・設計などをすることが多いので、ガッツリとしたアプリケーション開発には携わっっていない状況です。

そんな私でも貢献できるということですね！

初めてのコントリビュートはこんな感じでした

一目でわかるやつ

急にですがこのグラフをご覧ください。

細かい流れよりも伝えたいのは始めてコントリビュートした時の私の気持ちです。

これをみていただけるだけで、その辺の娯楽より面白かったことは伝わるのではないでしょうか？（上がったり、下がったり）

aws-cdkコントリビュートまでの流れ

さて気持ちの遷移をお見せしたところで初めてのコントリビュートまでの流れをご紹介します。

Issue・PRを出すまでの経緯はこんな感じでした。

• CDKで AWS Step Functionsを使っている時に少しつまる
• 「ドキュメントに1,2行書くだけでも助かる人もいそうだなぁ」と思う
• Issueを探していたら他にも困っている人がいた
• 「ドキュメントに数行書くくらいなら自分でもできるか！」という気持ちになる

次に実際にコントリビュートするまでの流れはこんな感じでした。

• Contributing Guide(通称)をみてPRまでのお作法を学ぶ
  • 英語でわからんけど翻訳ツールを使ってがんばる
• 既存でIssueが上がってないか確認
• 上がっていないので新規でIssueを立てる
• 「えいや！」でforkする
  • forkしてもオリジナルのリポジトリに影響はないのでご安心ください
• ローカルに開発環境を立てて、新しくブランチを作成
• ローカル開発・各種テスト
• Git PushしてPRを作成
• CI/CDで実行されるテストをパスする
  • PRのタイトルまでチェックしてくれるので安心
• レビュワーからapproveされてマージ！

この辺りは弊社の佐藤の過去の発表資料が非常にわかりやすかったです！

ほぼこの流れのとおりでした！

初めての人が「何かちょっと抵抗あるわ」と思ってそうなポイントとやってみた感想

始めてIssueを立てる

英語で書かないといけないだろうし、何か少し抵抗ありませんか？私はありました。

が、やってみるとあまり問題はありませんでした。

これは実際に私が初めて作ったIssueです。

その時は真面目に書いているつもりなのですが、結構「何言ってんだこいつ」みたいなことを書いてしまっている気がします。

実際にIssueを立てようとすると以下のように多様なテンプレートが用意されています！

書くべき項目も少なく、勝手にラベル付けもしてくれるので非常に作成しやすかったです。

翻訳ツールが作る英語を少し変更するだけでも、意味は伝わる文章をかけると思います！

PRを作成する際に走るCI/CD・テスト

実際に作られているPRを見れば分かるのですが、PRを作った段階で各種テストやリンターが実行されます！

一見すると「何か英語で怒られてて怖い」という気もしますが、実際は自分の変更がパッケージ全体に悪影響を及ぼさないように守ってくれているのですごく安心感があります。

これは私のPRのタイトルがお作法に則っていなかったので、リンターが指摘をしてくれている様子です。

英語もそこまで難しくないので、言われたとおりに変更するだけでした。

やらかしたらどうしよう・英語で怒られるの怖い

こちらをご覧ください。

せっかくapproveしてもらった後に、うっかり私はコードを変更してしまいました。（mainブランチの変更を取り込むボタンを押してしまった）

• 一斉に再度実行されるリンター
• コードが変わったため一度approveしてもらったものが外れてしまう

これらにビビりまくる私に対して、メンテナーの方は優しく教えてくれました。

英語も怪しい中、「それよりもコントリビュートありがとう」と言ってくれることで私はすごく安心しました。

やってみた感想

全体を通して「やってみてすごくよかった」と感じました（小並感）。

一番はコントリビュートすることでGitHubのアクティビティ（通称「草」）にかっこいいマークがついたことでテンションが上がりました。

他にも以下のようなメリットを感じました。

• 自分が触っているOSSの仕組みを知ることができる
• 単純にマージされるとすごくテンションが上がる
• 自分の市場価値向上につながる（と私は思う）
  • 今回はドキュメントだけですが、もっとバグ修正・機能修正をすることで

実際にマージされるとテンションがすごく上がったので、今度は既存のバグ修正にもコントリビュートしちゃいました！

これからも暇を見つけて、自分にできる貢献をしつつ、いっぱいレビューをもらいたいなと考えています！

怖いことよりも楽しい・嬉しいことの方が圧倒的に多かったので、ぜひみなさんも好きなOSSのIssue起こしからでも初めてみてください！