リリース履歴の重要性
Redmineには、変更履歴と言うリリース履歴の機能がある。
この機能がいかに重要か、ラフなメモ書き。
【1】チケット駆動開発では、バージョンをリリースしたら、自然にリリース履歴が残る。
SVNコミットに必ずチケットをリンクさせれば、終了チケットがリリース履歴になる。
リリース履歴は何故重要か?
いつ何をリリースしたのか、という記録だから。
手作業でリリース履歴を作ろうとすると作業漏れがおきやすい。
RedmineのようなBTS、Hudsonのようなビルドツールを使っていないチームでは、リリース履歴を自動作成することができないので、リリース履歴をExcelのリリース台帳で管理しているだろう。
例えば、開発者が修正したソースにタグを付けてリリース台帳に記載して、ライブラリアンはリリース台帳を見てビルド&デプロイを実施するワークフローにしているだろう。
このワークフローはExcelのリリース台帳が一番重要。
このリリース台帳が壊れたり紛失したら、リリース作業に大きな支障を残す。
また、手作業のワークフローが多いので、ミスも多いだろう。
RedmineやMantisでは、ロードマップというリリース計画にチケットを一覧表示できるし、リリース予定バージョンでチケットをグループ化しておくと、先の予定のリリース作業が見えやすくなる。
そして、リリースしたバージョンの履歴が変更履歴として残るので、どのバージョンでどんなバグ修正を取り込んだのか、すぐに分かる。
つまり、BTSがリリース履歴を一括管理していることになる。
Hudsonの場合、RedmineやTrac、MantisなどのBTSと連携する機能がある。
実際、Hudsonがつけたビルド番号に、SVNリビジョンがひもづけられている。
そして、SVNのコミットコメントにチケットNoがあれば、Hudsonのビルド番号とリンクされる。
これによって、Hudsonでビルドしたモジュールに反映されたチケットを探すことができる。
これがトレーサビリティに当たる。
この機能があるからこそ、ビルドモジュールからSVNリビジョン、チケットを経由して、仕様や要件まで辿ることができる。
また、BTSで管理していれば、全文検索が可能だから、キーワードで検索できる。
従って、運用保守で、過去のパッチの修正意図を過去の終了チケットから探り出し、リバースエンジニアリングすることも可能。
【2】WF開発でも、設計工程のタスク管理にチケット駆動開発を使うと良い。
設計書は必ずSVNにコミットして、SVNの配下に置く。
つまり、設計書もバージョンアップしていく対象と捉える。
設計書の修正は必ずチケットを起票して、チケットに作業履歴を残す。
そうすれば、チケットとSVNリビジョンの関係を通じて、設計書とチケットが結びつく。
バージョンをマイルストーン単位にする。
マイルストーンは、設計書の提出時期、進捗報告の単位になる。
変更履歴に、マイルストーン単位の作業履歴が残る。
いつ誰が、どんな仕様を設計書に反映したのか、作業履歴が残る。
だから、何故こんな仕様が反映されたのか、後日になって検索して調査することも楽になる。
実際の設計書は、顧客から引き出した曖昧な要件を試行錯誤して詳細化しならが作られていく。
たくさんの課題を各チケットに起票しながら、そのチケットを解決する度に設計書をバージョンアップしていく。
たくさんのチケットを課題としてあげて、そのチケットを解決するほど、自然により良い設計になってくる。
ソースがたくさんのパッチで成長するように、設計書もたくさんの課題を反映することでより緻密になっていく。
リリース履歴には、構成管理の配下にある成果物の作業履歴であり、成長した履歴でもあるのだ。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント