6 ms·

Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: https://trunkbasedde

by wcarss 6y ago

Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ One of the key elements of trunk flow that I value about it is that "the software you released" is not a living stream. Because of that, it should not be tracked by a long-lived branch with commits that flow in in over time except in rare fix situations. With trunk flow and similar styles, you can always merge to master, and you can always deploy master. You do so by cutting a new branch, and in my opinion, you then build a static artifact. Next time you deploy, you cut another branch, build your artifact, and put it somewhere. Need to do a hotfix, but there's other work since last release that you just can't ship? Cherry-pick onto the currently-deployed release branch, not onto some long-lived production branch. There's no weird merge-backs, no strange no-op commits in a long-lived history. trunk-flow is also very simple. For these and other reasons, it's great. And, some key points about building static deployment artifacts: if you build an artifact to deploy at merge-time to master, you can avoid having your production servers download and execute code for you. You can test your exact artifact before you ever send it to production. You can reproduce your builds. Left-pad-like library unavailability issues can't hit between staging and production. Deployments to production are very fast. You can keep a few artifacts around and roll back quickly and reliably to working states (barring database stuff!). You can deploy two versions to different userbases at the same time. It's very useful. :)

dionian 6y ago
never seen the site, expected to find something i disagree with, but found that it matches the way I've always worked. Merging early and often and using CI is the way to go and avoid being in the merge process as much as possible. Going to share this with people to explain my workflow, great resource
jes5199 6y ago
yeah, this is the one I use. I think of it as the “default” now - it’s been a while since I worked on a team that used anything else, I guess that means it’s popular with small startups
tempodox 6y ago
That's how I've always been using Subversion and I do the same with git. Development branches should be short-lived and feature-focused.
dastx 6y ago
Trunk flow often requires feature flagging systems to control what's not ready yet. Feature flagging is an issue to solve in itself. At previous places when I've touched feature flagging it's always been something along the lines of a config file. If the goal is the just filter out code that isn't ready, it's often fine, however if you were in a need to disable a flag you've just enabled as part of your deploy, it requires another deployment.
- Game_Ender 6y ago
  If you have a service or website you can (and should) do it dynamically with a service. I have seen Flagr [0] used to great effect here. As always you have to strip out flags when the features are permanent. 0 - https://checkr.github.io/flagr/#/ https://checkr.github.io/flagr/#/
  - dastx 6y ago
    I work for a company called LaunchDarkly. We're aiming to resolve the issues that come with feature flagging. Worth a look if you're looking for SaaS app.
twic 6y ago
I still cannot get my head round the fact that people don't know about TBD, and that there are substantial numbers of people not doing it. It's how all source control was done before DVCS. It's pretty much the default workflow with a DVCS - if you read the Git docs and do the simplest things, you're doing TBD! It works perfectly well for most people. How do people get to the situation where they know about Git Flow, but don't know about TBD? This feels like a huge failure of education or documentation or something.
- pseudalopex 6y ago
  Trunk based development isn't how all source control was done before DVCS.[1] The Git documentation suggests using long running branches.[2] "A successful Git branching model" was very influential. Git Flow sounds official. GitHub Flow sounds like Git Flow. [1] https://trunkbaseddevelopment.com/alternative-branching-models/index.html#mainline https://trunkbaseddevelopment.com/alternative-branching-mode... [2] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows https://git-scm.com/book/en/v2/Git-Branching-Branching-Workf...

by wcarss 6y ago

dionian 6y ago

never seen the site, expected to find something i disagree with, but found that it matches the way I've always worked. Merging early and often and using CI is the way to go and avoid being in the merge process as much as possible. Going to share this with people to explain my workflow, great resource

jes5199 6y ago

yeah, this is the one I use. I think of it as the “default” now - it’s been a while since I worked on a team that used anything else, I guess that means it’s popular with small startups

tempodox 6y ago

That's how I've always been using Subversion and I do the same with git. Development branches should be short-lived and feature-focused.

dastx 6y ago

Trunk flow often requires feature flagging systems to control what's not ready yet. Feature flagging is an issue to solve in itself. At previous places when I've touched feature flagging it's always been something along the lines of a config file. If the goal is the just filter out code that isn't ready, it's often fine, however if you were in a need to disable a flag you've just enabled as part of your deploy, it requires another deployment.

Game_Ender 6y ago
If you have a service or website you can (and should) do it dynamically with a service. I have seen Flagr [0] used to great effect here. As always you have to strip out flags when the features are permanent. 0 - https://checkr.github.io/flagr/#/ https://checkr.github.io/flagr/#/
- dastx 6y ago
  I work for a company called LaunchDarkly. We're aiming to resolve the issues that come with feature flagging. Worth a look if you're looking for SaaS app.

twic 6y ago

I still cannot get my head round the fact that people don't know about TBD, and that there are substantial numbers of people not doing it. It's how all source control was done before DVCS. It's pretty much the default workflow with a DVCS - if you read the Git docs and do the simplest things, you're doing TBD! It works perfectly well for most people. How do people get to the situation where they know about Git Flow, but don't know about TBD? This feels like a huge failure of education or documentation or something.

pseudalopex 6y ago
Trunk based development isn't how all source control was done before DVCS.[1] The Git documentation suggests using long running branches.[2] "A successful Git branching model" was very influential. Git Flow sounds official. GitHub Flow sounds like Git Flow. [1] https://trunkbaseddevelopment.com/alternative-branching-models/index.html#mainline https://trunkbaseddevelopment.com/alternative-branching-mode... [2] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows https://git-scm.com/book/en/v2/Git-Branching-Branching-Workf...