Gitによるチケット駆動開発の事例
Gitによるチケット駆動開発の事例をSlideshareで見つけたのでリンクしておく。
【元ネタ】
第5回テックヒルズ『Go to Git !』~さらばSVN~ に行ってきました | shinodogg.com
資料を要約しながら、自分の感想も入れてみる。
SVN主導の開発で抱えていた問題。
「pull request主導のチケット駆動開発したい。svnには障壁が多い。」
trunk, staging, releaseの3つのメインブランチ戦略。
(僕もSVNでこのブランチ管理の経験はある。
きちんとソース管理はされているが、マージが手作業な場合、ライブラリアンの負荷が途方もなく大きい。
どのリビジョンをリリースするのかというExcel申請書が大量に届いて、それを見ながら手作業でマージしてビルドする。)
SVNはマージやブランチを切るコストが大きすぎる。
(trunkから派生したブランチとtrunkの間のマージはまだ楽だが、ブランチ間同士のマージはまだまだ厳しい。)
理想は、GitによるPullRequest主導のチケット駆動開発。
(チケットにソースの修正理由や発端、経緯が記載されている、ないし、リンク箇所があるので、コードレビューしやすいし、担当を引き継ぎしやすい。)
Gitには、TiDDを実行する環境が揃っている。
GitHubにはチケットもWikiもあるし、PullRequest機能によってコミッタがそのパッチをレビューしてマージできる作業が埋め込まれている。
Trvis-CIと連携すれば、GitHubリポジトリのソースをWeb経由でワンクリックでビルド&リリースできる。
「ツールが文化を規定する」。
「知の高速道路、巨人の肩」。
速くなる、楽になるだけで世界が大きく変わる。
SVNでは到達しづらい目標にすぐに辿りつけて、追い越せる。
Gitによるチケット駆動開発のメリット。
リポジトリブラウザが速い。
Redmine+SVNとは全く違う。
TiDDをやりやすい。
diffを見ながら会話して、ワンクリックでPullReqestしてマージできる。
メンバーの意識も変わる。
コードを見てもらえる安心感。
ちょっとした思いつきをコミットできる気楽さ。
ペアプロやコードレビューを育む環境。
PullRequestのおかげでOSSの敷居も低くなった。
移行期間中は、SVNがメインライン、Gitが開発用のブランチ。
gitに慣れてもらい、cherry-pickで指定リビジョンをつまみ食いしてマージ。
その間にワークフローを直す。
(マージには幾つかの種類がある。「実践 反復型ソフトウェア開発」で詳細に書いてくれているので後でまとめたい)
git-flowやgithub-flowは夢。
git-flowよりシンプルなgithub-flowが理想。
リリースできないものをmasterに入れない。
GitHub Flow (Japanese translation)
(この部分は、比較検証して後で考察したい。)
移行時のチェックリスト。
上を倒す。
GitHubを使えば、コードレビューで改善できる点は理解してもらいやすい。
レビュー文化は正しい文化なので取り入れましょう。
でもGHEまでは受け入れられなかった。
数百万の初期導入費用は即OKではない。
なので、gitlab化。
横を倒す。
SVNすら使っていないエンジニアには、バージョン管理のメリットを説明。
共有サーバの短所、画像の履歴管理や差分表示。
元気なプロジェクトで便利そうで楽しそうな雰囲気作り。
PullRequestでワイワイ。
(ブランチ作成→コミット→PullRequestを公開)
移行しない理由を潰す。
環境、ツール、ドキュメントを整備。
前プロジェクトのリポジトリを勝手に同期しておき、いつでも移行できるようにする。
ドメインを全社に公開して、全社的に移行する雰囲気を作る。
不満を言われた瞬間に直す。
詰まった時にすぐに聞ける環境づくり。
(Gitを理解したエンジニアを増やす)
コンフリクトが起きたら、コミットツリーを書いて、原因を説明する。
Gitの手順に慣れてもらう。
移行していないプロジェクトは仲間はずれ、カッコ悪いね、という雰囲気作り。
「開発者はうまく怒らせるとすごい生産性を発揮する」。
リポジトリをGitにするだけでは駄目なのか?
WebUIからGitでバージョン管理できるのが大事。
ワークフローはツールが規定する。
UIが使われ方を規定する。
(まさにその通り)
WebUIが無かったら、SVNとほぼ同じ使い方をされてしまう。
ゴールはPullRequest文化の輸入。
個人で幸せになってもいいのは小学生まで。
チームの生産性最大化を目指そう。
| 固定リンク
« 構成管理パターンの記事「Streamed Lines: Branching Patterns for Parallel Software Development」 | トップページ | サーバー構築を構成管理とTDDで作業する時代になってきた »
「ソフトウェア」カテゴリの記事
- Redmine AI HelperプラグインはRedmineをAI駆動プロジェクト管理に変える可能性を秘めている #Redmine(2025.12.31)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
「Redmine」カテゴリの記事
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
- 第30回東京Redmine勉強会の感想 #redminet ~古いチケット管理基盤にAIという新しい衣を被った未来(2026.05.16)
- 製造業がRedmine導入で必ず聞く3つの質問~MS Project派がRedmine導入で悩むこと(2026.05.03)
- RedmineのAI支援機能はチケット管理システムにとって重要な要件だ(2026.04.29)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
「ソフトウェア工学」カテゴリの記事
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
- リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか?(2026.04.08)
- アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か(2026.03.23)
- アーキテクチャモダナイゼーションとはそもそも何なのか?(2026.03.22)
「チケット駆動開発」カテゴリの記事
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
- 第29回東京Redmine勉強会の感想~今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet(2025.11.09)
- RedmineJapan vol.4の感想part1~Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan(2025.07.31)
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
「Agile」カテゴリの記事
- 自動車・半導体・防衛産業から読み解く、業界を制する設計思想(2026.06.10)
- PMOはスクラムマスターである(2026.06.07)
- DX戦略はDX成熟度を考慮して戦略策定すべき(2026.03.20)
- PMPとCSM取得者数推移(日本 vs 中国)から読み取れる指針は何か?(2026.02.23)
- SAFeはScrumと全く異なるアジャイル開発プロセスだ(2026.02.01)


コメント