Octopus Deploy Tech Fest 2014

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]