Comment by Sevii | Hacker News Reader

Comment by Sevii | Hacker News Reader

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.

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.

> 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.

What happens next when feature A,B,C,D look fine in staging, but feature E is a blocker?

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.

> 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.

Reply on news.ycombinator.com