チケットファーストからビルドファースト、Gitoriousへ
Gitoriousやゼロ機能リリース(Zero Feature Release)に関するラフなメモ書き。
【元ネタ1】
Gitを使った開発・運用フローの紹介 | FIRN.JP
Gitという優れた分散バージョン管理をソフトウェア開発の中心の配置して、チケットやビルド管理ツールを連携する方法が書かれている。
GitoriousとRedmineを使った開発 - ひかえめプロジェクト
(引用開始)
ポイントは,フィーチャーブランチ,リリースブランチ,ホットフィックスブランチをそれぞれRedmineのチケットに対応付ける点です.
これらのブランチの名前をすべて id/xx (xxはチケットナンバー)にすることで,自動的にブランチ上のコミットがRedmineのチケットに対応付けられます.
(引用終了)
ブランチはRedmineプロジェクトだけでなく、チケット単位に作ってもいい。
分散バージョン管理を使っているなら、チケット単位に自分だけのブランチを作って開発して、masterへPush又はrebaseする時にチケットがCloseされる運用になるだろう。
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
Redmineを使いたいと思う人の理由の一つに、SCM連携としてGitがデフォルトで対応しているから、というものがあった。
Redmineと連携する場合、MercurialよりもGitの方が使いやすいのかもしれない。
(追記:Redmineコミッタのまるやまさんから、Redmine1.2では、Redmine+Mercurialが最強です、とのコメントを頂いたので修正しました。ご指摘ありがとうございます。)
【元ネタ2】
第三回Jenkins勉強会に参加しました。あるいはZFRは次のムーブメントを起こすか - ハードコイルド・ワンダーランド
ソフトウェア開発の秘伝“Development Baseline 2007” - @IT
ゼロ機能リリースとは、一番最初のイテレーションで、ソフトウェア開発に必要な開発基盤や紙芝居(HTMLだけで、動くシステムではない)などをリリースすることらしい。
XP祭り関西2010でも、中西さんが、Trac+SVN+Hudsonという開発基盤を作るというゼロ機能リリースについて講演されていたのを思い出す。
XPのアーキテクチャスパイク、プロトタイピングに相当するように思える。
ゼロ機能リリースが必要な理由は、最初のイテレーションで、顧客へ価値あるソフトを提供する基盤を整えて、必要なフィーチャをできるだけ洗い出して、その後のイテレーティブな開発を順調に軌道に載せたいから。
牛尾さんが、この辺りのフェーズではストーリー供給力やストーリー検証力が必要、と言っていたのを思い出す。
色々考えてみる。
【追記】
かおるんさんから指摘を受けたので、修正・追記しておいた。
Twitter / @中村 薫: @akipii この話ですよね。 これなら納得です:-) http://bit.ly/kvuDNR
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- Javaのラムダ式の考え方(2022.08.10)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
「廃止Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント
Redmineのコミッタをやっているまるやまです。
Redmineとgitの連携は現段階において諸問題があるので、あまりお勧めしません。
Redmine 1.2でMercurial連携が大化けします。
Redmine 1.2において、Redmine+Mercurialが最強だと自負しています。
投稿: Toshi MARUYAMA | 2011/05/28 11:55
◆まるやまさん
ご指摘ありがとうございます!
僕もMercurial愛好者なので、Redmineとの連携機能が強化されるのはとても嬉しいです。
Redmineの機能はまだまだわかってない部分が沢山ありますので、間違っていたらご指摘下さると助かります。
投稿: あきぴー | 2011/05/28 23:04