チケットファーストからビルドファースト、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
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「廃止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」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント
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