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!

Setting up projects to deploy

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.

A REPEATABLE PROCESS

At it's very basic, this should happen every time we work on a project...

1. Create project + repo
2. Write some code
3. Push some code to repo
4. Grab code and push to server

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...

 

Build phase

Creating a release package with an appropriate version.

 

Deployment phase

Deployment of the release package to a server.

TeamCity

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.

Step 1:

Configure version

Using a meta-runner for GitVersion...

https://github.com/JetBrains/meta-runner-power-pack/tree/master/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.

Step 2:

Fetch packages, build solution and run octopack

This will use the NuGet version from the previous step and create a release package.

Step 3:

Perform tests and check code coverage

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.

Step 4:

Publish package to Octopus nuget server

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.

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.

Step 1:

Grab nuget package

Step 2:

Create website in IIS

Step 3:

Deploy files to website folder

Step 4:

Update variables / apply transforms

Step 5:

Clean up / apply retention policies

Food for thought

Here are some other things which you might want to add during the process...

 

• Custom notifications to Slack / Hipchat
• Setup package restore
• Run npm install / grunt for assets
• Use bundler for gem dependencies
• Enable database sync / updates
• Offline deployments and lifecycles

Step Templates

Octopus Deploy also has a number of step templates that you can make use of within your deployments...

 

• HTTP - Test URL
• SQL - Test connection string
• File System - Backup directory
• Chocolatey - Install package

 

https://library.octopusdeploy.com/

Umbraco

There are a few other quirks with Umbraco in terms of what needs to be deployed...

 

• Document types
• Data types
• Media types
• Dictionary items
• Packages
• Content / media

Umbraco Base

This is what I would define as being the doc types, data types, etc. Umbraco requires this to work.

 

• Courier (supported by Umbraco)
• uSync
• Code first (!)
• Create package within umbraco
• Backup and restore database

Umbraco content

This is what I would define as being the content, media, etc. This could be different between environments.

 

• Courier (supported by Umbraco)
• uSync Content Edition
• Conveyor
• Create package within umbraco
• Backup and restore database