3 reasons why you should invest in Automated Deployments (AD)

Automated Deployments are simply website or software deployments which are done by a software process which is triggered by either code changing or a specific manual trigger by developers.

An example scenario is that when you check in code you are working on, it will be automatically built and deployed to an internal development environment so that project managers, other developers, clients, etc can all see the changes quickly and without having to wait for people to go through the often-painful process of copying files here and there.

CruiseControl.NET, TeamCity, Jenkins, Bamboo, Appveyor, and lots more are all software & services which offer automated deployments as part of their Continuous Integration / Continous Deployment environments, as well as other features such as automatic unit & integration testing and more.

There is a high cost to setup CI/CD/AD at the start, but this is easily offset during the life of the project by saving time of all the people who are involved.

Now let's get to it:

1) It saves you time, lots of time

You probably think that hitting 'Publish' in Visual Studio is an up to date way to deploy a web site. You click a few times then wait for Visual Studio to do it's thing and update the remote site. Depending on the site and the remote hosting environment this process might take anywhere from 1 minute to half an hour. You may even get to catch up on your blog writing while waiting for it to complete. Great huh?!

Nope.

If you need to continuously deploy to a development environment or are at the stage of a project (or team size on a project) where multiple deployments to an environment are occurring every day then AD will save you and your team members an incredible amount of time.

Let's look at an example.

If it takes you 5 minutes to deploy to a dev site and assuming you deploy to dev after each successful ticket you resolve, if you complete 10 tickets in a day then that's 50 minutes of your 7 hour work day that you have lost to waiting for deployments. Yes kids, 12% of your working day is spent waiting for deployments to complete. That's over 4 hours per week just sitting, waiting.

2) It reduces the chances of errors during deployments

If you're lucky, you get to hit 'Publish' in Visual Studio and then it deploys using Web Deploy. If you're unlucky then it writes a bunch of files to your HDD and then you copy-paste them through a Remote Desktop window to the server.

How can it go wrong?

Actually, it can go wrong in so so so many ways.

Automating your deployments means it will happen correctly every single time. And if something goes wrong then you can handle those scenarios in the same way every time.

It's a no brainer.

3) It reduces or eliminates the learning curve for new team members

"How do I deploy this?"

"Where is the server?"

"Do you have the login details? These ones don't work"

"I logged in and there were 34 sites with the same name but with peoples initials in the directory, where does the site go?"

These are all possible (and common) phrases heard by any developer who brings another developer on to their project to help out. Why bother with any of this?

With AD you have deployments to dev automatically when any code changes. You can trigger deployments to UAT or (gasp) Production with a few clicks and you also don't need to divulge sensitive infrastructure credentials to developers who may only be on the project for a few days or weeks.

Save yourself the pain. Just Deploy It.