バックエンドエンジニアのtakuminishです。現在、私は教材入稿ツールの開発チームに所属しています。教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。Commitsを導入するとともに、conventional-changelogによるCHANGELOGを自動で生成する仕組みを採用しました。Commitsの導入にあたって検討したルールとconventional-changelogを使用したCHANGELOGの自動生成について紹介します。本題に入る前に、教材入稿ツールの特徴的な開発フローについて説明します。独自のバージョニング手法セマンティックバージョニングとは異なる独自のバージョニング手法を採用しています。バージョニングのルールは以下の通りです。flowを参考にしたブランチ戦略をとっています。flowでは、featureブランチがmainブランチにマージされた時に本番環境にリリースするフローになっています。flowと異なります。そこで、リリースの手順を以下のようにしています。本番環境リリース承認チケットを作成し、承認をもらうリリース作業を開始するまた、featureブランチやreleaseブランチをmainブランチにマージする際にはSquashマージを行うようにしています。Commitsのルール整備とCHANGELOGの運用を検討した理由2023年6月に初回リリースをしてから数回のリリース作業を行なっていく中で、以下のような課題があることがわかりました。logの差分を確認した後、手動でリリースノートに貼り付ける必要があり、ヒューマンエラーが発生しやすく、また漏れがあっても気付きにくい本番環境にリリースする際にはリーダークラスの社員の承認が必要だが、リリースノートだけではユーザ影響の有無がわからないため、リリース対象のPRを一通り確認する必要があり、承認者の負荷が高まっているリリース時に社内向けにリリース内容の周知を行なっているが、リリースノートだけではユーザ影響の有無がわからないため、周知文の作成に時間がかかっている以上の課題から、リリースノートの情報量を高めること、リリースノートの自動生成の仕組み作りの両方が必要であると考えました。Commitsを採用することにしました。Commitsとは、より明示的なコミットメッセージを記述するための規約のようなものです。以下のようなフォーマットでコミットメッセージを記述します。footer(s)]mainブランチへのマージは全てSquashマージで行なっています。Commitsのルールを教材入稿ツール開発に合うように定義し直すことで、リリースノートの情報量を上げることができるのではないかと考えました。Commitsに関連するOSSも多く開発されています。調査することにしました。調査の結果、以下の2つについて検討しました。packageのpublishをワンストップで行う一見すると、semantic-releaseが多機能で良さそうに見えますが、前述した通り、教材入稿ツールはバージョニング手法が特殊です。場合はマイナーバージョンアップといった自動バージョンアップができません。packageを公開するわけでもないためsemantic-releaseは適さないと判断し、CHANGELOGの生成のみを行うconventional-changelogを採用することにしました。Commitsのルールを教材入稿ツールの開発フローに合うように再定義していきます。ルールの定義にあたり、以下の内容を考慮しました。Commitsに準拠している必要はなく、PRタイトルが準拠している必要がある導入にあたり、開発者の覚えるルールを減らし、開発者の負荷があまりかからないようにしたい考慮すべき内容をもとに以下のように方針を決めました。Commitsのtypeとscopeのルールを定めました。typeについては、@commitlint/config-conventionalを参考に以下のようなルールを定めました。新規機能を追加する(既存機能に機能を追加する作業も含む)場合はfeatとする。既存機能に要件と異なる動きをする機能が存在し、修正する場合はfixとする。レイアウト修正などの軽微な修正も含む。ユーザから見た振る舞いを変えずにパフォーマンス改善を行なった場合はperfとする。利用ユーザにとっては関係ないコードの追加、修正(eslintのruleの追加など)。依存ライブラリのアップデートもchoreとする。ドキュメントを修正した場合はdocsとする。リファクタリング、リアーキテクチャを行なった場合はrefactorとする。テストの追加など、テストに関する作業を行なった場合はtestとする。無scopeの内容は多岐にわたるため、厳密なルールを決めることはできませんが、おおまかに以下のようなルールを定めました。Commitsのルールに沿う形でCHANGELOGが出力されるように、conventional-changelogのconfigファイルを設定していきます。conventional-changelogは様々な設定をconfigファイルで変更できますが、今回はCHANGELOGに出力されるtypeとそれに対応するCHANGELOGの見出し文を定義していきます。具体的には以下のようになります。typesに設定している配列の順番がそのままCHANGELOGに出力される順番となるため、ユーザ影響があるtypeがCHANGELOGの上部に表示されるように配列の順番も考慮しています。],});作成したconfigファイルをもとにCHANGELOGを生成するには、以下のようにoptionでconfigファイルを指定します。前述した内容をもとに、CHANGELOGを出力した結果が以下のようになります。Commitsのtypeごとに見出しが分かれており、リリース内容がより分かりやすくなっています。typeごとにユーザ影響の有無を定義しているため、リリース承認者や周知文作成者はユーザ影響のあるtypeのみに注目すれば良いです。scopeが記載されていることで、影響範囲も一目でわかります。Commitsに準拠していない状態でmainブランチにマージされてしまい、CHANGELOG生成時に内容が不足していることが複数回ありました。Commitsに準拠しているかどうかをCIでチェックし、準拠していなければ以下のようにPRにコメントを残すと同時に、mainブランチへのマージをできないようにしました。Commitsに準拠していない状態でmainブランチにマージされるのを防ぐことができるようになりました。適用した結果どうだったかtype別にユーザ影響の有無、scopeで機能を表すようにしたことで、リリース承認時にどの機能に対してユーザ影響があるのか一目でわかるようになり、承認者の認知負荷を下げることに成功しました。社内向けのリリース内容の周知文を作成する際も、ユーザ影響のあるtypeのみに注目すればよく、リリース内容の周知漏れも防ぐことに貢献しています。今回の取り組みの結果、開発メンバーが作成するPRタイトルがより具体的になりました。Commitsを取り入れたのも1つの理由だと思いますが、PRタイトルがそのままリリースノートに記載されるようになったことで、より内容が他者に伝わりやすいタイトルにしないといけないという意識がメンバー内に芽生えたのだと思います。PRタイトルがより具体的になったことで、PRのレビュー時にタイトルを見て内容を把握できるといった副次的な効果もあリました。Commitsとconventional-changelogを導入して数ヶ月間運用をしましたが、まだ以下のような課題が残っています。リリースノートの作成に対して手作業がいくつか残っている現在の運用では、releaseブランチ内でCHANGELOGを生成し、mainブランチにマージ後、手動でtagの作成とリリースノートの作成をしています。CHANGELOGに詳細な内容は出力されているので、リリースノートは以下のようにCHANGELOGの該当のバージョンへのリンクを添付する簡素なものにしていますが、なるべく手動作業は減らしたいと考えています。今後はtagの作成、リリースノートの作成の自動化についても検討していきたいです。scopeの内容が開発メンバーによって統一されていないことがあるtypeについては前述した通り7パターンしかないため厳密にルールも決めていますが、scopeに記載する内容は多岐にわたることもあり、ルールを厳密に決めることができていません。そのため、同じscopeにすべき2つのPRタイトルのscopeが異なっていたり、大文字/小文字が統一されていないなどの問題が発生してきています。scopeが統一されていないのは開発メンバー間でscopeに対する認識が揃っていないことが原因であると考えており、解決するためにはメンバー間で密に認識合わせを行うことが必要になります。運用を開始してからの数ヶ月間で何百ものPRが開発メンバーによって生まれています。過去のPRでどのscopeが設定されていたのかをある程度資料化し、それをもとにscopeを決定することでscopeに対する認識が揃うと同時に、scopeの統一も図ることができると考えています。hiring!株式会社ドワンゴの教育事業では、一緒に未来の当たり前の教育をつくるメンバーを募集しています。カジュアル面談も行っています。お気軽にご連絡ください!カジュアル面談応募フォームはこちらwww.nnn.ed.nico開発チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。(3)引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。