-
頻繁にリリースするチームのためのリリース管理プロセス
スコープ計画から振り返りまでの七つのステップで、リリース管理プロセスを説明する。各担当者と完了条件、リリース種別ごとの違い、DORA指標を紹介する。
エンジニアリング1分で読めます
-
チェンジログは誰が書いていて、誰が書くべきか
チェンジログは誰が書くべきか。PR作者は何が変わったかを、PMはなぜ重要かを知っている。どちらか一方だけでは、顧客に使える項目は書けない。
エンジニアリング1分で読めます
-
チェンジログのファイル形式、JSONかYAMLか単なるMarkdownか
チェンジログの形式は、ページやウィジェットに使えるか人間にしか読まれないかを決める。Markdown、JSON、YAMLの代償と移行の判断基準を説明する。
エンジニアリング1分で読めます
-
GitHub Actionsのためのチェンジログチェック
GitHub Actionsのチェンジログチェックは、項目がなければマージを拒否する。記憶頼みの運用が続かない理由と、チェック自体が壊すものも解説する。
エンジニアリング1分で読めます
-
Gitタグ、リリース、そしてあなたのチェンジログ
Gitタグ、リリース、チェンジログのエントリは、一つの出来事の三つの記録だ。混同するとずれる理由と、三つが噛み合うべき形を具体例とともに説明する。
エンジニアリング1分で読めます
-
モノレポのチェンジログ:一つにまとめるか、パッケージごとか
モノレポのチェンジログは、全体で一つでもパッケージごとでもよい。正しい形を決めるのは構造ではなく、誰がログを読み、何を探しているかという点だ。
エンジニアリング1分で読めます
-
セマンティックバージョニングとあなたのチェンジログ
セマンティックバージョニングは、エントリを読む前に、リリースが呼び出し側をどれだけ痛めうるかを伝える。各番号の約束と対応するエントリの責任を説明する。
エンジニアリング1分で読めます
-
人々が追い続けるチェンジログページの作り方
チェンジログページを作る価値があるのは、誰かが戻ってくると期待できる場合だけだ。置き場所、各エントリの要件、フィード、ウィジェットを説明する。
エンジニアリング1分で読めます
-
チェンジログの自動化と、その限界について
収集、フォーマット、公開は自動化してよいが、選定と言い回しは自動化してはならない。チェンジログ実務での境界線と、それが動いたときの影響を見ていく。
エンジニアリング1分で読めます
-
Conventional commitsからチェンジログへとつなげる方法
Conventional commitsはチェンジログを導出可能にするが、読みやすくはしない。この慣習が与えるもの、限界、人間が埋めるべき隙間を具体的に説明する。
エンジニアリング1分で読めます
-
Keep a Changelog、実際に導入してみて分かったこと
Keep a Changelogの仕様は一ページで短いが、導入するとチームは逸れていく。仕様が語ること、意図的に残したこと、現実で破綻する点を検証する。
エンジニアリング1分で読めます