Thanks to Grant for hosting this month’s T-SQL Tuesday found (http://www.scarydba.com/2017/06/06/t-sql-tuesday-091-databases-devops/) where it is a chance to share our DevOps stories. I am not going into specifics of databases but I am going to write about it more generally.
What is it?
Some do it, some don’t, others may have not realised that they have done it. I fall into the latter group. Taking a step back DevOps (quoting from Amazon) “is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity” .
Now going back in time there was a short term tactic to group a mix of Developers, DBAs (Me and others), Middleware specialists, general Infrastructure and testers together to form an “A team”. This team’s goal was to develop, optimise and deploy a new platform for the company which was really successful.
Traditionally we would be very” SILO”, what this new approach did was bring us to together and really optimise the interaction and communication piece and from that everything else “just worked”. Honestly it needed a cultural shift to embrace these changes but the long term effect? Successful delivery of IT solutions.
- Developers had IT infrastructure (environments) more quickly to develop code.
- Various members across Operations would help with the automation of shared infrastructure for the developers.
- We would work together better to optimise code – What is easier then turning around and saying “Hey Dev, what’s with the HEAP?” Or “Dude, you are writing to the wrong Queue change the config file” – do you know how long something like this would’ve taken in the SILO world!?
- Continuous testing to get immediate feedback from a release, whoops, looks like I got the wrong .WAR file.
- Talking about software releases, source control tool is important.
Ok I lied, I have to talk about databases. The biggest advantages I have found with this “philosophy” is the idea of database version control. It has helped us by making code shareable with everyone within the team, when we make changes to financial tables we need a good audit trail and finally we have somewhere to go to in case we need an older version of a something like a stored procedure.
This wraps up nicely and can be summarised by the following diagram.
All the above while we were being watched by a someone in management (like a Coordinator) offering us support and free Starbucks.
It just worked for us, but you need the right people.
Pingback: T-SQL Tuesday #091 - Round-Up - Grant Fritchey