So while browsing another site, I found a very interesting article that sums up a lot of my thoughts on CD. Rather than copy and paste (and mistakenly get credit for it), I thought I’d add a link here, and get others’ opinion on what John Tyson wrote.
Somewhat yes (aka “It depends” …)
Often I work on projects around
- public service workflows, which is mostly driven by law implementation
- enterprise business systems, which is mostly around process automation
- regulated pharma documentation, which is driven by … regulations and GxP practices
It will take a long long time for these organisations to change to be agile, as it’s a mindset based on trust. (and trust me some org’s aren’t trusting vendors). But on step at the time yes, as discussed here: How to build agility into a regulated project?
Sometimes agile & CD is management’s (wet) dream of a quick-win towards time-2-market, where skills and collaboration are neglected. don’t do that, is really the articles key message:
If companies feel they can replace professional software testers completely with automated tests, I think we know the answer. While continuous deployment has the potential to be a very positive trend, never underestimate people’s propensity to misuse a good thing.
Exactly, but it also implies that there is, then, a basic lack of understanding of the roles and skills a team member brings to the table, and the importance of those skills in the SDLC. I’m seeing a worrying trend to again cut testers out, and migrating them into other roles. One proposal I’ve seen migrates testers to scrum masters, another forces them to become a lot more hands-on technically (becoming performance or UX testers), while still being responsible for the testing of the application in name, but having all actual power to halt a deployment or release removed from them. I think that CD is a step in the right direction, but perhaps it is not being viewed correctly across large chinks of the industry?
I work at a company that has moved to CD of some backend services, but not anything on the frontend. We use several tools to help with the CD pipeline (with more on the way) - and it is compelling to see how quickly fixes and features can get to production.
We’ve solved one problem this article seems to be bringing up (the lack of value seen in software testing) with one simple addition to our processes. For CD services, on the pull request, it cannot be merged without the approval of a member of the QA team. Whether it’s a trivial or major change, code cannot be released to production without someone on the QA team having looked at it first. We aren’t being a gatekeeper, so much as being seen as a valued and necessary member of the team - so much so that the engineering leadership recognizes that new code should not go out to production until QA feels confident that it’s safe.
It’s worth checking out this topic about the same post
I’m going to let my cynical side out for a while here and make two statements that I’ve found to be (unfortunately) extremely accurate.
- There is no good practice that cannot become a Worst Practice when upper management is sufficiently determined to locate a silver bullet.
- Sufficiently advanced ignorance and folly is indistinguishable from malice.
Continuous deployment handled correctly can be fantastic. Continuous deployment with Dilbert’s Pointy-Haired-Boss in charge (or one of his many, many fellow travelers) is a nightmare of Lovecraftian proportions just waiting to consume the souls of the unfortunate developers and testers caught in their tentacles.
Very true- I wish that people would stop and think about “silver bullets”- they only work on werewolves, not on IT problems.
I think that there may also sometimes be an element of actual, real malice involved- “I’ll teach you to interfere in my plans…”
I may just steal those two lines for a presentation I’ve got coming up!
When I join a team as a tester I am usually pushing towards a continuous deployment pipeline. To me it makes testing more valuable as to succeed you need quality checks at every stage. So when the article states
some companies are moving away from having their software tested by professional software testers
I think the author is either undervaluing the testing that can be provided by developers and automated tests. Or is overlooking just how much testing thought is required for a successful CD pipeline.
Remember, not all tests can be automated.
Sure. The test those manually when they change and put that check into your release pipeline. Also add appropriate telemetry to the live product so that if users are having issues it can be quickly detected. And make live releases staged so you don’t knock out 100% of your users with an un-caught issue.
Without CD you still will miss things and will still release bugs. But it will take weeks (or more) to get a fix out or require you to break all your quality processes. CD is not just about getting product out the door quickly. It’s about getting feedback all the way back to developers. A broken CD process being a worst practice doesn’t prove anything
I reread the article 4 times now. I thought about responding to most of the points made by the author, but then I decided against it.
To any tester that wants to write about Continuous Deployment I would suggest working at least for 5 minutes in a CD context before writing an article on it.