Octopus Deploy: Automating .NET Deployments

1. Octopus Deploy Presented by @CasseyLottman Software Developer at Ocuvera
2. Our System • Windows service “hub” running in each hospital • Kinect + computer in each room • Windows desktop app for patient monitoring & alarms • Android phones for alarms & live video • Monitoring websites in Azure
3. Build servers build. Octopus deploys. https://octopus.com/why
4. In six months, we went from 1 deployment to 15.
5. Getting Started
6. Step 1 – Install Octopus on the server You’ll need your own SQL Server instance.
7. To the Web Portal! Check out https://demo.octopusdeploy.com/ to play around with a real Octopus server.
8. Octopus has Tentacles.
9. Options for your Tentacle • Polling Tentacle or Listening Tentacle? • What port to use? • Need to use a proxy? • What environment to add this machine to? • Should it be part of a tenant?
10. Listening Tentacle My updated version -https://git.io/v9pID Polling Tentacle
11. Getting packages to Octopus • Manual upload in the web UI (gross) • Gulp or Grunt task wrapping octojs • Using Octo.exe from the command line • Extension for TeamCity/TFS/VSTS • Using Nuget.exe • HTTP POST to Octopus API • Your existing, external package repository
12. Projects and Lifecycles • Project: A cohesive set of steps and configuration variables that correspond to a deployment • Lifecycle: How a release gets promoted through different environments  Default Lifecycle  Something like QA -> Staging -> Production  Override  Deploy to an environment without going through the default lifecycle  Primarily for hotfixes
13. Tenanted Projects Either the best or the worst new feature in Octopus.
14. Deployment Steps Now we’re getting to the good stuff.
15. Variables Powerful, Flexible, Possibly Confusing.
16. Variable UI – see video - Open in PowerPoint if you want it to crash
17. Project Variables
18. All Variables
19. Project Variable Templates
20. Common Variable Templates • Values defined by each tenant • Shared across projects & environments • If you only have one project, Project Variable Templates work just as well
21. Library Variable Sets • Shared across tenants, projects & environments • If you have just one project, can be used to group variables & de-clutter the project variable list
22. Variable Substitution - OctoStache
23. Importing Variables You can’t.
24. Deploy a Release
25. Version Control Doable, but still a work in progress
26. I recommend Octopus Deploy for .NET apps.
27. Deploy .NET apps with Octopus because… • Script as much as you want of your deployment configuration • Don’t script anything if you’d rather not • Ample built-in & community step templates • New tenants feature is a powerful tool for organizing machines & configurations • Easy to start using; powerful enough for complicated setups • Very responsive customer support

Editor's Notes

Need to have SQL Server installed on the machine!
Once you’ve installed Octopus Server on your machine, the rest of your work with it will be done through the web interface. Of course, you can script yourself out of even having to access that GUI, but the UI is a good place to start familiarizing yourself with Octopus concepts and setting up your build process.
Add some environments in the web interface
Deploying using Octopus requires installing software on the target machines. That software is called the Tentacle agent. Wordplay abounds! In our system, the tentacle software is installed on the image that we use for a new hub installation. Updates happen automatically whenever there is a newer version of Tentacle available when you attempt to run a deploy, so it doesn’t matter if your Tentacle installer is out of date. Installing the Tentacle software is the boring part – configuration happens later.
Like everything in Octopus, tentacle configuration can be scripted. This is actually the easiest place to start using scripts to automate your use of Octopus. Some of the options you’ll configure in setting up a tentacle include
Shown here – scripts generated from the Octopus Tentacle Manager GUI.
We generated the scripts, then at first, were manually updating them to set the target name (--name) and environment. Eventually, we switched to using the computer name as the machine name, so it wouldn’t need to be updated every time. And, the environment name can be provided as a command line argument, so you don’t have to fiddle with the script on the remote machine at all. A scrubbed version of our script, with the additions I just mentioned, can be found on the Github link at the bottom of the page.

If you don’t like the prospect of opening cmd, you can also do all of this in Powershell, or even .NET if you really want to. Though, Octopus won’t do as much of the work for you if you go that route.

Also note – it’s best to run these in an administrator prompt so that you get all the output in one window. Otherwise, it will try opening up one for each of the Tentacle.exe commands.
Here’s what you’ll see after you’ve created several different Tentacles in each of the environments.
You can manage Azure accounts, passwords, and SSH keys through Octopus. Click the green Accounts button to get there. Here’s an example of how Octopus’s web UI leaves a bit to be desired in some cases- it can be hard to remember “Accounts – of course I should go look at the top of the Environments page to get there!”
One of the features of Octopus is that you can configure which deployment targets go with which Azure subscription, based on machine, environment, tags you apply to a target, or what tenant it belongs to, and at deployment time everything just works. Getting it to that point can be difficult, though, and making seemingly minor changes to your Azure subscription scope can cause big headaches when it causes deployments to fail because a tentacle can’t find its Azure subscription. When it doesn’t work, it can be really difficult to figure out why, and your search often leads you to the support forums where you find that there is some sort of open issue around matching subscriptions to the machines that they can be applied to.
Up next – we need some packages to deploy. Remember, Octopus doesn’t build your apps. You’ll need to do that yourself, package the files you need, and then get them to Octopus somehow. You can do it all manually, but there are plenty of automation options that you’ll want to use instead. We use OctoPack to package our .NET apps,
If you already have an external package library, great! There’s a good chance whatever you’re using can be consumed by Octopus. Otherwise, go with what’s easiest. If you’re publishing a Node app, it makes sense to use the gulp or grunt tasks. If there’s an existing extension for your build server, use that.
At first, we were using our Override lifecycle to do the initial deployment that helps set up a new hub machine. When we refactored our environments, we realized it made more sense to deploy to a new target by simply promoting the most recent release that was in the environment we’re adding to. It made it a lot easier, so we didn’t have to roll back changes (if we deployed the QA build to a new production environment before it was ready for example.)
Deployment steps have to belong to a project. If you’re deploying multiple apps, which have a different cohesive set of steps, it might make sense to have multiple projects.

At Ocuvera, we only have one project. Though sometimes we want to push a hotfix that only applies to our phones, for example, on a typical deployment we want to update the entire system at once. Octopus seems to really focus on providing a good experience for the big guys who might need to have multiple types of deployments, but it works fine for us little guys, too.
Step templates are building blocks of a deployment process. There are a ton of existing step templates you can use provided by default, and you can create your own as well as access new ones from the community step templates.
Community step templates can be submitted by anyone, but so far I’ve found them to be pretty high quality scripts in general. Each of the icons you see here expands to individual step templates that you can add using that technology or platform. (See next slide)
There are so many step templates out there now that if you need to add a new step to your deployment process, I recommend looking to see if there’s an existing template before you write your own scripts. I’ve had a couple experiences where I wrote something like a Powershell script to grant file permissions, then after I had it working, found that there was an existing step template that would have worked out of the box.

Step templates save time and often, have logging and error handling. All of the source code for each of the steps is available to look at, so you can see exactly what you will be running and modify it if you need to.
Apparently Mac OS Sierra + Powerpoint + video = crash.
Read-only view
See the source of a variable – was it set in a tenant? In a library variable set?
Can be overwhelming
Variable substitution in Octopus is powered by the open source library OctoStache, which you can consume as a Nuget package to create little test programs.
This is supposed to be on the Octopus roadmap, but doesn’t seem to be coming any time soon. “Improve variables UI” is the top suggestion on the Octopus Deploy UserVoice site, with 943 votes as of yesterday. That request was posted two years ago. If you already have a large number of configuration variables, you will experience the pain of typing them all into Octopus individually, and losing your tab position after adding a new variable if you are trying to use keyboard navigation.
- You can completely restore an Octopus server from a SQL Server backup.
You can store your step templates in Git
You can read variables from the API and write them to a file, and back that up in source control

Overall, version control in Octopus is not a solved problem.
They are working on this - https://octopus.com/blog/rfc-version-control
Unless you’re diligent about logging, it can be difficult to figure out what a variable resolved to when it was used in a step that ran as part of deploying a release, even immediately after a deploy but especially a week or two down the road if people have been making changes.

Octopus Deploy: Automating .NET Deployments

You are reading a preview.

Check these out next

Octopus Deploy: Automating .NET Deployments

More Related Content

Recently uploaded (20)

Featured (20)

Octopus Deploy: Automating .NET Deployments

Editor's Notes

Octopus Deploy: Automating .NET Deployments

You are reading a preview.

Octopus Deploy: Automating .NET Deployments

Recommended

More Related Content

Recently uploaded (20)

Featured (20)

Octopus Deploy: Automating .NET Deployments

Editor's Notes