Except it's not like that. At least that's from my experience and from from the speaking to people who work in enterprises.
DevOps has created a ripple and quite rightly so - we (developers) were sitting in silos cranking out code and blissfully unaware of the downstream carnage that can be caused.
But what is this big bang DevOps movement? We've all read the Phoenix Project and follow #devops but what are we trying to achieve?
We want to be DevOps
Damn you Spotify and Netflix - you guys are fantastic but you've put DevOps on the radar of the people who wear suits and that is causing devastation downstream in the engine room.
Yes we like what we've read and heard about DevOps but being told to transform into a DevOps organisation often seems like an impossible task.
You Can't always get what you wantWe want DevOps but what do we need?
But if you try sometimes you might find
You get what you need - Richards/Jagger
Well for starters, lets start with this one:
We need to deliver features faster
It's not uncommon for enterprises to release software quarterly - we want to release daily, if not hourly or even better - be in control of our releases and choose to deploy to live anytime we want.
What's the problem?
There are many problems, mostly down to the scale of the changes required at enterprise level.
Delivering faster takes discipline and cultural buy in and Enterprises have a lot of stakeholders. Getting everyone to buy into the dream is hard and it only tales one or two senior nay sayers to cause lots of pain.
The Enterprise may be based in the backend of nowhere - getting the right people that are enlightened is not easy. Many Enterprises chug along with sub par development teams churning out buggy software that doesn't do exactly what the business or customer want but this rubbish works well enough and is profitable enough to warrant not rocking the boat.
How can we fix the problem?
Success is the sum of small efforts - repeated day in and day out - Robert CollierFaster Delivery is the end goal and is a side effect of the sum of a number of small factors. We can create a ruler to measure where we are now and where we need to be in order to achieve our goal of delivering features faster. Here are some ideas to deliver software faster:
Level 1 - Basic building blocks
- Basic Agile Methodology followed
- Coding standards and peer review in place
- Source code is in version control
- Continuous Integration (CI) in place
- Unit tests run on the CI server
- Static code metrics in place (Code coverage, cyclomatic complexity, etc)
- Acceptance test behaviour written in common language between business and development teams (BDD)
- Test Driven Development (TDD) practiced
- Code pairing is common practice
- Code reviews in place
- Architecture is modular
- Time allowances for teams to work on dealing with technical debt
- Stable teams
- Test environments that mimic live
Level 2 - Intermediate progress
- Development Teams provide out of hours support for the features they own
- Software built with components
- Scripted one click test environment build
- Living documentation built from acceptance tests
- Database is in version control
- Integration tests run on CI server
- Monitoring awareness by all teams
- Configuration in version control
- Configuration as code in place for deployments
- Developers and testers integrated
- Culture of learning and self improvement, proper staff training available
Level 3 - Advanced progress
- Acceptance tests run on CI Server
- Automatic Performance tests
- Automatic database deployment
- Live systems monitoring accessible to all
- Infrastructure as code
- Software can be deployed to live with no downtime
- Zero touch deployment
- Development team integrated with operations team
Of course different enterprises will have different ways of operating so some of the above may not apply but everyone in the team has a very important role to play in delivering software faster.