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つの機能は、とても重要な意味を持っていると感じている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「構成管理・Git」カテゴリの記事
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント