A little background...
I'm a .NET developer by trade. I've been developing .NET applications almost as long as .NET was a thing. I've been tinkering with systems automation in some shape or form for most of my career, but really only stumbled into an official job title by accident when a client asked me to become a player on a DevOps task force for their ebook ecosystem. For the past few gigs, I've been playing around with Continuous Integration (CI) and (CD) Continuous Deployment of scalable applications in .NET environments.
There's a lot I didn't know about DevOps when I got started, and a lot I still don't know. I've tried to keep notes along the way to look back on and remind myself from time to time what I've learned. Much of which I sorely wish I'd had someone to show me rather than have to find the information the hard way. I'm going to try and distill my notes to the important pieces in the hope that they can help other .NET developers cross the chasm and begin to understand the DevOps world.
From the projects I've worked with, it's become evident that there's a lot about continuous integration and deployments that developers are either shielded from or are ignorant about - details that our projects would benefit from greatly if we made certain deployment considerations at the initial design of our code. These considerations are rarely asked of developers when writing their code, if they were, it would make our builds and deployments 100 times easier, would make our applications more production ready and in many cases make them more scalable too.
In the next few blog posts I will try to break down each of the pieces necessary to deploy production ready application and the considerations required to form a coherent deployment strategy.
I cannot obviously cover every tool you may use in your production environment, so I have picked a couple of easily accessible off the shelf tools that will cover the main paradigms and hopefully help you to bridge the gap between your development knowledge and what is needed for deployment. The paradigms are very similar across most deployment tools, once you understand one, the concepts are reasonably easily transferable to others.
The tools I'm going to be using for this blog series are:
- Visual Studio 2015 - There's no real dependency on this version, if you've got 2013 or 2010, they should be perfectly adequate to get you through this series. I don't think there's anything inherently 2015 that I depend upon [though perhaps if I do, people can comment].
- GitLab - Obviously you can use GitHub, Git, TFS, SVN or whichever source control system you enjoy most or are using in your environment. I made the leap to Git from TFS and SVN a number of years back and it's now my source control system of choice. I like GitLab's features for my personal projects. It's freely downloadable from gitlab.com
- ProGet - ProGet is a commercial version of NuGet available from Inedo.com. You can easily use NuGet in place of this - or even shared folders if you wish. My reasoning for using ProGet is that I enjoy the facility to host multiple managed feeds in a single intuitive professional user interface. You can use the Free edition for your own projects. The basic license is easily capable of supporting many enterprise ready development teams and the licensing cost is very competitive.
- MSBuild and Jenkins - Jenkins is open source and has relatively comprehensive installers for every major platform, making it easy to follow along regardless of your choice of build and deployment platform. Their plugin ecosystem maintained by a highly engaged community makes this a highly accessible build system. The bulk of your necessary understanding will be less about Jenkins and more about the structure of your project build target files.
- Octopus Deploy - Octopus Deploy is fast gaining traction as an industry standard for deployment and with their rapid pace of releases, highly engaged support team and community and competitive licensing model, this is arguably the most accessible deployment system on the market at this time. The community edition is more than adequate for personal projects or proofs of concept. For enterprise systems, most clients I've worked with have yet to stray beyond the $5,000 (at time of writing) Enterprise Edition. The price may seem high until you compare it to the competition and find that it's really miniscule... especially when comparing to offerings from companies like IBM's UrbanCode. Not that I'm knocking UrbanCode, it's an excellent product and there is much value in it.
I want to emphasise that these tools are just that, there's nothing inherently different about them than most of the alternatives. I'd recommend concentrating on the paradigms more-so than the tools because you will likely find that you will not be using this toolset in its entirety at your current or future clients - or perhaps you will, it's not my place to speculate. You may even wish to follow along the series of blog posts and use completely different tools - hopefully you will understand the concepts I present well enough to apply them in the tools you're using.
I have separate servers set up for each in a VirtualBox environment as GitLab only runs on Linux and Jenkins not only seems to place nicer on Linux, but most of the documentation you can find appears to be written for Linux, it just makes life easier to go with that. There are many tutorials on how to install and configure these if you feel you need to install them to follow along with these posts.
If you prefer not to have to have a Linux environment set up, GitHub has a version for Windows, or you can use a GitHub repository hosted at GitHub.com to save hosting your own version at all. The caveat to this is that your build system needs access to your repository to function so you can either hook it to your local repository or assume that you will need to be connected to the internet to run your build. For the purposes of stability, I prefer to have my central repository somewhere locally accessible.
If you prefer to run Jenkins on Windows, it works well, I've run it on Windows and it has a Windows installer. Configuration of your builds are virtually identical.
Some considerations for how you set up your infrastructure is to ask yourself: If my build server loses connectivity to this resource, how will this impact my ability to build my code. Prime candidates for this question are: Your source code repository and your dependency repository (i.e. NuGet). I prefer to ensure these are under my control somewhere on my local network that connectivity isn't every going to take down my build or deployment.
Continue to Part 2 - Steps to manage your deployment