Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd
Redmine・HudsonとSCMの機能の関連表 をチケット管理システムWikiに追加した。
【元ネタ】
チケット管理システムWiki
RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索
特集:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社
言いたかったことは、RedmineがSCM(構成管理)と密接に関係するだけでなく、ビルド管理ツールHudsonの機能とも対応していることだ。
つまり、下記の機能がそれぞれ対応する。
【1】SCMコードライン⇔Redmineプロジェクト⇔Hudsonジョブ
バージョン管理(Subversion、CVS、Git etc.)のリポジトリにあるtrunkやbranch単位で、ビルドモジュール(コンポーネント)が作られる。
Hudsonがビルドする作業の単位はジョブになる。
ビルドモジュールが複数個のコンポーネントを統合してビルドされる場合、下流ジョブにコンポーネント、上流ジョブにビルドモジュールというジョブの依存関係を設定する。
Hudsonを使ったアジャイルな開発入門:第3回 Hudsonによるチーム間の連携~上流・下流ビルド|gihyo.jp … 技術評論社
上流・下流ビルド(ジョブ)とは、依存関係のある複数のジョブでつけるHudsonの機能。
普通は、jarのような最小のコンポーネントを下流ジョブとして先にビルドした後に、warのように最後にビルドするモジュールを下流ジョブとしてビルドする。
つまり、ビルドの実行順序を上流・下流ビルド(ジョブ)で関係付ける。
Hudsonが無かった頃は、Antなどで手作業でビルドしていたから、ビルドの実行順序を間違うとすぐにコンパイルエラーになってしまう。
Hudsonがあるおかげで、複雑なビルドもGUI上で設定できて、かなり楽になった。
更に、ビルドモジュールを本番環境へリリースする場合、ビルドモジュールが本当に本番モジュールであるのか、を検証したいなら、ファイル指紋を使えばいい。
ファイル指紋はバイナリファイルのハッシュ(MD5)であり、ファイル指紋を比較することでより厳格にリリース管理を運用することも可能。
Hudsonを使ったアジャイルな開発入門:第3回 Hudsonによるチーム間の連携~ファイル指紋を記録|gihyo.jp … 技術評論社
【2】SCMタグ⇔Redmineバージョン⇔Hudsonビルド番号
Subversion(CVS) tagging pluginを使うと、SVN(CVS)タグからチェックアウトされたソースからビルドされる。
SVNタグをリリース予定バージョンとして厳格に扱う場合に有効。
HudsonのSubversion Tagging Plugin: プログラマの思索
イテレーションに紐づく全てのタスクが100%で終了したら、いつでもリリースできる。
SVN(CVS)タグはリリース予定バージョンであり、Agile開発ではイテレーションに相当する。
【3】SCMリビジョン⇔Redmineチケット⇔Hudsonビルドログ
SVNリビジョンに書かれたコミットログは、Hudsonのビルドログ(コンソールログ)に出力される。
HudsonのRedmine(Trac, Mantis etc) pluginを使えば、Hudsonのビルドログから各BTSチケットへ遷移できる。
又、RedmineのHudson pluginを使うと、RedmineチケットのSVNリビジョンの履歴に「SUCCESS」「FAILURE」などのビルド結果が追記されるので、どのビルド番号にどのリビジョンが反映されているのか、が一目で分かる。
r-rabsのRedmine Hudson Pluginがすばらしい件
Redmine - Hudson Plugin 0.1.0 - Redmine
つまり、ビルドモジュール→SVNリビジョン→チケット←仕様(要件) or ビルドモジュール→BTSバージョン(SVNタグ)→終了チケット というトレーサビリティを実現できる。
Redmineプロジェクトとビルドモジュールを対応づける理由の一つは、ビルドモジュールのリリース計画や変更履歴がRedmineプロジェクトのロードマップや変更履歴に対応するようにしたいからだ。
そうすれば、Redmineの各プロジェクトのロードマップを見るだけで、コンポーネントがいつどんな修正を反映してリリースされるのか、をすぐに一覧できる。
ソフトウェア開発のリリース管理では「いつ何をリリースするのか」「今のモジュールにどんな修正が反映されているのか」という2点がいつも重要になる。
しかしながら、リリース作業をきちんと記録して、厳格なワークフロー管理をしていないチームでは、デグレやリリース作業ミスが多発しがちで、開発メンバーのモチベーションを落としてしまう。
デグレやリリースミスほど、ソフトウェア開発で嫌なものは無い。
チケット駆動開発は、「いつ何をリリースするのか」はロードマップというリリース計画、「今のモジュールにどんな修正が反映されているのか」は変更履歴という過去のリリース履歴という機能に置き換える。
この2つの機能は、とても重要な意味を持っていると感じている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「Redmine」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
「ソフトウェア工学」カテゴリの記事
- Javaのラムダ式の考え方(2022.08.10)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント