Automating
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
•
http://ianpaullin.com (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
problem
•
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
deployment
•
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
Survey
•
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
rollback)
 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
deployments
 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:
/p:RunOctoPack=true
/p:OctoPackPublishApiKey=<YourCustomApiKey>
/p:OctoPackPublishPackageToHttp=<YourNuGetServerUrl>
•
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: http://bit.ly/1sTxsbo
How to configure Octopus Deploy?
(con’t)
•
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 library.octopusdeploy.com (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 http://dbup.github.io
•
SSRS deployments
 GitHub project “Deploy-SSRSProject.ps1” has PowerShell script to
deploy reports to Reporting Services asmx web service target
 Check out https://gist.github.com/jstangroome/3043878
Demo
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 Nuget.org.
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
issues
 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
 http://help.octopusdeploy.com/discussions/problems/184-30mb-default-maximumnuget-package-size
•
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
philosophy
•
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:
 https://octopusdeploy.uservoice.com/
•
Roadmap available (based from community feedback)
 http://octopusdeploy.com/roadmap
•
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:




•
Free
Professional
Team
Enterprise
$0
$700
$2000
$5000
5 projects
20 projects
60 projects
* projects
10 agents
20 agents
60 agents
* agents
For more information, check out http://octopusdeploy.com
* = unlimited
5 users
20 users
60 users
* users
Reasons NOT to use Octopus Deploy
Conclusions
•
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
INTERVENTION etc.)
•
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!