DevOps is actually a thing – and people are willing to pay for it Is DevOps actually a thing, or just the latest funny way to case a word? At least there are vowels in it. We finally know the proper casing, but is it actually something normals are doing? Right after the cloud horses left the barn some years ago, this mysterious notion of "DevOps" surfaced. DevOps started as a rallying cry …
"The idea of releasing code to production more frequently is certainly appealing"
Is it? As a user and a developer I'd say the opposite: fewer releases with much deeper testing beats having to worry about 10 significant updates in a month, let alone a day.
I'm all for security patches, but I'm all for considering whether what you've just done turned out to be a good idea after all. Many CI-trumpeting projects just seem to be a pile of scar tissue and I know in theory there should be no relationship between the frequency of releases and the quality of integrated (as opposed to unit) testing, but there is.
For a consumer product where functionality beats security, I see where CI adds something.
But for corporate systems handling financial or regulated data, CI looks like the end of any credible code review or authorisation for changes. What stops someone adding their own dodgy code to a component and seeing it automatically pushed to live?
CI != "automatically push to live"
CI is having processes in place such that you can be confident that you can always push to live without breaking things.
We do things on a 2 week sprint cycle, which means every task, change request or feature we do must be fully complete, tested and deployable by the end of those nine days (or it gets re-scored for the next sprint).
Once the sprint is complete, on the tenth day we demo the completed tasks to the commercial team, the maintenance team and then release to live.
During the sprint, the maintenance team will make as many maintenance releases they need, all also underpinned by CI - or they might kick things back to us if we broke them in the previous release.
"We do things on a 2 week sprint cycle, which means every task, change request or feature we do must be fully complete, tested and deployable by the end of those nine days (or it gets re-scored for the next sprint)."
Except when the client or management say that it HAS to be patched up and out the door for the trade show or that there's no more money left and we have to go with what we've got (plus a little unpaid overtime).
There's nothing special about the idea that development is "fully complete, tested and deployable" by a deadline. What agile does is create completely artificial deadlines that ignore the reality of what's going on in the company and the marketplace.
My experience of it is that it doesn't really insulate the dev team from any of the normal problems with budgets running out or holes being found in specs or what have you. In fact, it's made almost no difference to how I develop other than to dramatically increase the number of meetings with stupid people I have to attend while still drinking my first cup of tea of the day.
CI doesn't do anything interesting at all, as far as I can see. "you can be confident that you can always push to live without breaking things" is tautology. What is it you're confident about pushing? Stuff that's been tested! Well, duh!
Except when the client or management say that it HAS to be patched up and out the door for the trade show or that there's no more money left and we have to go with what we've got (plus a little unpaid overtime).
Yes, every two weeks we re-evaluate everything we are doing to determine whether it is still worth doing more work to that for the business (not us). We tell the business how long it takes to deliver quality, so if we haven't got enough time to deliver quality, either we've been slow or we're bad at estimating.
Given we are only estimating tasks that take less than 2 weeks, you really can't be that far out. And if the feature you're working on was scored for "2 days work" (thats not how we score things), and it takes 10 and is still not done, then you either didn't get enough details from the project owner (hence his fault - the job of the project owner is to give well specified tasks to the team), or the task is overly complex and should be re-evaluated anyway.
Before you move to a scheme like this, you have to have buy-in from all the key stakeholders , so that when that trade show rolls around, you can easily say "No. This was not agreed on. If you want us to work on things, you have to present it through the project owner who will prioritize your requests alongside everyone elses.".
I've happily said this to C-level execs, they agreed this working model. This shifts the discussion about whether you do something away from your team; it's then a business decision, and they can horse-trade all they like in order to change what you do *next* sprint - no-one can change what you do *this* sprint.
"What stops someone adding their own dodgy code to a component and seeing it automatically pushed to live?"
The same thing that stopped them before!
CI doesn't mean automatically pushing to live and it doesn't mean the end of code review. In my experience it actually makes code review much more meaningful. Your validation stops being "hand it off to the test team and wait" and becomes a matter of waiting for your own team to tear it apart; the tests of course having already passed. In Agile land even that final validation doesn't allow something to release - that power lies solely with the product owner.
Done well it's a very graceful system.
I'm also not surprised at the 28% of people not doing CI. A fair chunk of software devs who'd report themselves as having "devops" on the team isn't really suitable for CI. How do you do TDD for exploratory analytics, for example?
I presume this is tightly linked to having a mature agile development and automated testing processes in place?
Is anyone doing this with short bursts of waterfall?
I find the concept intruiging - Im not sure it can be any worse than 3 months of impenetrable shite going live all at once. I presume it all depends on development and testing discpline. If you fudge your SIT and UAT (as so many do) you will be screwed no matter what.
Does anyone have any feedback to how well userland adjusts to these kind of cycles?
Whats the typical end to end from requirement to go live?
The words abbreviated in the "DevOps" are "development" and "operations". In our organization it's a group of people with experience in development and experience in operations who bridge an all-important gap between the application developers and the systems administrators.
We standardize and automate system, application, backup, and monitoring deployment a lot to leverage the work of our systems admins. We also explain the hardware impacts of application code to the developers who sometimes forget, and explain to the systems staff why sometimes they do need to provision hefty hardware for a project that just can't be handled by less. We don't need to hire developers and make them administer systems or hire administrators and have them also write code, because we have a team specifically to bridge that gap.
I'm not in a DevOps team but there is a fairly sizeable one in the company I work at.
I recently sat through a presentation on how the DevOps team have setup their own architecture and it was the mother of all bundles of duct-taped cats!
They had hundreds of individual web servers with a one to one relationship to an application server.
Each application server only ran a single app and each app had a number of point to point connections to other app servers as well as back end infrastructure.
Absolutely no thought to scaling (except though more VMs at it) or performance outside of individual components.
They recently had an outage as the load of connections spread across two data centre sites were swamping the load balancers.
This was my first exposure to a DevOps environment so it may be affecting my view of the process as a whole, however I think that the majority of people will never be good at multiple roles but will never admit it.
The one thing that I did like was that whoever made a code release was on oncall support for the next 48 hours so there was a lot of incentive to make sure it wasn't going to fail.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
