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で作業する時代になってきた »
「ソフトウェア」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント