Embed Size (px)
DESCRIPTION
Octopus Deploy presentation made at Pittsburgh Tech Fest 2014
Citation preview
Continuous Deployments with Octopus Deploy
Adrian WrightPittsburgh Tech Fest 2014@adrianwright, [email protected]
About Me
▪ Consultant at Summa
▪ .NET architect with 9 years experience
▪ 3 years experience in builds/deployments
▪ Adjunct Faculty Geneva College at one time
▪ Passionate about making teams more productive… automation helps!
Outline
▪ Automation – Why is it hard?
▪ 5 things I like about Octopus
▪ Demo
Automating Stuff
▪ What do we mean when we say “automation”?
▪ Why do we care?
▪ Who’s responsible?
Facts and figures
▪ Source: dzone
▪ 48% are checking in infrastructure changes, environment changes, and system definitions into source control
▪ 24% of teams deploy a change within one week
▪ Lack of Time and Company Culture leading inhibitors
▪ Tools are NOT an inhibitor
▪ Technical challenges are an inhibitor, but many can be solved
First Level Automation
▪ Continuous integration
▪ Unit tests
▪ Building a deployable package
▪ Automating some deployments?
Second Level Automation
▪ App deployments to Dev, Staging, and Production environments
▪ Database deployments
▪ Integration tests
▪ Auditable deployment trail
Third Level Automation
▪ Infrastructure / VM level automation (outside of today’s scope)
▪ Advanced automated testing
▪ Automated rollbacks (all types of deployments)
▪ Continuous, gated delivery (any time of day)
▪ Advanced topics – web farms, manual intervention workflows, feature switches, enterprise-wide automation (mobile, etc.)
Things to consider
▪ Needs a management sponsor to break the “we only build functional stuff” cycle
▪ Collect statistics, if necessary
▪ Our QA’s spend 30 minutes deploying a build
▪ 15% of our releases have deployment issues
▪ Deployment automation lives and dies by automated testing
Treat it like a product
▪ Start small
▪ Evaluate vendors
▪ Run an achievable, successful pilot project
▪ Incorporate into daily process (definition of ‘done’)
▪ Build a roadmap
5 things I like about Octopus
Flexible
▪ Based on NuGet – if you can package it, you can deploy it
▪ Deploy to multiple servers in multiple environments
▪ Built for Web apps, windows services, and Azure apps
▪ Deploy everything else with Powershell
▪ Integrate with CI using TeamCity and TFS plugins or CLI or REST API
Improves Your Process/Visibility
▪ Automated build/test/deploy is good for your health
▪ Helps you get the most out of managing Dev, Staging, and Prod environments
▪ Dashboard shows current state of each server in each environment
▪ Auditable trail of who deployed what when, and what went wrong
▪ Link your TeamCity builds with your deployments
▪ Pro-active about alerts
Built for .NET, but don’t stop there
▪ If you can pack it, you can deploy it
▪ Deploy .NET web apps, windows services, SQL Server databases, to traditional or Azure servers with ease
▪ Built in IIS configuration support
▪ Web.config transforms
▪ Connection string replacement
Excellent Support Team
▪ Quick responses on forum
▪ Monthly or bi-monthly releases
▪ Helpful tutorials, demos, webinars
▪ Public product roadmap
▪ Swag!
Feature-Rich
▪ TeamCity and TFS plugins
▪ OctoPack (NuGet)
▪ Manual Intervention
▪ Team permissions
▪ Security
▪ At-rest encryption
▪ SSL
▪ encrypted backups
▪ two-way trust
Example – Without Octopus
▪ Using TeamCity as a Deployment tool
▪ Deployed 5 web apps/services, each with its own database
▪ A big, complex integration platform
▪ A VB6-based client application with over 150 executables
▪ Windows services to be distributed to 1000+ locations nationwide
▪ Medium/Large team – 25, including Dev, BA, QA
▪ TeamCity was not the perfect solution, but the automation mentality and scripting were in place to plug in Octopus (TC has more deployment features now)
Example – With Octopus
▪ 4 web apps and databases
▪ Replaced a home-grown deployment automation tool
▪ Small team – 1-2 developers, BA, Project Manager, UX Designer
▪ Initial Octopus implementation took one week
▪ No production deployment errors (yet)
▪ Currently releasing multiple times per week
Demo – getting up and running with Octopus
▪ Set up Dev, Staging, Prod servers on Azure
▪ Set up Mercurial repo (BitBucket)
▪ Create new MVC app
▪ Install TeamCity
▪ Add build for MVC app
▪ Install Octopus Server
Demo
▪ Install Octopus Tentacles on 3 servers (Dev, Test, Prod)
▪ Enabled TeamCity NuGet Server
▪ Add OctoPack to .csproj via nuget
▪ Add NuSpec File
Demo
▪ Add TeamCity Octopus Plugin
▪ Enable Octopack on Build step
▪ Set TC to use a standard build number format (0.9.x)
▪ Configure Octopus to find TC NuGet Feed
▪ Add new NuGet project (include Custom Installation Directory)
▪ Set up IIS apps on all servers
▪ Create Octopus Project
▪ Manually create a release and promote to all servers
Demo
▪ Add transform files
▪ Create Deploy project in TeamCity
▪ Add AssemblyInfoPatcher to the build
▪ Add Environment name and version number to Contact.cshtml
▪ Promote to Dev, Staging, and Prod and verify
Final thoughts
▪ Create a vision for your automation
▪ Challenge company culture
▪ There are many useful automation tools out there. Octopus is a very useful part of the puzzle.
▪ @adrianwright, [email protected]
