Octopus Deploy Tech Fest 2014

797 views

Published on

Octopus Deploy presentation made at Pittsburgh Tech Fest 2014

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
797
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Octopus Deploy Tech Fest 2014

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

×