Category: Octopus Deploy

Jan19201619 January 201619 January 20167Commentsby Gregor Suttie

Tips for Deploying your .Net project

Posted in Best Practices, Ideas, Octopus Deploy, PowerShell, Pro Tips, Productivity, TeamCity

Over the last 20 years I’ve seen many a deployment, some good, some bad and the ugly, life’s too short for manual/long deployments.

Here is what I recommend

If you have manual steps in your deployments then stop it, now, no seriously, you can deploy with zero manual steps (clicking deploy doesn’t count).

What to do instead

Get yourself TeamCity, yes TeamCity, Jenkins is ok but you get what you pay for, trust me Jenkins isn’t TeamCity. Ok now that you have an excellent build server, you’ll want to script your builds, for this I liked using psake along with PowerShell, honestly people who don’t know PowerShell are missing out, its awesome.

So get your scripts together and kick the builds off from TeamCity using psake.

Unit Test your PowerShell Scripts

Using Pester you can unit test your PowerShell scripts, thus realising that their fragile or poorly written or just large function which are hard to test, well do yourself a favour and use pester to unit test them.
Pester also gives you code coverage for your PowerShell scripts

Deploy your app

To deploy any .Net app use Octopus Deploy, its easy, its painless, it deploys with error handling, rollback using transactions, and you can do blue/green deployments, if you want to deploy a previous release, one click, deploy to multiple environments, any previous version etc. all in one click.

Summary
To summarise, no more manual steps, no copying files, manually unzipping files, creating folders etc, – no need to do that, and leads to human error, highly recommend each of those tools.


Apr28201528 April 201528 April 20150Commentby Gregor Suttie

Octopus Deploy – my wishlist

Posted in Octopus Deploy

OD First of all I’ve been using Octopus Deploy for a couple of months maybe less, and to be honest its freaking awesome, its easy to set up, easy to use, has an awesome API and is just a really well thought out piece of software.

Having used it I have one or two minor little things I’d love to see in the next version, I could go off and find out if there in the uservoice system for Octopus but I like giving credit where credits due so mentioning Octopus Deploy in another blog post is never a problem, anyone I talk to who I don’t work with currently, I always try to get them to go off and take a look at Octopus Deploy.

Moving on here is my wish list for the next version of Octopus, some of them may already be done, may not be an issue, might even just be pilot error from myself but any hoo here goes, off the top of my head.

  • Ability to make a step disabled I know a workaround is to create a dummy environment and set the task to this which will be ignored but disabling steps would be great.
  • Export settings option to be able to export all of the variables.
  • Variables, be able to go back and time and see the variables held against a specific release at on the date and time it was released at.
  • Email Template that you can use to send out which allow variables, this can be used across all projects.
  • Automated releases for doing out of hours releases, this options hard to find.
  • Automated releases which have the option to ignore manual step, so we can release to production out of hours without having to still accept the manual step we normally have
    for production.
  • Backups, when you take a backup have the ability to restore it and not lose all of the packages you had originally – this isn’t huge but a bit of a shock when I restored and we had no packages.

      • I will add more if I come across any but to be very fair this is all pretty much nice to have options.

      By the way did you check our the api for Octopus Deploy in case I haven’t mentioned it before – real nice work!


Tags:

Mar0120151 March 20151 March 20151Commentby Gregor Suttie

One week using Octopus Deploy

Posted in Octopus Deploy

ODSo its been a one week of using Octopus Deploy for me and its fair to say I am impressed.

API
Octopus deploy was written API-first with the UI built on top, this mean that anything you need to do or access can be done either from the command line or from the available Nuget package, documentation for the API is also great and is up on github here.

Documentation
The documentation is very thorough, don’t think I have managed to come across anything which hasn’t either been covered or discussed via the support forums which have plenty of detail.

Blue/Green Deployment
One necessity at work for us is repeatable automated deployments, we currently have this already as I’ve mentioned before with MSBuild scripts and use of TeamCity for the builds. The idea of Blue/Green deployments is something we need for our external facing website at work and is a major plus point with Octopus Deploy, we can build our release version of the website and publish this internally for testing purposes and then switch this to production in an instant, this way we know our production environment includes the latest fixes/changes and has been tested by our QA department.

The documentation for OD covers Blue-green deployments and this along with Scheduled Deployments make the case for using Octopus Deploy a strong one.

Why you should look at Octopus Deploy
I have spent a week trying out different kinds of project deployment, as per previous post as well as testing out deploying an internal .Net website, its been pretty much very straight-forward, it handles web.config transforms, app.config transforms and even substituting variables held within OD for settings in both app.configs and web.configs (connection strings, NLog settings etc.).

Scheduled deployments, Blue/Green deployments are a big selling point to us, on top of that a well written API with good documentation (which uses confluence which is also nice) makes it an easy sell – I am fairly sure we will be changing our deployment strategy to use this going forward and I am happy about that.

One last very nice thing is the sharing of PowerShell scripts which means you can make use of existing scripts, write new ones and share them with the community up on github and help make OD even better – version 3.0 also looks like it will bring even more good stuff to the mix when that is released in the coming months.

I hope to look at deploying database’s using Octopus Deploy at some point fairly soon.

So take a look at Octopus Deploy and I’m sure you wont be disappointed! – that’s all for now.


Tags:

Feb24201524 February 201524 February 20151Commentby Gregor Suttie

Giving Octopus Deploy a Test Drive

Posted in Octopus Deploy

OD
The last couple of days I have been taking Octopus Deploy for a spin, we have been working on a new project and I have been tasked with using Octopus Deploy to see how easy it would be to deploy our application to our Development, Staging and Production environments.

The application itself isn’t really import but its a TopShelf Web Service running on Katana which includes the use of certificates, url acl’s, MSMQ and some RavenDB for good measure.

Current Setup
Our current deployment setup makes use of Teamcity and MSBuild to deploy our applications, making use of a set of standard .proj files we use to deploy all types of applications, we have it down to 1 click deployments, which covers:-

  • Checkout from Source Control
  • Inspections
  • Compile/Build
  • Unit Tests / Integration Tests
  • Deploy

Change to our process
With Octopus Deploy (calling it OD from here on in) I changed this slightly removing the Deploy step above from our MSBuild script and looked into how to deploy the code using OD.

OD takes your code and bundles into a nuget Package using a tool called OcotPack, an add-on for Visual Studio as well as an executable which looks at your code and figures out what’s needed to package your code into a Nuget package. Once you have your Nuget package you put that into your Nuget feed, either your own or using OD’s in built Nuget feed (very handy and much quicker to use) and then you create a Release based on the nuget package, steps outlined below for clarification:-

  • Run OctoPack on project you wish to Deploy, this creates you a Nuget package
  • Copy your nuget package to Nuget Feed (even has an option to do that for you)
  • Create a Release pointing to your package
  • Deploy to chosen environment
  • Job done

I will be covering more on Octopus Deploy but so far I have managed to deploy the application in question to Development and Staging, register URLACL’s, register the Certificate, create our private message queues, and install and start the Katana based Top Shelf Service in 2 days worth of work from having really no idea about how Octopus Deploy works, fair to say I like what I see and so far so good! – Oh and the documentation and sample videos are excellent – more coming soon on my use of OD, if your deployments aren’t using Octopus Deploy I recommend you take some time and take a look, its been well thought out with a REST API and the UI built on top of that, it allows you to run custom PowerShell scripts which I really like and in general looks like a good addition to our tools belt.


Tags: