Voice of the DBA

Tag: DevOps

Good DevOps Books to Read
I was interviewed recently at DevOps.com talking about the database as a part of DevOps. As part of the interview, Alan Shimel asked me for a book recommendation. After that, I decided I should recommend a few books that I’ve read and think have helped me to understand DevOps.

Tl;Dr: The Phoenix Project, The DevOps Handbook, Continuous Delivery.

The Phoenix Project

I actually read The Goal first, which applies the principles of DevOps, grown out of the lean movement, to manufacturing. The Phoenix Project is based on the Goal, but looks at Information Technology.

The book is a good, light read. It felt like a repeat of The Goal, but it cemented some ideas, and I enjoyed it. The guru character is a little overdone, but certainly the “Brent”, jack of all trades, the one everyone depends on rings a bell. I’ve been Brent in a few places, where I had to be involved in everything. While flattering, it’s tiring and annoying.

This is a good, semi-satirical look at IT projects that helps you to realize the somewhat silly ways we build and deploy software sometimes. A nice overview for DevOps.

The DevOps Handbook

I read The DevOps Handbook the most recently of these three. After looking for more information on how DevOps is evolving, and following the research of Gene Kim in talks and articles, I decided to give this a try.

The book is long, though if you read on the Kindle, you’re at the end around 70%. The rest of more details and additional material. It was interesting, using case studies and information from a variety of companies to explain the three ways that Gene Kim has postulated as the principles of DevOps. They are:
- Systems Thinking
- Amplify Feedback Loops
- A Culture of Experimentation and Learning
Those are discussed in chapters with examples of how companies implement these, along with the shift left and shift right concepts. I’d definitely recommend this one.

Continuous Delivery

I actually read this book first. Continuous Delivery was recommended to me when Redgate got serious about DevOps and DLM (Database Lifecycle Management). I was reading this as I attended FlowCon and had the chance to meet Jez Humble. That was a great conference, and I’d like to go back to another (or similar) one.

This book talks mostly about how CI, automated testing, CD, automated deployments, and other specific parts of good software development and deployment practices that come under the umbrella of DevOps. When you look for specific things to implement as you adopt DevOps, this is a good book to give you ideas.

Remember, DevOps isn’t a tool. It isn’t a think you buy or a specific way you do something. DevOps is an idea, a set of principles, by which you get better. If you have a way of doing that, no matter what you call it, others might call this DevOps.

Conversely, if you aren’t getting better, if you struggle to get software changes to customer, have quality issues, or stressed staff that don’t collaborate, it’s not DevOps, no matter how much “stuff” you do.
April 3, 2017
Including Your Database in a DevOps CI/CD Process

Abstract

DevOps is changing today’s software development world by helping us build better software, faster. However many organizations struggle to include their database changes with their application deployment. In this session, we will examine how the concepts and principles of DevOps can be applied to database development by looking at both automated comparison analysis as well as migration script management. We will cover using branches and pull requests for database development while performing automated building, testing, and deployment of database changes to on premise and cloud databases.

Level: 300

I chose 300 because you’ll need some understanding of how software development proceeds, be very comfortable with producing code and executing it on different servers, using a variety of techniques.

Downloads

March 31, 2017
Big Companies are Improving with DevOps

One of the comments I’ve often heard from people that work in IT and haven’t adopted DevOps is that the principles and changes required won’t work at their organization. Quite a few people think that only small, new companies, like Flickr and Spotify can use the ideas. Plenty of others look at only high-tech, progressive companies like Amazon and Facebook able to change.

That’s not true.

In fact, there are four Fortune 500 companies using DevOps, including a large (though young) bank, Capital One, and another, older one, WestPac. I’m not sure anyone would consider American Airlines or Hertz to be small, agile companies, though certainly they are in highly competitive industries and need every advantage over their competitors that they can get. I suspect that is the driving reason for many of these companies to adopt fast, quick software development. They can’t afford to have an idea take months to implement.

Those companies aren’t like yours? What about Maersk or Nationwide? Ticketmaster? Maybe Norstrom (and a few more)? I actually had the chance to speak with a number of Nordstrom employees that had taken a POC concept for the mobile group and proved that DevOps has value. From there, almost the entire IT department, hundreds of employees in groups from internal IT to mainframe to web, all have adopted various types of DevOps processes, starting with value stream analysis. Over a few yeasr, they have dramatically transformed their delivery of software. When someone in the business proposes an idea or need, it used to take over 6 months for something to get deployed. That’s down to a couple of weeks, and it’s released in a true, get-something-useful-to-the-customer fashion. This isn’t alpha or beta software, but a basic item that can be used and is then grown and changed according to customer feedback on a daily or weekly basis.

The transition to DevOps really requires some belief and understanding of the ways in which you can deliver better software, faster. This requires some slow growth, which seems crazy, but the the cultural changes take time, and even the technology tools you choose, require some patience, trust, and experimentation from your technology staff. While it might take months or even a year to get a DevOps process working well and one you’re comfortable with, the gains grow and grow over time.

Even if you don’t believe in DevOps now, why wouldn’t you try to get someone in management to set up a proof-of-concept and build something. It’s a small investment, that could have huge payback with limited risk. You’ll learn a lot and can then decide if it helps you delivery value to your customers in a better way. And if you do adopt DevOps, don’t forget to include the database in your process.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

March 29, 2017
Building a Database DevOps Process at the Data Platform Summit 2017

I’m heading to India this August for the Data Platform Summit 2017. I am honored to have been selected to deliver a pre-conference seminar called “Building a Database DevOps Process”, where I’ll walk through the way in which you can include your database alongside application code and deploy it smoothly to various other environments, such as test, QA, UAT, Beta, Staging, Pre-prod, etc.

If you are going to be in Bangalore during the middle of August, register for the DPS and come see my, or another, pre con as well. There are some great ones.

This will be my first trip to India and I’m looking forward to it. Actually my whole family is looking forward, as I’ll be taking a week or so vacation before the conference to travel with them before I spend a week at work. I should be acclimated to the time change by the time the conference starts, which is good. I’ve got customer training also scheduled, so a busy August for me.

Now to get a Visa and inoculations. Hope to see you there.

March 21, 2017