I’ve written this post because I have a pretty unique perspective on the deployment process. I sit on the outside of development teams, both at Red Gate and with customers, and I peer in. I speak to lots of people every day with the same issues. A surprising number of them think they are alone. They really aren’t.
Open disclosure: I am part of the Deployment Manager team… I am the sales guy.
It’s with this in mind that I’ve taken the time to share one of the most difficult (and common) conversations that I have with customers. It may sound familiar:
>> Hi, is that Joe Bloggs?
>> Yeah, who’s this?
>> My name’s Alex, I’m calling from Red Gate because you downloaded SQL Compare last week. How are you getting on?
>> Hi, yeah. It looks good. But we aren’t going to buy it. We have our own application for doing deployments. It’s been working fine for a couple of years now so we aren’t interested.
>> OK, thanks for letting me know. May I ask why you downloaded SQL Compare?
This is the point where Joe tells me that something went wrong. Joe downloaded the SQL Compare trial for a quick fix. It’s OK now. It’s sorted.
The problem with home-made deployment processes
Joe and his team have a custom application and process for deploying their software that some developer put together this one time and it works OK (almost) all the time. It was “free” because they did it in-house (I’m biting my tongue). OK, only that one developer knows how to use it (it’s hardly ‘ingeniously simple’), but it works, and it suits their particular peculiarities. This application may or may not include the database (Who cares about the database?). The application is fairly restrictive, but that is OK because Joe and his team can change the way they work so that they won’t break the release. And besides, modifying the release application is too scary (what if it goes wrong?) and too much work to bother.
But things do go wrong. And the first time things go wrong it comes as a shock. I’m sure Joe (or Joe’s manager) is fully aware of the cost of a bad release. It’s more than the cost of Joe and his teams’ overtime or the spike in the company’s coffee bill. If this gets anywhere near customers they could lose confidence. The company could even lose business. It could damage the brand. It will also delay the next bit of work. And most importantly, Joe had plans for the weekend!
If this isn’t scary enough, what happens if that developer who built Joe’s release process is on holiday or off sick? What if they leave the company? When that happens I tend to have very different conversations with clients.
The trouble is, Joe is a busy person. He doesn’t have time to try something new. “If it ain’t broke don’t fix it.” (But it is broke!?) There are other priorities. Joe wants to get back to the important stuff. Because as far as developers are concerned, the important stuff is anything but deployment, right? That is, until deployments go wrong.
Besides, that developer who built the deployment app swears by it. It’s their baby. Not many other people really understand it but they are happy to trust it and get on with the day job. So Joe will wait until it goes wrong again, and then will most likely have to buy a tool designed for the job anyway.
This may or may not sound familiar to you. Some people do have a great system set up. For example Annette Allen and Dave Green at FirstDataBank have detailed their Continuous Integration and code promotion model for us and Ben Adderson, who manages all of our releases at Red Gate, discusses how he improved his deployment process below:
Why automate your deployments?
By automating manual processes both examples demonstrate that less stuff goes wrong and more stuff gets done more quickly. Also, by using software that is supported full time you know that you won’t out-grow your release application and it will support the work you do rather than restrict it. By adopting an approach that makes your development/release process visible and maintainable by many people the business is no longer tied to the schedule of a single person. It will probably also be cheaper to set up.
Whether or not you decide to use Red Gate tools to manage and deploy code, please take it from someone who speaks to dozens of like-minded people a day:
- Developing (and maintaining) a tool that you build in house will be much more expensive than you expect. Especially when you take into account the on-going support costs. Besides, you can probably write a list of things that you would prefer to be doing than fixing a deployment process.
- Using tools that are maintained by a team of developers full time will be more secure than trusting something that was built in house by a developer as a side-project. Also, the tools will be far more likely to stay up to date and improve over time, supporting your development efforts, rather than restricting them, for years to come.
- Putting yourself in a position where there is only one person (perhaps it is you?) who understands the release process is unwise. The longer you leave it, the more it becomes an issue. (Besides, that one person who you are leaning on may well get frustrated at being called on their day off, in the middle of the night, or when they are trying to work on something else.)
Does this sound familiar to you?