Atlassian製品による「No Ticket, No fork!」
Atlassian製品による「No Ticket, No fork!」に関する記事をリンクしておく。
GreenHopper を使用した Bamboo と Bitbucket の自動化 | Atlassian Japan
(引用開始)
率直に言って、チームが 課題ごとに開発ブランチを作成する慣習 を採用 (または検討) していない限り、上記の手法にこだわる必要はありません。 この手法には 3 つの意義があります。1 つ目として、ブランチ作成、マスターへの最終マージ、およびブランチの削除が自動化されます。これによって課題の実装にかかる時間が何時間も短縮されるというものではありません。しかし、開発者の作業項目からいくつかの管理タスクを省いてくれます。また、ストーリー ブランチの実践も促します (チームがそうすると決めた場合)。しかも、しつこくメールをしたり、井戸端会議で愚痴を言ったり、チーム ミーティングをしたりすることなく、洗練されたやり方でそれが実施されます。3 つ目として、これらのブランチに対する命名規則が自動化されます。チームのレポジトリ内のブランチを見るときに格段に見分けやすくなります。
(引用終了)
課題・障害・タスクのチケット単位にブランチを派生し、更新して、ブランチをmasterへマージする時にチケットも同時にCloseする方法が公開されている。
この手法は、チケットをトピックブランチ(ストーリーブランチ)とみなした場合によく使われるだろう。
この手法の利点は上記には3つ挙げられている。
(1)ブランチ作成、マスターへの最終マージ、ブランチ削除を自動化
(2)メンバーにチケット単位にストーリーブランチを作ることを促す
(3)ブランチに対する命名規則が自動化される
目を惹くのは(2)におけるチームへの影響だ。
バグ修正や機能改善、リファクタリングなど、開発者個人の作業は必ずブランチ上で更新され、masterへ最終マージされる運用が自然に促される。
いや、むしろ強制されるといって良い。
その運用によって、masterへのマージ時にコードレビューするタイミングが生まれたり、ブランチ上で試行錯誤する空間を得られることで自由に開発できる、などの利点が生まれる。
ツールがチームにプロセス改善を促す良い事例の一つだと思う。
| 固定リンク
「構成管理・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.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント