Slashdot Mirror
Time To Move on from DevOps and Continuous Delivery, Says Google Advocate (zdnet.com)
A reader shares a report: Continuous improvement and continuous delivery (CI/CD) and DevOps may be on many peoples' minds these days, but there's nothing particularly new about the concept -- software shops should have put these concepts into action years ago. Instead, technology leaders should be now worrying about the futures of their businesses. That's the view of Kelsey Hightower, staff developer advocate at Google Cloud Platform, who says too many IT leaders are debating how to manage IT operations and workflows, when their businesses are being hit with unprecedented disruption. "CI/CD is a done deal -- like 10 years ago it was a done deal," he said in a recent podcast with CTO Advisor's Keith Townsend. "There is nothing to figure out in that domain. A lot of people talk about DevOps, and there may be some culture changes, in number of people who can do it or are allowed to do it. For me, that is the table stakes. CI/CD, DevOps; we have to say, listen, figure it out, or go work with another team outside this company to figure it out."
So somewhere along the way people figured out again that quality of software is more important than the speed in which new features are pushed out the door.
I guess the cranio-rectal inversion over devops crap is finally coming to an end.
Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.
I have chickadees at my birdfeeder but instead of making normal chickadee sounds they go "chick-a-DONK-DONK-DONK". And a lot of the time if you're coming or going they fly at you and attack you with their little beaks like miniature kamikaze pilots. And if they miss you they circle back and shit on you. I'm starting to think the little f**kers have bird flu or something, I've never seen chickadees out for blood like this. Hell, they're usually friendly little guys. I think I'm going to get some of those sticky glue mouse traps and mount them on the bird feeder, see if I can catch some of those bastards. I wonder if they could have cross-bred with killer bees and made some kind of 'Africanized' species? Maybe I should try to catch a specimen.
I have yet to see to a CI/CD shop actually implement this in such a way that people can safely commit away.
I'm sure life is easier when you don't actually have customers that care about state or you just shit on your customers continuously. Google wins on both counts here!
I just started reading "Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript" by Harry J.W. Percival. Now CI/CD is obsolete.
With Amazon Lambda and other microservices, you just need HR to hand out IAM accounts, and a company really doesn't need an IT staff whatsoever. Just some CI/CD mechanism to get pushes in production, and that is basically it.
Ops is dead. Who needs to rack and stack physical servers when the cloud takes care of that, and far cheaper. Who needs OS guys, app guys, net admins, and DBAs when serverless services replace all this?
Lets be real... the future is NoOps. Pay your Amazon bill, and they take care of your IT infrastructure.
I've always felt that integrating and keeping up to date test automation processes as the greatest challange in the CI/CD space. As business cycles get shorter, creating and maintaining the required set of test automation processes that can give you confidence in the final production release can be an immense challange. This together with the increasing complexity of cloud based systems has made the testing challange a really hard nut to crack.
So whats the new buzzword?
Sorry, but if the projects you worked on had no integration tests, that was a problem with you and your team, or possibly the whole organization. Where I work, we have both unit tests and integration tests, not only for application code, but also for the code we use for system administration/orchestration/automation, and also for the code that supports the development environment (i.e. devops tooling).
It can certainly get difficult, but saying that DevOps has no testing is too sweeping a statement.
Oddly enough the latest Humble Bundle (owned by IGN) is about cloud computing.
https://www.humblebundle.com/books/cloud-computing-books
I'll just leave this here : Human error caused Amazon Web Services outage, Apple iCloud service issues.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Traditional development cycle -Ready, aim, fire.
Lean - Ready, fire, aim
DevOps - Fire, fire, fire, fire
Unit and integration level tests are not enough by themselves as the gap between the systems these tests run on and the actually production system is too great, and with the complexity cloud deployments allow this gap is growing. Yes, you can run a set of smoke tests in production but that doesn't hide the fact that most of the testing is not performed in a realistic environment.
Someone has been reading too many issues of CIO magazine between rounds of golf!
Either that or this was a good troll. Either way... cloud is never cheaper for non trivial deployments and work loads. Period. If your cloud service is cheaper for real work then you're seriously incompetent and going out of business soon anyway.
Who is taking the 3am call when shit breaks? Your developers? They checked out at 3:45pm, went to the bar, did the deploy to production from there, got super drunk and passed out.
NoOps: more silly shit from people who never worked in the real world.
Too funny!
Now your customers say, 'where's your mobile app? I want to be able to have voice assistance to talk to your particular product.'
Is that really true? I thought apps were mostly a dead end now, and everyone is just writing for the web. Do people really want voice recognition in apps?
"First they came for the slanderers and i said nothing."
"With Amazon Lambda and other microservices, you just need HR to hand out IAM accounts, and a company really doesn't need an IT staff whatsoever. Just some CI/CD mechanism to get pushes in production, and that is basically it.
Ops is dead. Who needs to rack and stack physical servers when the cloud takes care of that, and far cheaper. Who needs OS guys, app guys, net admins, and DBAs when serverless services replace all this?
Lets be real... the future is NoOps. Pay your Amazon bill, and they take care of your IT infrastructure."
You sir, are a moron. This is the crap that PMO/MBA wannabe's push to C suits to get into Director/VP promotions and once it's done, they bolt. Anyone who says DevOps or Cloud as a term to solve a companies problems is going to blackhole the company. Unless you're a mobile app provider with 1-2 products, you don't do that. All Fortune 100 companies user Ops and even some Cloud and some DevOps, but in percentages where they work.
Next person that says web-scale......
Unless you go the Netflix route and do tests in production.
I wouldn't hire someone stupid enough to publicly say what you're saying here to work on my team. Good sense is important in any developer.
A certain generation and culture of developers always praise continuous delivery to the heavens. Implying that *every* commit should be stable, bug-free, extensively tested and released.
But on every single project I've seen, it results in the opposite: Permanent instability.
No version is allowed to mature anymore. None!
Yet everyone involved can't admit to having been wrong, and so the whole thing turns into another Cult Of (Riding The) Dead Horse.
And for everyone with a bit of brains, it is blatantly obvious why that is: The snapshots *aren't* tested to an acceptable level, in the real world. Because the next one would be finished earlier, or if blocked, development would slow to a crawl.
In the time you have, you can only test *some* snapshots. And if you care about stability, you can only release those.
Continuous delivery and stable software are mutually exclusive.
I wouldn't hire someone stupid enough to publicly say what you're saying here to work on my team. Good sense is important in any developer.
For all you know, lucm is working for you right now.
. . . because, sooner or later, DevOps HAD to no longer be the New Hotness. . . Of course, the question is. . . what comes next ?
I think the complaint is developer written tests of their own code is frequently considered a replacement for an actual QA team, whether unit or integration test.
One of the *massive* gaps is if the developer is batshit crazy and designs horribly because they are not the target audience and do not understand the target audience, the tests are going to sail on through and be horrible because no 'mere mortal' could check that developers bizarre vision. Also a developer can be plain dumb and think the wrong thing and make tests that only will pass when a broken implementation is thrown at them.
The biggest problem is the buzz of CI/CD brands developers in general as infallible. CI at least is a good idea in and of itself to augment a process, but the collateral damage of how those words are interpreted by management is severe.
XML is like violence. If it doesn't solve the problem, use more.
While I agree with you that good test automation is challenging, I would say that it is no worse than on-premise product development. Effective testing requires engineering commitment to make test automation development co-equal with product development. It is an immense challenge. BUT, having worked CI/CD for both an on-premise product and a cloud-based (AWS) product, cloud seemed easier. If for no other reason than it is much easier to manage the equipment.
He says the battle is over and DevOps won and people need to move on to the next thing, not that people need to 'move on' from it in the sense of rejecting it or forgetting about it.
This was my internal code name for that thingy, after it married the rampant bureaucracy at $WORKPLACE and begat a monster.
Before, I'd been doing it all the time, but the code name was different:
configure && make && sudo make install
This one Just Worked (TM).
The moral of the story: it's not the tools, but how you use them. Don't buy a $24 hammer if you can't use a $2.49 hammer.
So use System Tests as well in your Continuous Integration setup. Have you never heard of them ?
Not strictly true. If you have a globally applicable product that must nonetheless comply with local data residency and access rules then cloud services let you deploy globally without needing a complex fragmented physical estate.
For regions with sizeable footprints there will be an inflexion point at which self hosting makes commercial sense. Even there I'd constrain the solutions to the same deployments used in the cloud, for dev and ops simplicity.
CI: Continuous Integration (in this context)
CD: Continuous Delivery
CD: Continuous Deployment
(Yes, I, too would like to punch whoever picked a second word that starts with D; it's probably the same guy who gave us Verification/Validation and Authentication/Authorization.)
Continuous Integration means not having code hanging out on an isolated branch for more than a day or so: instead, it is continually integrated into the main branch (master, trunk, etc.). People started calling automated build servers "CI Servers" because they're very helpful in supporting CI, but that means many people now think "CI is what CI servers do," and so someone had to go and invent "Trunk-Based Development" as a term for actual Continuous Integration.
Continuous Delivery means very frequently giving your organization a system that's of high-enough quality that they could deploy to production if they wanted to. Dave Farley and Jez Humble wrote a book on this; go read it.
Continuous Deployment goes one step further and actually deploys that system to production. This turns out not to be crazy if you pay a lot of attention to quality in your pipeline.
Human QA is still a valuable part of these pipelines, as is actual customer involvement. Automated testing is a way to take the load of repetitive testing off the shoulders of Devs and Testers, so they can do things that require actual human thought.
Yes, I know your dysfunctional organization screwed these things up horribly. Consider getting another job instead of bitching about good ideas.
Is gmail out of beta yet?
Or do they still have 3 outages a year?
Agree.. Its time we stop coddling older devs who still live in the days of siloed responsibilities and push them out of the best. Devs who can't be cross functional arent really devs.