Re: Usual DevOps bollocks
@bat
I think you might have missed a few key points here.
The “goal” is to automate and break out your monolithic applications into smaller, more manageable components. Have API connectors between apps etc.
Application X should never break Y through a change. In fact, application X should raise an error in the connector and Y should continue to work, albeit possibly with some reduced functionality for a time.
Testing still happens before anything is released, it’s just done as soon as the dev is completed so changes are rapid.
So an API not passing the pre-defined tests means it doesn’t go in, and doesn’t break the application.
Anything not caught by tests obviously is an issue - but designing the app to not fall over (through apis etc) means the risk is minimised.
Furthermore, a decent tech stack (git, Jenkins) means you can roll production versions back at the click of a button.
So X-2.0 might break Y, but you can turn it back to X-1.7 at the drop of a hat.
I used to be on the other side of CABbies, and they were 100% political nonsense.
Why do you need a defined meeting about changes? Surely any discussion about X and Y can just happen between the two or more devs who are involved? Else you’re wasting 20/50 minutes of people’s time who only have one relevant part in the CAB.
Biting the hand that feeds IT
