こんにちは、 開発担当 の松本です。 Sleipnir 3 for Windows 開発では Redmine と Mercurial (Tortoise HG) を利用しています。 チケット駆動開発のように、Redmine チケットを利用した開発では修正をコミットしてから Redmine チケットをクローズすることはよくあるので、Redmine のチケットと Tortoise HG を連動させたくなります。 Tortoise HG から Redmine のチケットを参照するのは以前に紹介した TurtleMine で行えますので、ここからさらにチケットをクローズする処理を自動化しようというのが今回の話です。 処理の概要 Mercurial ではコミットなどの特定のタイミングで外部プログラムを呼び出すことができる仕組みがあります。今回はこれを利用して Redmine チケットのクローズ処理を
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス=担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス=担当】 →t
本格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。 想定する状況 VCSはmercurial一本で運用 IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたい リリース順≠開発完了順(チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえる リポジトリ配置 中央(central) どこかの共有サーバー上にあり、全ての開発成果が集まる場所。 中央@個人用(default) ↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。 確認環境(test) 中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。 個人ローカル 個人の開発環境上に置かれるリポジトリ。やりたい放題する。 ブランチ運用 default リリースブランチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く