The most efficient way to deploy your code & the tools you should use. Stack Overflow share their approach.
Tags: deployment, webdev, devops, productivity
Published: 2018-06-05 08:41:03

---
title: The most efficient way to deploy your code & the tools you should use.  Stack Overflow share their approach.
published: true
description: The most efficient way to deploy your code & the tools you should use.  Stack Overflow share their approach.
tags: deployment, webdev, devops, productivity
cover_image: https://thepracticaldev.s3.amazonaws.com/i/rddjrfq1eddi847o9unw.jpg 
---

It's a major part of coding, it's all good it working on your machine, your version of SQL, your local single IIS box, but how do you take the single web site and get it out to the general public, or out to your testers?

What's the most efficient way, what requires the least amount of headbanging to get to work. It's a question all developers have to face at some point. It's always best looking to others, rather than trying to re-invent the wheel and who better to take a look at than the behemoth that is Stack Overflow. It has millions of users a year and they've detailed fairly comprehensively their approach to deploying their code!

There is a lot of variety in the Automated Deployments right now I've been reading about the subject and <a href="http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/">here is a great blog post from Stack Overflow </a>and how they go about this mammoth undertaking. They make a number of good points and give a very detailed explanation into their process.

Are you new to the ALM Lifecycle? Do you want to start Continuous Integration of your system, but don't really understand the concept or how it can benefit you and your product? Well there are multiple benefits to Automated Builds and Deploys, from my own experience I would say the most prominent reasons behind following such an approach to being:
<h2>Anyone can Deploy</h2>
The worst thing with a standard deployment structure, is that certain people do certain jobs. The infrastructure team will usually be tasked with deploying code across to all our environments. But what if they are away, or busy with other tasks? Should your deployments really be handled by real people? With Automated Builds and Deploys you remove this constraint from the process. You can deploy whenever you want, from wherever you are, and by whoever has the privileges to approve such a decision.
<h2>Less Errors, More Repeat-ability</h2>
It may take a little while to get it up and running, especially successfully, but once this hurdle has been overcome then Deploys will no longer contain human errors, and they can be run as many times as you want, whenever you want.

You may have made a little text change somewhere, and want it pushed out, it's a Saturday/Sunday. Continuous deployment doesn't care, press a button and watch the magic happen!
<h2>Developers and DevOps spend their time doing their job!</h2>
Developers and Infrastructure will spend more time together getting this process in place. It's integral the the current process is correctly defined and transformed into the automated process. This will require lots of trial and error, setting permissions, testing firewalls, creating re-runnable Powershell scripts and even ultimately automated sanity test scripts.

This will free up time to look into the crux of the release, how to keep adding to it, optimising it, making it faster, more efficient, and ultimately give time back to the people that have more important thing to do then copy files from server to server!
<h2>Release more often</h2>
In addition to this, as there is no overhead to releasing code once the automated process is complete, it also means you're in the the fortunate position that you can release code more often. Just made a change? Checked it into TFS or GitHub? An automated build kicks off behind the scenes and then release that version whenever you are ready, or schedule it in for any downtime planned that day? No longer do you need to wait for a resource and take them away from what they were doing. The benefits are HUGE!

So, what are you waiting for? Start looking into solutions now? My motto is always to start SMALL and SLOW! Don't tackle a massive legacy project from the get go. Have you got something smaller you could practice on? Maybe an internal application that gets released once in a while. How about creating an ALM Lifecycle solution for this? Then using what you have learnt, start working on your application and see how far you can get!

There are a number of other tools you could use for Automated builds &amp; Deploys, these are probably the most popular right now, I've linked to each so click through and see which would benefit you the most.
<ul>
 	<li><a href="https://msdn.microsoft.com/en-gb/library/ff650529.aspx">TFS</a></li>
 	<li><a href="https://www.jetbrains.com/teamcity/">TeamCity From JetBrains</a></li>
 	<li><a href="https://www.docker.com/what-docker">Docker</a></li>
 	<li><a href="http://www.tutorialspoint.com/jenkins/jenkins_overview.htm">Jenkins</a></li>
 	<li><a href="https://octopusdeploy.com/">Octopus</a></li>
</ul>
<strong>To read the full article follow the link here</strong>: <a href="http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/">How Stack Overflow do deployment 2016</a>

Let us know what you think below the fold, if you've had any positive experience from any specific products or services. We're all here to learn, and as the saying goes, there is no point in re-inventing the wheel, if there is a good approach that fits your requirements, you should probably use that.