Deployments with
Octopus Deploy
“All problems are boring problems until they're your own”
- Galina “Red” Reznikov (Orange is the New Black)
Who am I?
Ian Paullin
• (Twitter: @ianpaullin)
C#, ASP.NET developer for 4 years with Avanade and 8 years of .NET
development experience
Not ALM or DevOps guy (seriously reconsidering)
Computer nerd who likes too much tech
Proud Seahawks fan
Why present Octopus Deploy
Rolled off of a integration project using Web Services at major health
insurance provider (from Aug 2012 – October 2013)
November 2013 – Jim Szubryt from Accenture contacted me with
opportunity to tackle automated TFS deployments for all of Accenture CIO
No experience doing deployments with tools; always manually done
Chance to fix this issue once and for all (delusions of grandeur)
Opportunity to test out two tools head-to-head and implement enterprisewide automated deployment solution throughout Accenture world-wide
 Release Management for Visual Studio (InCycle/Microsoft)
 Octopus Deploy
The “real” reason I tout Octopus
“I abhor deployments”
-Ian Paullin
Experiences with deployments
Excel spreadsheet check lists
Email as documentation
When something goes wrong, everyone is frantically trying to figure out the
Rolling back to previous version takes longer especially if database changes
need to be reverted
Multiple deployment types (web,db,ssrs,services,etc.) drastically prolong
Public deployments done on Saturday night (late)
 Conference call with a few developers
 Everyone smoke tests the site
TFS Automation at Accenture
November of 2013 – Present – testing 2 products:
 InCycle/Microsoft Release Management 2013 for Visual Studio
 Octopus Deploy
After 3 months of testing, Octopus was the winner
How many people do deployments?
What kind of apps/technology do you deploy?
How long does it take on average?
How frequently do you deploy and to what environments?
How does Octopus work?
Octopus uses NuGet packages as a storage mechanism
Using the OctoPack, TFS build template can generate NuGet
packages and push them automatically to a specified NuGet server
NuGet server stores compiled projects as NuGet packages available
for deployment at any time
Agents (tentacles) are installed on servers you want to deploy to
You can define your environments and assign servers (tentacles)
A deployment process will fetch your NuGet package and run the
defined steps in parallel (across servers)
How does Octopus work? (con’t)
Why is Octopus better?
 NuGet is the better approach
 No need to recompile projects (if you need to
 Centralized storage; TFS build drop folders
insecure and waste storage space
 Prevent tampering of config files with lockeddown NuGet server (security)
 NuGet gallery for all (internally or externally)
Why is Octopus better (con’t)
 Powershell is the best choice for Windows
 Octopus audits all PowerShell output by default
 Store all web.config settings for all environments
 Can deploy to Azure and Amazon instances
 Can use to deploy SharePoint, SSRS/SSIS,
Windows Services, etc.
 DSC (desired state configuration) – next big thing
in PowerShell
 Anything can be done with PowerShell!
Why is Octopus better (con’t)
SQL Server not required!
 Uses Embedded RavenDB
IIS not required!
 Uses NancyFX (Self-hosting)
Octopus REST API
 They consistently use their own API throughout all components
 You can call the API to automate/script your own solutions
Octo.exe, DbUp, Octopus Step Template Library are all open source
Force process over manual changes (best practices)
Other features of Octopus
Agents (tentacles) can use any port to connect to Octopus Server
 Many company networks may have very restrictive port access
Able to do Continuous Deployment on Check-in or scheduled releases
 Octo.exe can be called to trigger release on Octopus Server
Integrates with Active Directory or own user database
Active community suggestion forum
Rapid development schedule
Let’s get started!
Three major components to getting started in Visual Studio
1. OctoPack – a NuGet package to install for your project
a. Hooks into TFS build template to create NuGet package and push to server
2. NuSpec file – a file that tells what files to store in the NuGet package
a. Use command line “nuget.exe spec <project name>” to create nuspec file in project folder
3. Change TFS build template (MSBuild arguments)
a. Include the following three parameters:
Configure Deployment process for deploying your NuGet package
Make sure your tentacle is installed and configured for your environment
you’re targeting
Note: You don’t need the OctoPack,
but it makes life a whole lot easier
OctoPack requirements
 .NET 3.5 runtime or higher
 Web Application Projects (not Website compatible!)
 Injects Octo.targets and commands in *.csproj file
Alternative to the OctoPack?
 Build packages from command line in Visual studio using NuGet
 Run MSBuild local desktop and pass paramters to OctoPack
 Download New-Nugetpackage PowerShell Script:
How to configure Octopus Deploy?
When your project NuGet package is in NuGet server feed, Octopus can see
the package and deploy to specific environment/servers
Define deployment process per project
Configure config file variable replacements (if you need to)
Can configure manual interventions for approval/denial (not required)
Email notifications (not required)
Downloadable Step Templates from (no
powershell knowledge necessary!)
Basic rule: If you can get want you want deployed in a NuGet package,
Octopus can deploy it
What about “X” type of deployments?
Database deployments
 Recommended practice is to have a Windows Console app that is a
script runner; Octopus has free dll (DbUp) available on
GitHub/NuGet that allows Windows Console to execute SQL scripts
in folder in console app
 Check out
SSRS deployments
 GitHub project “Deploy-SSRSProject.ps1” has PowerShell script to
deploy reports to Reporting Services asmx web service target
 Check out
Crazy Implementations
Do you ever just get down on your knees and thank God that you know me and
have access to my dementia?
- George Costanza
Customization Examples
Provisioning of NuGet feeds via PowerShell in Octopus Deploy
 You can use the NuGet feed in the Octopus Server but we use the free version from
Provisioning each feed manually takes time so we automated the process via PowerShell and added the
NuGet server with a tentacle
Backup NuGet packages on NuGet servers to off-site locations (myget)
 Running a service to check a folder for new packages and push to another off-site server
Tying Active Directory groups used in TFS with Octopus team to allow for user-management
directly from teams
 We’re a small support group; we don’t want to deal with user management
 Adding active directory groups to Octopus Deploy teams solves this!
Created windows service to insert new user accounts (or remove) in Octopus teams
 Automating user provisioning with custom windows service using C#, Octopus libraries and REST API
 Scan Octopus Project Groups for IDs to find match in external database
Warts and road bumps
NuGet NuGet.exe and NuGet servers
 NuGet Developers seem to break compatibility or have numerous unaddressed
 Each new version has it’s issues; must be careful in using latest and greatest
NuGet versioning
 Need to find unique way of versioning your packages – can be complicated
IIS configuration (for NuGet server only)
 Default NuGet upload size is 30MB; must configure IIS for larger packages
Users and Team Management can be tricky
 With custom roles, anything is possible but difficult to implement
(layering of teams with appropriate permissions to specific environments)
Warts and road bumps (con’t)
Most errors are not Octopus Deploy but technologies around Octopus
 OctoPack issues largely with NuGet.exe – unhelpful error messages
 Networking issues can make connecting tentacles to server
Lessons learned
Almost _anything_ can be done (especially through PowerShell)
PowerShell expertise is not as mandatory thanks to PowerShell scripts
available online (github) and the Octopus Step Template library
User management is tricky, but can be _very_ granular
No real integration with CI is a benefit
Once you get it going for your environments, you want to continue adding
even more to your process
In large environments, automation is key; need to figure out policies and
REST API and Octopus client/platform library are awesome for
extending/customizing Octopus to your needs
Yeah, well, what about new stuff?
Constant community feedback at:
Roadmap available (based from community feedback)
Aggressive schedule (2-4 week sprints)
For reference, since January of this year, they’ve had 6 releases!
 (From 2.0 to 2.5)
Well, they must be pricey, right?
Perpetual license! Once you buy it, it’s yours plus one year of updates
Renewals are for updates and support
Renewal pricing is 50% of original cost
Octopus Licensing:
5 projects
20 projects
60 projects
* projects
10 agents
20 agents
60 agents
* agents
For more information, check out
* = unlimited
5 users
20 users
60 users
* users
Reasons NOT to use Octopus Deploy
Octopus Deploy is the tool to reliable, maintainable and fast deployments
Leveraging NuGet to the fullest extent and thus implicitly enforcing
practices (release versioning, nuget package versioning, NO MANUAL
Auditing and automatic documenting of all output from deployment process
beats email, spreadsheets and chat history any day
Octopus Deploy’s components separates it from other solutions
No direct integration (IDE or CI server) allows creative solutions and
flexible configuration
Other solutions are either too cumbersome, heavy-handed or outdated
Octopus’s product transparency and velocity easily surpasses competitors
Pricing is extremely affordable
Go forth and deploy!

similar documents