Octopus Deploy Tech Fest 2014

  • 184 views
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

Views

Total Views
184
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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