by Thomas Morris / @mozzy16
One very important factor of being a developer is deploying your code to the appropriate environment without anything failing.
Reduce human failure and automate all the things!
It is also true that during a deployment you generally tend to do the same each time.
Automate the steps that can be and you will have a process that you are comfortable with. No more worrying about what you may have missed out.
Now... parts 1, 2 and 3 will largely be the same wherever, but 4 could be done in a number of different ways.
There are also various different settings / updates required to get a working website.
I will not go into too much detail as to the different options, but look at a particular method for making this work.
I would also suggest that part 4 can be split into 2 parts...
Creating a release package with an appropriate version.
Deployment of the release package to a server.
Choose what tools are built for the task in hand...
Used to build the solution, perform tests and create an artifact for deployment. This will have continuous integration set up for the dev branch so that we don't have to trigger the release each time. We can use a template to share this across projects.
Using a meta-runner for GitVersion...
Adds variables into your build process that can be used to tag the version of the release package.
Supports both NuGet and SemVer versions.
This will use the NuGet version from the previous step and create a release package.
Do some tests on the project. If this step fails then the release package won't be deployed as the next step won't run.
We have now built a release package and done some tests on our solution and so we send this out to our NuGet server, which is built into Octopus Deploy.
Used to deploy an artifact to a given environment, as well as setting up a website in IIS and updating variables for different SQL connections. This all happens on the server we are deploying to via a secure connection.
Octopus Deploy also has a number of step templates that you can make use of within your deployments...
There are a few other quirks with Umbraco in terms of what needs to be deployed...
This is what I would define as being the doc types, data types, etc. Umbraco requires this to work.
This is what I would define as being the content, media, etc. This could be different between environments.
See these associated blog posts for
a more detailed discussion: