DevOps - How I Learned to Stop Worrying and Love Deploys

# DevOps
## How I Learned to Stop Worrying and Love Deploys

Thomas Foulds

SGS Ideation Lab Dec. 2, 2016

---

## Agenda

1. Who am I?
2. DevOps: The What and Why
3. Implementing DevOps
4. DevOps in Real Life
5. Wrapping Up
6. Demo
7. Q&A

---

## Who am I?

* 2 years @ Sapient
* Solution Delivery
* Homebrewer and CLI junkie
* Use DevOps tools for fun and profit

---

## What do Google, Amazon, and Netflix all have in common?

\(Other than being hugely profitable?\)

---

## DevOps

Note:
* Netflix is notorious for it's DevOps culture with a focus on automation
  and tools like the SimianArmy which keep its service up even when effected
  by random failures.
* AWS is a leader in orchestration and configuration management with tools like
  CloudFormation.
* Google has one of the largest collections of servers on the planet. The only
  way an organization could manage that number of resources is be heavily
  leveraging automation.

---

## What is DevOps?

![What is DevOps?](Silicon_Valley_Inquisitive.jpg)

Note:
* Born out of Agile
* Meant to address second major gap in software lifecycle between dev and ops.
* New way of thinking about a product team that breaks down the silos
  * Especially between developers and operations.
  * We want to involve the development, QA, operations, management, and client
    stakeholders throughout the product lifecycle.
* Smaller and faster changes that we can test the effects of more easily.
* Built from interchangeable tools. The culture makes the practice, not the tool.
* Not an all-or-nothing process. Slow incremental adoption is better than an
  all in approach.

---

## Why Implement DevOps?

===

## Generate Business Value Faster

Fewer bugs + shorter lead time + more feedback data

More time spent making better products and more money

===

## Who benefits?

* Developers - Easier setup
* QAs - Faster testing
* PMs/BCs - Pulse of product
* Clients - Lower time to market

Note:
* Developers - Reduce your production push headaches and environment setup
  nightmares.
* QAs - Automated tests to catch the simple stuff and developers who are
  building on an exact replica of production.
* PMs - Decrease developer onboarding time and increase client delivery speed.
* Clients - Be faster to market and respond quickly to changes in the business
  climate

---

## Implementing DevOps

* Version Control
* Automation
* Infrastructure as Code
* Release Management
* Monitoring and Logging

Note:
* This is just an overview because there is a ton of content.
* Nobody is **just** a Developer
* A tool is only useful when it gets used
* You need team **and** client buy in
* Trade time **now** to save more **later**

---

## Version Control

* Save points for real life
* Everyone is using it, right?

Note:
* Version control allows us to track all the changes in our application over
  time and discover where bugs were introduced.
* Gives you snapshots of your entire stack and thinking at any point in time.

===

## Tools

![Version Control System Logos](VCS_Logos.png)

Note:
* Git/SVN/Bazaar/Mercurial
  * Git has gained a lot of mindshare with the Linux kernel and Github.
  * The Dojo provides Git repos through Stash.
  * Atlassian Bitbucket also supports Mercurial
  * SVN has long history and lots of tooling but is centralized

===

## Practices

* Blend roles to take advantage of tools from each
* Check in your application and how it's configured
* Small frequent changes

===

## Benefits
### Reproducible Builds

![Assembly Line](Assembly_Line.jpg)

Note:

* If an unexpected bug occurs in production you can easily return to the last
  working state. You can also deploy the misbehaving bug into a test environment
  to try and characterize what went wrong.

---

## Automation

* Make the machine work for you

===

## Tools

* Continuous Integration and Delivery
* Automated Testing

===

## Continuous Integration and Delivery

![Continuous Integration Logos](CI_Logos.png)

Note:
* More options which depend on resources and developer familiarity.
  * Jenkins
  * GitLab CI
  * Bamboo
* Bamboo is provided by the Dojo and has great integrations with both Stash and
  Jira.
* Provision your servers, deploy your applications, and run your tests all
  without needing human interaction.

===

## Automated Testing

* Behat/Phantom.js/Intern/Grunt
* Have tests for everything:
  * Code style
  * Unit
  * Functional
  * Experience

Note:
* Code style tests can be in a Git pre-push hook to prevent bad code from ever
  even making it to the repository.
* Unit and functional tests help you prove that what you built does what it says
  it does.
* Experience tests make sure that it looks the way it should on a variety of
  devices.
* Can even use this to test your configuration management, just run your tests
  on a new VM configured exclusively with your management solution and destroyed
  afterwards.

===

## Practices

* If you do it, script it.
* Good tests are hard to write, but worth it.
* Test early, often, and everything.

Note:
* Have tests to cover everything from unit level to functional and
  non-functional requirements.
* This means to test your infrastructure as well!
  * With a cloud platform you can set up and tear down environments with almost
    zero cost.
  * Automation is your friend!
* If you find something that the test cases didn't catch, fix it **and** the
  test cases.

===

## Benefits
### Delivery Speed
![Delivery Delays](Delivery_Delays.jpg)

Note:
* Flikr manages >80 deploys to "production" each day.
* By breaking changes into small easily tested chunks it's easier to find
  where a bug was introduced.
* Instead of days or weeks to respond to a bug or issue we can measure response
  times in hours.
* Why is that a good thing? The 2015 State of DevOps Report says so.
  * 30x more frequent deploys, 200x shorter lead times, and 60x fewer failures
    in high performing IT organizations
  * That means quicker market response and less downtime which means more time
    making money.

---

## Infrastructure as Code

* Do you know how to set up PROD?

Note:
* "Well it works on my machine..."
* With a DevOps practice, setting up a copy of production is very low effort.
  So developers can work against a copy of production instead of their own
  unique development environment.
* Things as simple as how file paths are written can make an entire system fall
  apart.
  * Mac VS Linux case sensitivity
  * Windows VS UNIX file paths
  * Dependency assumptions

===

## Tools

* Virtualization
* Configuration Management

===

## Virtualization

![Virtualization Software Logos](VM_Logos.png)

Note:
* Lots of different tools and methods, pick one that works and learn its quirks.
  * Vagrant
  * Docker
  * VirtualBox
  * VMWare
  * KVM
* Pick a cloud provider or roll your own host, it's up to you.
  * AWS
  * Azure
  * OpenShift
  * Rackspace

===

## Configuration Management

![Configuration Management Tools](Config_Management_Logos.png)

Note:
* Provides a way to declare the intended state for a server instead of just a
  set of steps.
* Again lots of different options to pick from.
  * Ansible
  * Chef
  * SaltStack
  * Puppet

===

## Practices

* If it isn't in the config, it doesn't exist
* Test your environment
* Write roles you can reuse

===

## Benefits
### Scalability

![AWS Autoscaling Diagram](AWS_Autoscale.png)

Note:
* When your infrastructure is code it's easy to create new copies of your
  environment.
  * With role based configuration you have a standard webserver template, fire
    and forget, no guesswork about manual changes.
  * Don't have to guess if you configured the server securely every time, just
    get it right once.
  * Large repository of existing roles you can draw upon and any custom roles
    you can reuse across projects.
* Many integrations with cloud providers make fanning out your product easy.
  * Easy to set up and tear down additional development and test environments.
  * Environments can mirror production to avoid nasty surprises.

---

## Release Management

* Control the flow of features to the public

Note:
* You want your deploys and rollbacks to be atomic. Test them heavily.
* This way if soemthing goes wrong you can switch back to the old version with
  minimal downtime.

===

## Tools

* Version Control
* Continuous Integration/Delivery

===

## Practices

* Deploys and rollbacks should be atomic
* Work against a copy of production

===

## Benefits
### Continuous Integration & Delivery Pipeline

![Continous Test Pipeline](CICDCD_Pipeline.png)

Note:
* Fail fast to speed up the feedback loop between code change and error
  appearing.
  * This helps developers continously improve their code instead of finding
    problems late and having to scramble to fix them.
  * A culture of risk willingness and openness to new optimization helps an
    organization innovate faster while remaining data driven.
* Continuous Delivery is different from Continuous Deployment.
  * A Continuous Delivery may run to the UAT environment but allow for QAs and
    the client to test the product before it is moved to production.
  * CI is for everyone, Continuous Delivery for most, and Continuous Deployment
    for the rare few who mature their process to the point where it is
    sustainable.
* Enables A/B testing of new features

---

## Monitoring and Logging

* Know where you are to know where you're going

===

## Tools

![Example Monitoring Dashboard](Monitor_Dashboard.png)

Note:
* Nagios, Sensu, NewRelic
* More data for feedback loop

===

## Practices

* Production logs for everything
* Dashboards for key performance
* Alerts vs trends

===

## Benefits

* Data driven development
* A/B testing

---

## Devops in Real Life

* ManufacturingUSA went from requirements to NIST servers in 15 days.
* Wrote the configuration scripts that automated our builds.
* Fire and forget process that anyone could run.
* Easily 10 or more builds to production in a day.

---

## Wrapping Up

* Pros
  * Faster/Easier feature delivery
  * Reduce downtime and bug count
  * Faster feedback on your product
* Cons
  * Can be expensive with tooling and education
  * Difficult to migrate legacy projects
  * Lots of habits and cultural walls to break down

---

## Demo

Remember ManufacturingUSA.com?

Note:
* We're starting from a basic Drupal 7 installation on a server in the
  SapeCloud.
* This is to save time but all of the server configuration was done with the
  Ansible tasks we're going to run.
* You can see scrolling by the configuration tool checking all the various bits
  of software to make sure that they are set up exactly how they're supposed to
  be.

---

## Q&A

* Any questions?

---

## Resources

* [References and Extended Discussion](https://thomascfoulds.com/2016/12/02/devops-stop-worrying-and-love-deploys)
* [AWS on Devops](http://www.slideshare.net/shivamaan/devops-common-use-cases-architectures-best-practices-48731462)