10周年のSPコンテンツ!
27
songmu @songmu
feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど
チーフ @katzchang
Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。
小野マトペ @ono_matope
Githubはfeatureブランチをmasterにマージする前にデプロイしてるのか…下手に真似すると怪我しそう。 / “中の人に聞いたGitHub flowの本当の使い方 - Qiita” htn.to/4oW5GSrJJv
小野マトペ @ono_matope
モチベーションは理解できたが、developとmasterがまるで別物になってしまうのが良くない。任意のfeatureブランチを検証環境にデプロイする仕組みを整えた方が建設的ではないか。 / “GitFlowをやめて本番リリースが楽になった話 - Qiita” htn.to/2XcjhTZczy
小野マトペ @ono_matope
やっぱfeatureの検証(QA)はfeatureブランチからるべきだな。developerやmasterはテストするとこではないぞいという
songmu @songmu
最近はdevelopブランチは要らないんじゃないか、と思うようにはなってきてて、developからmasterにマージされたら自動deployされるのではなくて、masterにfeatureブランチ直接マージしていって、masterにタグが打たれたら自動deployという形が良いのではないかと思いつつある
songmu @songmu
何故かというと、developからmasterにマージするとコミットハッシュが変わってしまうので、そこでまたテストとビルドが走ってしまうのは時間の無駄だし、動作確認を事前にdevelopでやっている場合、別のハッシュでリリースするのであれば、その確認の意味が薄れてしまうというのもある。
ymmt @ymmt2005
> masterにfeatureブランチ直接マージしていって、masterにタグが打たれたら自動deploy neco の CD の片方がこれ。tag -> CI -> deb package build -> pull で自動デリバリ
songmu @songmu
ここに対する障壁としてgit-pr-releaseの便利さがあって、pull request上でリリース差分を確認できたり、pull requestをリリース証跡にできるのは有用なんだよな。
songmu @songmu
GitHubはあるコミットハッシュに対するRelease Request(Tag Request)みたいな機能を提供して欲しい。 twitter.com/songmu/status/…
songmu @songmu
git-pr-releaseに代わる、Release issueを登録できるツールがあれば良いのかねぇ
songmu @songmu
pull requestが便利だから、release engineeringもそれでやってしまっているけど、Git本来的にはそれはtagでやるべきなんだろうなー
一生青春宣言 @side_tana
tagでリリース絶対いいな(テストが2回走る問題辛いよねという立場です)
songmu @songmu
@side_tana あと、ステージングで動作確認したものと、本番に出ていくものが、厳密には異なるっていうのもちょっと気持ち悪いよね
songmu @songmu
多分コミットハッシュでビルド作るのもイマイチという話もあって、例えばgit archiveのtar玉のハッシュ値をビルドのURIに使えば、masterブランチにマージしても同じ成果物を使わせることができる、とかはある。
らっきー @ara_tack
@songmu @0918nobita 質問です。developブランチなしの運用の場合、hotfixを切りたいときはどうすれば良いとお考えですか? masterの最新ではなく、タグ打ちされたところから切れば良いのでしょうか?
songmu @songmu
マージコミット作りたい派ではあるんだけど、メインラインにffマージできるのであれば、テストとビルドをやり直す必要はないってのはあるんだよな
songmu @songmu
@ara_tack @0918nobita 普通にfeatureブランチと同じようにブランチ作ってマージしてリリースするか、masterに直接コミットしてテスト通って動作確認終わったらタグ打ってリリースで良いのではないでしょうか。masterがリリースtagより進んでいて、リリースしたくないものがある場合は、(続きます
songmu @songmu
@ara_tack @0918nobita 一旦revertしてしまうか、前回のリリースタグ地点からブランチングして、そこで修正を作ってそこにタグを打ってリリースした後にmasterにマージすると、などが考えられると思います。ただ、masterにマージしたのにリリースできないものがあるという状況をそもそも作らない方が良いとも言えます
songmu @songmu
hotfixブランチって、複雑なブランチングルールの上で生まれざるを得なかったワークアラウンドルールみたいなところがあって、本来要らないものでもあるとも思う
らっきー @ara_tack
@songmu ありがとうございます。 今のチームではリリース前にまとめて動作確認しているので、不具合修正だけ動作確認してすぐに出したい時はどうすべきか気になって質問いたしました。masterにリリースできないものがあるのがよくないという話は同意するとともに耳が痛い話でした。
songmu @songmu
featureブランチをffマージしつつ、いざとなったらそこで入った複数のコミットをまるっとrevertできる、みたいな機能もGitHubにあると嬉しいのかなぁ
柴崎優季 @shiba_yu36
@songmu develop作らない時、hotfixの難しさはあるかもしれないですね
songmu @songmu
@shiba_yu36 確かにその難しさはあって、別のリプでも回答しています。ただ、緊急修正はhotfixがあろうが無かろうが難しい問題で、hotfixブランチはdevelopを並走させるからこそ生まれてしまった徒花でもあると思います。
残りを読む(39)
git

コメント

せんたく @senn_taku 2019年10月28日
みんなリベースおぼえて…グラフィカルログが世界樹になってる
wint: #DeathStranding @wint7 2019年10月28日
developいらないのは同感。リリース差分はタグをcompareすればいいし、ブラウザ拡張入れれば楽になる。
ログインして広告を非表示にする
ログインして広告を非表示にする