6 ms·

This workflow, like all others, is just a formalization of some reality. The reality is that many organizations and teams run on nothing but trunk - and it more

by kosma 10y ago

This workflow, like all others, is just a formalization of some reality. The reality is that many organizations and teams run on nothing but trunk - and it more-or-less works on them. Some teams work by building blocks separately and then joining them together; other prefer to hammer away on a problem all together. Both approaches work. What worries me are emotional claims that the other approach is fundamentally flawed, or that some git workflow is The One True Way. I've seen feature branches get stuck in review for weeks. I've seen trunk-only developers not knowing how to merge a branch back to trunk. I've seen trunks brought into a state of disarray and never fixed again. I've seen svn-only devs get completely bogged down and confused by a git wofkflow. Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists.

paul_h 10y ago
https://trunkbaseddevelopment.com/youre-doing-it-wrong/#merely-naming-a-branch-trunk https://trunkbaseddevelopment.com/youre-doing-it-wrong/#mere... Subversion having that TBT thing made it easy for people to respond 'yes we're doing trunk based development' when they're not
crdoconnor 10y ago
I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).
- brianwawok 10y ago
  How do you support a 3 year LTS branch for enterprise customers without long lived branches?
  - lloeki 10y ago
    IIUC your use case this is not the kind of branch that gets merged back, it's more of "another trunk" whose version is largely frozen and that may get backports and fixes.
  - crdoconnor 10y ago
    I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).
    - brianwawok 10y ago
      Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.
      - crdoconnor 10y ago
        We were selling to Fortune 500s. The upgrade paranoia only kicked in when they were subjected to broken releases and had to roll back.
      - devonkim 10y ago
        The F500 is incredibly varied in their requirements even within the same company. I've seen demand for new features and long term, keep-everything-the-same-as-day-one from the same group for different services / products. Paying more money to keep things from not changing or for not adding features is something unique to enterprise environments though.
    - icebraining 10y ago
      Well, sometimes the lack of stability is purposeful - new features are added, old features are deprecated, etc. How do you deal with that?
  - masonic 10y ago
    What languages do not support the equivalent of #ifdef in the C world, such that you can have variations in actionable code without having permanently separated code branches?
  - angry_octet 10y ago
    OP: this works for Google and Facebook, if you don't use it, you're dumb. I'd quite like to load the LTS version of GMail and Facebook. I'd also like to have some say in how these apps I use every day work. Unfortunately, I have no say. I'm not even the customer.
- kosma 10y ago
  Branch rot is a known problem, and it hints at a larger issue lurking somewhere in the organization - usually either inability to ship or inability to keep things in order.
- prodigal_erik 10y ago
  In 20 years I've never worked on a project that had a test suite strong enough to merit blind faith. Usually the weak points are * realistic test input: either you carefully scrub actual production traffic and replay it (these require a ton of setup that doesn't age well), or you guess what you think users are doing and create dummy requests (and miss anything wacky you didn't know users do) * load & perf: it's rare for a team to spin up a prod-sized cluster just for a test, and before AWS it was almost unheard of to go out and buy twice the hardware you need, even when you were lucky enough not to be deploying on your customer's boxes. A change that tanks your cache hit rate can ruin your whole day yet look fine at trivial sizes. * visual design: Microsoft famously got bitten by moving away from manual testing that would catch dialogs made unusable by layout changes We usually had best-effort integration tests, but they never caught everything, and we always had to make tactical decisions about when to release what based on risk.
  - crdoconnor 10y ago
    * Lack of realistic test input is usually a problem caused by over-reliance on unit testing or lack of monitoring feedback. * UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review"). * "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory. >We usually had best-effort integration tests, but they never caught everything, Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible. I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.
stcredzero 10y ago
Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists. My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for. As always: context. The above approach is only going to work well, when there is convenient high bandwidth communications between teammates. (Not only for your version control, but also for communication between people.) I've seen trunk-only developers not knowing how to merge a branch back to trunk. Well of course. If they never had constant practice at merging, they wouldn't be very good at it. Merging isn't trivial. I've seen trunks brought into a state of disarray and never fixed again. Can't they roll back? This strikes me as a sign of badly designed process, or developer incompetence. This should be seen as something like breaking the build. (In a CI environment, it would be breaking the build, yes?)
- TylerE 10y ago
  This is basically how the team I work on does it. We have wrapper scripts around git. Commiting automatically merges from master first.
- kosma 10y ago
  It was a badly run organization - and, as an extension, bad management, bad developers, bad process, bad requirements and bad practices. It wasn't trunk-only that made the project grind to a screeching halt - it was people.
- chrisseaton 10y ago
  How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?
  - stcredzero 10y ago
    Most places I worked "built" by loading the release configuration, then saving off the image. That's often all there is to it. At one job, some pre-population scripts were also run for menus and drop downs.
iatanasov 10y ago
In other words there is no size fits all there is even no size fit two . All those workflows are based on the management o the organization it self .

by kosma 10y ago

paul_h 10y ago

https://trunkbaseddevelopment.com/youre-doing-it-wrong/#merely-naming-a-branch-trunk https://trunkbaseddevelopment.com/youre-doing-it-wrong/#mere... Subversion having that TBT thing made it easy for people to respond 'yes we're doing trunk based development' when they're not

crdoconnor 10y ago

I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).

brianwawok 10y ago
How do you support a 3 year LTS branch for enterprise customers without long lived branches?
- lloeki 10y ago
  IIUC your use case this is not the kind of branch that gets merged back, it's more of "another trunk" whose version is largely frozen and that may get backports and fixes.
- crdoconnor 10y ago
  I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).
  - brianwawok 10y ago
    Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.
    - crdoconnor 10y ago
      We were selling to Fortune 500s. The upgrade paranoia only kicked in when they were subjected to broken releases and had to roll back.
    - devonkim 10y ago
      The F500 is incredibly varied in their requirements even within the same company. I've seen demand for new features and long term, keep-everything-the-same-as-day-one from the same group for different services / products. Paying more money to keep things from not changing or for not adding features is something unique to enterprise environments though.
  - icebraining 10y ago
    Well, sometimes the lack of stability is purposeful - new features are added, old features are deprecated, etc. How do you deal with that?
- masonic 10y ago
  What languages do not support the equivalent of #ifdef in the C world, such that you can have variations in actionable code without having permanently separated code branches?
- angry_octet 10y ago
  OP: this works for Google and Facebook, if you don't use it, you're dumb. I'd quite like to load the LTS version of GMail and Facebook. I'd also like to have some say in how these apps I use every day work. Unfortunately, I have no say. I'm not even the customer.
kosma 10y ago
Branch rot is a known problem, and it hints at a larger issue lurking somewhere in the organization - usually either inability to ship or inability to keep things in order.
prodigal_erik 10y ago
In 20 years I've never worked on a project that had a test suite strong enough to merit blind faith. Usually the weak points are * realistic test input: either you carefully scrub actual production traffic and replay it (these require a ton of setup that doesn't age well), or you guess what you think users are doing and create dummy requests (and miss anything wacky you didn't know users do) * load & perf: it's rare for a team to spin up a prod-sized cluster just for a test, and before AWS it was almost unheard of to go out and buy twice the hardware you need, even when you were lucky enough not to be deploying on your customer's boxes. A change that tanks your cache hit rate can ruin your whole day yet look fine at trivial sizes. * visual design: Microsoft famously got bitten by moving away from manual testing that would catch dialogs made unusable by layout changes We usually had best-effort integration tests, but they never caught everything, and we always had to make tactical decisions about when to release what based on risk.
- crdoconnor 10y ago
  * Lack of realistic test input is usually a problem caused by over-reliance on unit testing or lack of monitoring feedback. * UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review"). * "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory. >We usually had best-effort integration tests, but they never caught everything, Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible. I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.

stcredzero 10y ago

Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists. My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for. As always: context. The above approach is only going to work well, when there is convenient high bandwidth communications between teammates. (Not only for your version control, but also for communication between people.) I've seen trunk-only developers not knowing how to merge a branch back to trunk. Well of course. If they never had constant practice at merging, they wouldn't be very good at it. Merging isn't trivial. I've seen trunks brought into a state of disarray and never fixed again. Can't they roll back? This strikes me as a sign of badly designed process, or developer incompetence. This should be seen as something like breaking the build. (In a CI environment, it would be breaking the build, yes?)

TylerE 10y ago
This is basically how the team I work on does it. We have wrapper scripts around git. Commiting automatically merges from master first.
kosma 10y ago
It was a badly run organization - and, as an extension, bad management, bad developers, bad process, bad requirements and bad practices. It wasn't trunk-only that made the project grind to a screeching halt - it was people.
chrisseaton 10y ago
How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?
- stcredzero 10y ago
  Most places I worked "built" by loading the release configuration, then saving off the image. That's often all there is to it. At one job, some pre-population scripts were also run for menus and drop downs.

iatanasov 10y ago

In other words there is no size fits all there is even no size fit two . All those workflows are based on the management o the organization it self .