This is the first part of a story, a story about how important it is to have a reliable release and deployment process.
Anyone working in our sector has had to deal with deployments. I’d like to launch this series with a bunch of interesting questions that will let you know whether you should change your deployment process.
Are your versions being managed manually?
The answer should be a clear no. Not one version, NOT ONE, should be manually specified by a developer. A decent continuous delivery process should handle this. Even a new project should be created from your continuous delivery process giving you a common base for the whole company. It could be a “.pom” with basic dependencies (common testing frameworks for example or static code analysis ) or a “.sbt” file, but this should be mandatory. My recommendation is: Do not create or release versions manually, ever.
How many developments have you finished without testing them in a production-like environment?
The answer should be none. This is a basic and common mistake that we all fall prey to. We have all seen tests running in a non-production environment, but these can’t show real errors. You can’t adopt a wait-and-see attitude in which a development is only really tested when it falls the hands of the user.
Imagine if Google deployed software changes in production before testing if they really work. It would surely end up in a lot of people switching to duckduckgo! The solution is to certify environments. It’s important to take one’s time, use one’s money on this. The first time you do it, you will realize how important it is.
How many times have you deployed software manually?
The answer should be never.
Well, it’s 4 o’clock, and you are thinking about having that huge Starbucks (or other) with your colleagues… and then a wild deployment appears! Someone comes to your desk and asks you to deploy “the project”. First of all, what on earth is “the project”? Sometimes even the versions you need to deploy yourself are not well-defined, other times you have no documentation about how or what to deploy. In the best of cases, you have a document that tells you how to do it. But even if you are that lucky, you probably (or certainly) have to face other problems, like inaccuracy or outdated documentation. And even if the documentation is perfect (wow! very lucky day), you are only human so mistakes are possible!! Maybe, after tons of hours, you will end up knowing what to deploy and how to do it, but wait… I said YOU!! so you are now a huge SPOF, the whole project depends on your presence to go into production… No way dude!
Which questions should you ask yourself to deploy a piece of software?
This is an easy one. You should only need to answer two questions if you are playing this game as it’s meant to be played: Which version shall I deploy? Where shall I deploy it? Questions such as “where is the documentation?” or “which team did this?” should not be necessary. If they are, then something needs to change!
After a deployment, do you need to set everything up?
Last but not least: configuration. Yes the black beast, the thing that, even if you have successfully answered the previous questions, even if you are the hero of the day, the employee of the month, the mother/father of dragons and whatever you want… could make everything fail. An IP number mistake could be fatal.
Well, I hope you are all scared and saying “O RLY? Am I doing all these things wrong!?” because the first step to correct a mistake is to point it out and be aware of it. In the next chapter we will go over good practices to improve releases and deployment processes.
