The DevOps Handbook - The Technical Practices of Flow

We begin our journey into the repeatable world of DevOps by taking cues from The DevOps Handbook, while Allen loves all things propane, Joe debuts his “singing” career with his new music video, and Michael did a very bad, awful thing.

These show notes can be found at https://www.codingblocks.net/episode136 for those reading this via their podcast player.

Sponsors

• Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after your first dashboard.

Survey Says

When you do listen to music, how do you do it?

Take the survey at: https://www.codingblocks.net/episode136.

News

• We’re very thankful for all of the new reviews!
  • iTunes: galTheJewishHammer, Ragnaroekk, Marcel7473826, rkosko31
  • Stitcher: Bicycle Repairman, BrunoLC
• Joe serenades us in song! (YouTube)
• Congratulations Allen on his renewed MVP status!

What is The DevOps Handbook?

• It’s a collection of arguments and high level guidance for understanding the spirit of DevOps.
• It’s light on specifics and heavy on culture. The tools aren’t the problem here, the people need to change.
• It’s also a book about scaling features, teams, people, and environments.

The First Way: The Principles of Flow

The Deployment Pipeline is the Foundation

Continuous delivery:

• Reduces the risk associated with deploying and releasing changes.
• Allows for an automated deployment pipeline.
• Allows for automated tests.

Environments on Demand

• Always use production like environments at every stage of the stream.
• Environments must be created in an automated fashion.
• Should have all scripts and configurations stored in source control.
• Should require no intervention from operations.

The reality though …

• Often times the first time an application is tested in a production like environment, is in production.
• Many times test and development environments are not configured the same.

Ideally though …

• Developers should be running their code in production like environments from the very beginning, on their own workstations.
  • This provides an early and constant feedback cycle.
• Rather than creating wiki pages on how to set things up, the configurations and scripts necessary are committed to source control. This can include any of all of the following:
  • Copying virtualized environments.
  • Building automated environments on bare metal.
  • Using infrastructure as code, i.e. Puppet, Chef, Ansible, Salt, CFEngine, etc.
  • Using automated OS configuration tools.
  • Creating environments from virtual images or containers.
  • Creating new environments in public clouds.

All of this allows entire systems to be spun up quickly making this …

• A win for operations as they don’t have to constantly battle configuration problems.
• A win for developers because they can find and fix things very early in the development process that benefits all environments.

“When developers put all their application source files and configurations in version control, it becomes the single repository of truth that contains the precise intended state of the system.”

The DevOps Handbook

Check Everything into One Spot, that Everybody has Access to

Here are the types of things that should be stored in source control:

• All application code and its dependencies (e.g. libraries, static content, etc.)
• Scripts for creating databases, lookup data, etc.
• Environment creation tools and artifacts (VMWare, AMI images, Puppet or Chef recipes).
• Files used to create containers (Docker files, Rocket definition files, etc.)
• All automated tests and manual scripts.
• Scripts for code packaging, deployments, database migrations, and environment provisioning.
• Additional artifacts such as documentation, deployment procedures, and release notes.
• Cloud configuration files, such as AWS CloudFormation templates, Azure ARM templates, Terraform scripts, etc.)
• All scripts or configurations for infrastructure supporting services for things like services buses, firewalls, etc.

Make Infrastructure Easier to Rebuild than to Repair

• Treat servers like cattle instead of pets, meaning, rather than care for and fix them when they’re broken, instead delete and recreate them.
• This has the side effect of keeping your architecture fluid.
• Some have adopted immutable infrastructure where manual changes to environments are not allowed. Instead, changes are in source control which removes variance among environments.

The Definition of Done

• “Done” means your changeset running in a production-like environment.
• This ensures that developers are involved in getting code to production and bring operations closer to the code.

Enable Fast and Reliable Automated Testing

• Automated tests let you move faster, with more confidence, and shortens feedback cycles for catching and fixing problems earlier.
• Automated testing allowed the Google Web Server team to go from one of the least productive, to most productive group in the company.

Resources We Like

• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Amazon)
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Amazon)
• The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (Amazon)
• Kubernetes Failure Stories (k8s.af)

Tip of the Week

• Press SHIFT twice to search everywhere in your IntelliJ project: Search for a target by name (Search everywhere) (JetBrains)
• Use ALT+F1 in Datagrip to see available options for a schema object such as navigating to it in the left pane.

• Use database migrations for all of your DB DevOps needs:
  • Flyway by Redgate (flywaydb.org)
  • RoundhousE (GitHub)
  • Liquibase (liquibase.org)