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.

[@Lemmy4555]

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

[@stephencollis1453]

At the end he explains when these hotfixes don't go into master and only go into production, I feel like this covers the scenario you are describing. The hotfix branch that gets cherry picked will only has the changes necessary to fix the issue in question, if mater has changed so dramatically that A) the fix is no longer relevant, and B) the fix is significant enough to hotfix before next release, then you just create the branch from a point where it is relevant and don't merge it into master like he says. It seems pretty straight forward

[@mahdihosseinali7492]

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?

[@garethwynn01]

I'd say that itself is a scenario to try and avoid. It's more of a business issue than a technical issue.

[@kirankumarsukumar]

I learned something here. Thanks

[@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?

[@reneschindhelm4482]

I'm not a pro, but wouldn't QA test a version that's already no longer up to date then? 3 week iterations doesn't sound much for manual testing and stuff IMHO.

[@PiotrKula1]

Good practice for branching a test environment is not having a branch for test. It really complicated things and I have seen it go wrong more times than it actually stopped any thing critical form happening. With TFS online you can use the Release pipelines on which your testers can work on. For example, have CI build and tag packages from master. Have a dedicated release pipeline for the testers, THEY click a button, select a package and test it. Everything is good by them, then THEY tell us this version is good and we use the release pipeline - select the same package.. its going into UAT, then Blue/Green,Canary or Live - Much nicer approach as you testing the same code from start to end, without complicated branching strategies. You essentially build the package for Release and all that changes is the config per environment. You can use the same thing for Feature switching, probably even faster as you can deploy master direct into live and only enable a feature for specific IP's, or with specific headers, maybe special load balancing. That is ultimate.

In that approach, we do build each QA (in a isolated way) from its related Pull Request.

[@ddanielsandberg]

5 month late but here is a response. I will come at you (and all developers) hard in this one. Start rant: 1. You test the latest build from master/trunk. And by that I mean that you do not test a code branch, you test the BUILD of a specific commit. You deploy that build to different environments. ie. dev -> verification -> system -> stage -> prod. 2. Ensure that the things that differs between environments like ports, IPs, hostnames, settings, threads, etc. are provided at deploy-time or at run-time. Meaning that you do not create branches or rebuild the package for different environments. You build the package once, stamp a version number on it and deploy the same binary for all environments. 3. And this is the hill I will die on. There is no such thing as "QAs". QA are not equivalent to testers. QA is not a phase, not a department, not a team, not role and not a title. QA stands for Quality Assurance and is an ACTIVITY that happens from before the first requirement is written till the software is retired 10 years later. Do not conflate the skill of testing with the much larger activity of assuring quality of the product. Quality is everyone's responsibility and as such it cannot be delegated away. 3b. You do not send the build to testing, you do not put it in "ready for test", you don't get to say you are done (and start coding the next thing) unless it's built from TRUNK and tested. If it's not TESTED it's not done, it's still in "doing", meaning programmers and testers need to collaborate on every change till it's properly done. /end rant

[@GG-uz8us]

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

[@stephencollis1453]

The end "release flow" strategy describes a continuous integration setup, but you could apply CD to this easily. CD triggered at the end of the sprint, and on any merge to the "production" branch

[@elcool]

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

[@alexwatson6370]

that go into "real master"

[@stephencollis1453]

The release branches are just the master branch snapshots in time

[@valkon_]

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

[@awesomeworld557]

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.

[@raoulkoopman9408]

feature flags & comments

[@DamCipolat]

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

[@VictorMartinez-zf6dt]

They don't, github did.

[@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?

[@VictorMartinez-zf6dt]

No, because if you don't do it on master you risk a regression on future releases.

[@y666p]

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

[@VictorMartinez-zf6dt]

Except they haven't, because gitflow requires feature branching, creating a development branch that gets merge to trunk, and is overall more complicated. This is trunk based development, where you work on main or close to main and avoid branching all together, except for releases as teams need.

[@matswessling6600]

@@VictorMartinez-zf6dt "except for branches the teams need"..... gitflow

[@moorzymoores]

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

[@m_sedziwoj]

each time when is change on master, task should done by then, and it pass pull request review (so less simple bugs on code lvl)

[@Vaisakhreghu007]

There you have to do build once and deploy many strategy

[@dmitrym83]

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

[@KulKulKula]

What? No, it's not similar at all, actually, the “wrong” pattern looked like git flow

[@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?

[@stephencollis1453]

"We create a new branch in master, then fix the bug IN MASTER. Then cherry pick the bug into production" so no the next release wont have the bug

[@maucbsful]

@@stephencollis1453 yep, my bad. Misheard where the bug was fixed.

[@ahtabbasi]

Yea sorry. Testing in production might work for some projects but it is not a possibility for high risk systems like financial systems etc.

[@VictorMartinez-zf6dt]

They're not testing in production, but you should be testing in production anyways, especially if it's high risk.

[@arnoldwolfstein]

This demo... For the context... OK, no comment :)

[@wahoobeans]

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

[@OhhhThatVarun]

This is a 20min ad with a catchy name.

[@quixoticfallcy]

Hmmm. seems like you just revert back to gitflow.

[@vanivari359]

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.

[@VictorMartinez-zf6dt]

No, they didn't say thaty can't, they said that's their release schedule. Their main branch is always releasable.

[@jankinsics]

Would u kindly share links for this strategy? I am not quite following

[@ivanc.6064]

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!

[@DmitryKandalov]

It's not trunk-based development if you work on a branch and do PRs

[@omri9325]

Before GH was officially bought by MS

[@FordExplorer-rm6ew]

😂 YOINKED

[@samrasoli]

cool

[@PerpetualEducation]

5:41 ephemeral?

[@alpersilistre]

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

[@arnoldwolfstein]

Couldnt agfee more. Dont watch and waste your time. Fyi for new comers.

[@aldoburbank]

See Gitflow, already!

[@wojciechem65]

Please read the "revisited" note in original post about git flow. It's not golden bullet, especially in CI / DevOps times.

[@aldoburbank]

Where is the "revisited" note in original post about git flow. Thx!

[@alan-]

Hmmmm. Knowing how many bugs are in production in MS products and how many DECADES they remain there, makes me not take this too seriously. No wait.... Not take it seriously AT ALL.

[@arnoldwolfstein]

MS terminal killing me. So ugly. Sorry. Fortunately now they have WSL2 so we have zsh.

[@JohnnysaidWhat]

Am I missing something here? He bug fixes into master first then pushes to the production branch? WTF so he renamed dev branch master and master production???😂

[@WutipongWongsakuldej]

TBD Sounds like continuous integration to me.

[@VictorMartinez-zf6dt]

It is

[@thatoneuser8600]

TBD is only a part of CI; CI is much more than just TBD. It's also frequently using pair programming, having automated unit tests run before each commit, everyone using TDD, merging/committing to trunk at least once a day, etc.

[@matheusvictor9629]

Hmm sorry but this does not look good

[@Test-po1lu]

GitHub Flow, Multi-Branch-Pipeline Jenkins, Docker Containers, Master-Slave Architecture of Jenkins.... CI/CD DONE!

[@andrealaforgia]

That’s not Continuous Integration.

[@Manhunternew]

This is not good, do real trunk based development