4 ms·

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 indica

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.

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.