Octopus Deploy Tech Fest 2014

Uploaded on

Octopus Deploy presentation made at Pittsburgh Tech Fest 2014

Octopus Deploy presentation made at Pittsburgh Tech Fest 2014

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Continuous Deployments with Octopus Deploy Adrian Wright Pittsburgh Tech Fest 2014 @adrianwright, adriantwright@gmail.com
  • 2. 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!
  • 3. Outline ▪ Automation – Why is it hard? ▪ 5 things I like about Octopus ▪ Demo
  • 4. Automating Stuff ▪ What do we mean when we say “automation”? ▪ Why do we care? ▪ Who’s responsible?
  • 5. 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
  • 6. First Level Automation ▪ Continuous integration ▪ Unit tests ▪ Building a deployable package ▪ Automating some deployments?
  • 7. Second Level Automation ▪ App deployments to Dev, Staging, and Production environments ▪ Database deployments ▪ Integration tests ▪ Auditable deployment trail
  • 8. 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.)
  • 9. 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
  • 10. 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
  • 11. 5 things I like about Octopus
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. Excellent Support Team ▪ Quick responses on forum ▪ Monthly or bi-monthly releases ▪ Helpful tutorials, demos, webinars ▪ Public product roadmap ▪ Swag!
  • 16. Feature-Rich ▪ TeamCity and TFS plugins ▪ OctoPack (NuGet) ▪ Manual Intervention ▪ Team permissions ▪ Security ▪ At-rest encryption ▪ SSL ▪ encrypted backups ▪ two-way trust
  • 17. 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)
  • 18. 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
  • 19. 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
  • 20. Demo ▪ Install Octopus Tentacles on 3 servers (Dev, Test, Prod) ▪ Enabled TeamCity NuGet Server ▪ Add OctoPack to .csproj via nuget ▪ Add NuSpec File
  • 21. 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
  • 22. 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
  • 23. 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, adriantwright@gmail.com