Git patterns and anti-patterns for successful developers : Build 2018

In this session we show how to use Git in teams with pull requests and how to use branches to manage your releases. In this session we will compare GitHub flow with the 'Release Flow' practised at Microsoft.

[Lemmy]

There's a weak spot in this strategy: the master branch may diverge significantly from production due to a highly productive two weeks. As a result, the fix required for master could differ from what is needed for production. In such cases, merging the fix directly into production becomes unavoidable, unless you can afford to wait for the next release, which is the best option when feasible. My take is that you have to first assess the severity of the issue, and if an hotfix is necessary is better to create a branch from prod, fix it there, run all the checks and deploy and then fix or cherry pick the fix in the master as well. If the issue is not that urgent than just wait 1/2/3 weeks for the next release and fix the bug just on master

[vanivari]

Sooo... you can't deploy every single change to production due to scaling issues... and the answer is to not deploy to production at all for 3 weeks and use cherry picking of bug fixes? There are better solutions. Like: use "slots" (e.g. one deployment every 20 minutes), which contain all the changes of the last 20 minutes. Or much better: change the structure of your monolithic application (into... let's call it "microservices" or "self-contained systems") to avoid that 300 people work on the same code base and deployment unit. This talk is 4 years old, but this is not a new concept. And the decision to go from 20+ deployments a day to one every 3 weeks is kinda a extreme overreaction. And you don't solve any problem because how do developers now test their changes? Once every 3 weeks to find out that the master branch is "broken" for 2 weeks now? I'm not a fan of a dogmatic microservice approach, but if you run into these types of scaling issues, your application is way to big.

[valkon_]

Is this example really trunk based development? I don't see a difference with future branches.

[elcool]

This got weirder every jump. The master here is really develop. And those throw away branches are releases that go into master.

[GG-uzus]

So how do you deploy your release branch to production? It is not continuous delivery, right?

[uncommonbg]

What is a good practise for branching for a test environment if we are doing trunk based development? I understand that everything in master is suppose to go to the client, but what if we want to have a separate branch and environment for QA's to test?

[mahdihosseinali]

This seems interesting, but what would you do if you have multiple live branches? Azure runs on servers, so you can obsolete the previous release, what if you have multiple customers and need to keep changes for each one of them?

[awesomeworld]

I still don't understand how you deal with features that takes long time? How do you maintain multiple versions of the same software? Features flags looks easy but on paper only.

[alpersilistre]

The title of the video does not reflect the topics of the talk.

[OhhhThatVarun]

This is a 20min ad with a catchy name.

[DamCipolat]

Why you lock/unlock the master branch? this practices affects the continous delivery

[yp]

I wonder if VSTS team realised they have re-invented the Git Flow and named it 'Release Flow Branching'

[quixoticfallcy]

Hmmm. seems like you just revert back to gitflow.

[wahoobeans]

just pull in new changes from the main branch in your working branch with merge or rebase

[RobertNutella]

It looks fun on the paper, as every presentation about this topic. But nobody is showing right tools for versioning and how to use it with specific project management and building tools.

[dmitrym]

This branching strategy looks very similar to GitFlow, with one exception. The strategy that is in the video doesn't have develop branch.

[moorzymoores]

So how would I CD to test/qa environments with just master branch?

[dbarochia]

But fixing on master branch? What we have already added some features before the issue get reported? Don't you think we should do bug fix on the release branch and later that should merge into the main?

[maucbsful]

Something I don't understand is fixing a bug only in the production branch. Wouldn't the next release have the bug? Since the new production branch is made from master and the bug wasn't patched in master, only the production branch. Am I missing something?

[ivanc.]

I dont think merging features in periodically and adopting feature flags is practical or even needed in most cases. plus what if mid way through feature u decide u dont want the feature but its already partly release (in an unstable state!) ? nah i wont be adopting feature flags thanks!