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のUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント