3 ms·

My initial thought on this was that the negative changes the author describes in the post were driven by continuous delivery pipelines. But agile delivery pract

by Sevii 5y ago

My initial thought on this was that the negative changes the author describes in the post were driven by continuous delivery pipelines. But agile delivery practices have a similar effect of increasing the frequency of delivering software. If you have a system to deliver software updates in one hour, you will use it to ship 'just in time' updates. Structurally it is hard to argue against fixing the customer pain when you can easily deploy a fix. But the long term effect of having CD is that testers get pushed out of the system. If we deliver code everyday we can no longer afford to spend 3 days testing each release. If we can't spend 3 days testing for defects in the entire product, we end up only testing a small amount of the actual product on each release. If we deliver code multiple times per day we probably cannot afford to do 'any' manual testing. CI/CD encourages spending as little time as possible on testing. If deploying code takes 10 minutes, why let testing make it a 3 day process? The long run effect is that the quality of software decreases in general. Bugs are continuously deployed into the system and you never reach a state of doneness.

shkkmo 5y ago
They way I've run CD is we had continous deployment to a staging environment where final testing and stakeholder review happens, then periodic deployments to production. This works best when you do a good job of getting the bigger/riskier changes in earlier and do a good job scheduling other changes around anything that is time sensitive.
- undreren 5y ago
  > They way I've run CD is we had continous deployment to a staging environment where final testing and stakeholder review happens, then periodic deployments to production. As you hint at, it is called continuous delivery, not continuous deployment. The best strategy IMO is to mob with testers, and clarify how a thing will be tested before implementing it. It saves you a lot of headaches.
- konschubert 5y ago
  What happens next when feature A,B,C,D look fine in staging, but feature E is a blocker?
pjmlp 5y ago
I have had CI/CD pipelines, in offshored projects, where the amount of issues that would creep in was unberable, despite unit tests and whatever best practices. So for the teams to have anything at the end of the CI/CD that could be either demoed, or tested, multiple stages integration stages of green builds were introduced. A full multi-stage CI/CD integration pipeline from a devs machine, into what became known as diamant build, would take about a day, assuming all in-between-stages were green on first build.
- rualca 5y ago
  > A full multi-stage CI/CD integration pipeline from a devs machine, into what became known as diamant build, would take about a day, assuming all in-between-stages were green on first build. A day is indeed a bit on the long side, but CICD was never a synonym for instantaneous. Let's put things into perspective: staged deployments, or simple blue/green deployments, do require a baking period to verify if a new deployment leads to alarms going off. Depending on how you phase your deployment, that last stage alone can take hours. and that's deployment alone. If we look into it, unit tests barely register in the time that it takes a commit to go from git push to the client starting to use the feature/bugfix. I've worked on webapps deployed globally where unit tests took far less time to run than the baking time of a single deployment stage.

by Sevii 5y ago

shkkmo 5y ago

They way I've run CD is we had continous deployment to a staging environment where final testing and stakeholder review happens, then periodic deployments to production. This works best when you do a good job of getting the bigger/riskier changes in earlier and do a good job scheduling other changes around anything that is time sensitive.

undreren 5y ago
> They way I've run CD is we had continous deployment to a staging environment where final testing and stakeholder review happens, then periodic deployments to production. As you hint at, it is called continuous delivery, not continuous deployment. The best strategy IMO is to mob with testers, and clarify how a thing will be tested before implementing it. It saves you a lot of headaches.
konschubert 5y ago
What happens next when feature A,B,C,D look fine in staging, but feature E is a blocker?

pjmlp 5y ago

I have had CI/CD pipelines, in offshored projects, where the amount of issues that would creep in was unberable, despite unit tests and whatever best practices. So for the teams to have anything at the end of the CI/CD that could be either demoed, or tested, multiple stages integration stages of green builds were introduced. A full multi-stage CI/CD integration pipeline from a devs machine, into what became known as diamant build, would take about a day, assuming all in-between-stages were green on first build.

rualca 5y ago
> A full multi-stage CI/CD integration pipeline from a devs machine, into what became known as diamant build, would take about a day, assuming all in-between-stages were green on first build. A day is indeed a bit on the long side, but CICD was never a synonym for instantaneous. Let's put things into perspective: staged deployments, or simple blue/green deployments, do require a baking period to verify if a new deployment leads to alarms going off. Depending on how you phase your deployment, that last stage alone can take hours. and that's deployment alone. If we look into it, unit tests barely register in the time that it takes a commit to go from git push to the client starting to use the feature/bugfix. I've worked on webapps deployed globally where unit tests took far less time to run than the baking time of a single deployment stage.