In this article there is no difference between the process of deploying and releasing. There are tools that will separate these two events which I do not cover in this post.
One thing that a lot of developers and IT departments don’t utilize is small, automated deploys. This is wonderful to have when writing and maintaining software. It helps with the cycle time to get software in user’s hands, turns deploying into a non-event and makes the process auditable.
Most people know and understand that building the software takes a lot of time. In fact, a lot of studies have shown that software spends most of its time in maintenance (meaning after the initial deploy). So what good is an automated deploy for cycle time? First, as a developer once you hit the deploy button there is nothing stopping you from working on something else while the software is being deployed. Once you are at the point of deploying the software you don’t have to think about deploying it. Your mind is free to start focusing on closing your current task and starting up your next task. Second, since most projects spend so much time in maintenance mode bug fixes and new features have to get deployed to this system. Do you want to have to manually deploy each time a bug fix or new feature is ready for production?
Imagine working at a company that interrupts the entire company when a weekly deploy is about to take place. This kind of deploy is all too common and can include hundreds and even thousands of lines of code that have changed. Multiple systems and applications have probably been altered and modified. Before the deploy, the team of developers are each assigned a department to speak with and stand by if they have questions during a deploy. Members of the various teams need to quit what they are doing and wait for the deploy to finish since what they are doing may not work correctly while the deploy is happening. As is often the case with really large deploys, something breaks and a rollback is needed. Hours later the problem is identified and corrected and a deploy is attempted again. Once again the teams and organizations must stop what they are doing. Seems cost effective to have everyone in the company waiting a deploy right? This may happen over and over until the deploy succeeds.
Contrast that scenario with making a small change to your software that is only 20 or so lines of code. If you deploy the software and something breaks you will be able to find the problem very quickly. Small changes of 20 lines don’t normally affect the entire system and so the whole company doesn’t need to watch and wait as the entire system is down. The company doesn’t lose so much time trying to be productive. Calendars don’t need to get marked to let everyone know when the deploy is happening. In fact, with small deploys most people don’t know the software even changed.
Deploying software can be a very complex problem depending on your system. Ever had a person in the company that has all the answers? Heaven forbid, but what if they get a new job offer and leave? How difficult would your next deploy be? There is nothing worse than having a single person knowing how a complex process like deploying works and they don’t have documentation or even up to date documentation. Deploying manually also has the risk that a step might be missed or happen out of order.
An automated deploy doesn’t have these issues. An automated deploy script serves as living documentation. It should be version controlled. When something needs to be altered in the deploy, you can change the script. You can also measure and improve the deployment process. If a new developer or system administrator joins the team they can be brought up to speed on how deploys happen by looking at the deployment script. They can quickly find out what technologies are being used and how the process is deploying. The script will always deploy in the order you tell it. If someone leaves your company you don’t have to worry about getting software in user’s hands.
If you found this useful I also have a personal programming blog at www.ericbulloch.com