4 ms·

In your example is A->B->C->D a series of staged release environments in the pipeline? Something like a graduated rollout? If that's the case then I'd say that

• joshuamorton 5y ago
  > In your example is A->B->C->D a series of staged release environments in the pipeline? Yes. > Something like a graduated rollout? If that's the case then I'd say that frequency depends on how you define deployment. I don't see why. If you imagine that you have only two stages, "staging" and "prod", and a requirement that things spend 24 hours pre-prod before being deployed, you can deploy each day to staging, and the next day to prod. If you then add additional stages, you can have it spend 8 hours on each stage, deploying to prod every 8 hours, so a higher frequency, but any given build is still preprod for 24 hours, so frequency has tripled without a change in latency.
  • thcipriani 5y ago
    > If you then add additional stages, you can have it spend 8 hours on each stage, deploying to prod every 8 hours, so a higher frequency, but any given build is still preprod for 24 hours, so frequency has tripled without a change in latency. Got it, thanks for the clarification. I'd interpreted your argument as: each stage is a deployment, therefore deployment frequency goes up (which also, of course, would mean lead time goes down -- so I was confused). I like that this scheme could maintain continuous integration by having the "B" staging include the patch under test in "C" -- clever solution!