Chapter 1, Section 1.

4, "Understanding Improvement"
"Introduction to DevOps", instructor John Willis, @botchagalupe on Twitter.
So, another really important piece of DevOps is the Continuous Delivery Model, or,
sometimes referred to as CI/CD, Continuous Integration/Continuous Delivery.
So, there's a ... what's considered the Continuous Delivery Principles. Jez Humble
has a book called "Continuous Delivery".
I have a link at the end of the section for the web page, which describes the
principles
as Jez and his group define them, and then it has a link to his book. His book is
the canonical source, in my opinion, for Continuous Delivery.
If we want to go through the principles, first off, you build quality in.
So, you basically ... this means, if you're going to build a software pipeline, you
want to basically create a full test coverage.
High-performing organizations take testing very serious. They take it serious in
the kind of code, the functional code,
the integration level, the smoke test,
all the way through the process, even how they deliver the software. We'll talk
about kind of advanced deployment things in a later chapter.
So, you build quality and work in small batches - this is about as an important
concept in DevOps as there is.
This idea of "you iterate fast,
you don't build code that is, you know,
hundreds of days or large, kind of waterfall deployments.
You start iterating fast: each feature is actually changed and it's put in and can
be delivered right to production.
The "small batch" is an incredibly important concept of DevOps.
Automate repeatable tasks ...
in general, automate anything that you possibly can. Automate everything that makes
sense.
There are some things that human factors actually need to be in place but, in
general, when in doubt, automate.
Always be pursuing this continuous improvement mindset.
It's important to make sure like the Deming cycle, the Plan-Do-Check-Act,
you know, think about small batch and Plan-Do-Check-Act.
Damon Edwards calls them the big "Js" versus the little "js", that little hook
in...
you know, you learn something, and then, you kind of fall off, and then, you start
kind of getting incrementally success.
The little j's would be little small batches of successes.
And then, everything is ... everyone is responsible - this is another principle.
You'll often hear people talk about in DevOps that, in their organization,
developers wear pagers.
Werner Vogels, the CTO of Amazon, I'm kind of paraphrasing here, buddy,
oh, he says that "If you build it, you own it".
So, this idea that everybody is responsible for the pipeline.
There it is, you know, when we look back at Dev ... Dev, Ops, Dev and Ops,
DevOps ...
What we're really talking about is collaboration, sharing responsibility
and so, the pipeline, the system becomes the responsibility of everybody.
As I said, developers wearing pagers, developers getting working up
developers writing code ... the idea that a developer doesn't just check in the
code and they're done with it.
In a lot of cases, they own it for the life of the service or the feature.
You know, then we look at the Continuous Delivery anti-patterns.
So again, we can learn from anti-patterns, like incongruity testing and production
environments.
So, in the early days of DevOps, we saw that a lot of people wanted a first quick
win was using infrastructure as code at every level.
So, Chef, or Puppet, or CFEngine, if a developer was testing an application on
their laptop,
we would try to build that laptop using something like Chef or Puppet or CFEngine.
Then we move the code into a test harness or CI Integration
Would also again use Chef, Puppet, or some infrastructure as code implementation.
And then, when it goes into production again use the same infrastructure code.
And what we found is that we get, you know, we get less variation
as opposed to manually building environments. In some cases, the worst case anti-
patterns are organizations where the environments are completely different.
The laptop is running different infrastructure across the board, different
operating system, then test harness systems and from the production.
So, we look to improve that. In fact, containerization, things like Docker,
now people are referring to immutable infrastructure, where everything, the system,
the application,
and the middleware, they're all in a binary that basically is run on the laptop,
and is running the integration and the production exactly the same, bit for bit.
Another anti-pattern would be testing taking too long.
So, if your tests are taking really like days, you know, 3-4 days, right? We need
to look at that.
Manual, anything manual: manual regression, acceptance test, checklists, long lead
times, you know,
any kind of anti-patterns, is when they ...
it just takes forever to get a change in the system
and it's probably because the people who built that system or maintain it are so
risk-adverse.
And what we get, what we find is, you know, you can go fast and be, and in general,
the risk-adversed implementations are more risky.
High technical debt, there's a metaphorical technical debt.
These are all the things that basically kind of build up, like financial technical
debt, that, if you don't address,
they become larger and looming, they create more complexity and are harder to debug
and harder to fix.
You'll find that the companies that kind of have DevOps anti-patterns will be, or
Continuous Delivery anti-patterns, will have high turnover and, in general,
these will be organizations where it's slow and hard to change.
And back to the kind of risk adverse, the fear that things will break
in general, they break worse.
And so, the Continuous Delivery patterns are the couple of things that are kind of
core to Continuous Delivery. One is everything starts in source control.
So, not only your application source, but your kind of meta-definition, so, if
you're using Chef or Puppet or CFEngine,
those products have languages.
The code that you use the build your infrastructure, with that infrastructure's
code
Chef, Puppet, CFEngine should also be stored in source control.
If you're using stuff like Docker, the actual DSLs that build the images should be
in source control.
Source control today is usually GitHub or Git,
but it just needs to be in source control.
A unique feature of GitHub is this concept of a "pull request".
High-performance organizations tend to peer review on pull requests, so before
the ...
the code gets put into the code base,
somebody else looks over your shoulder at the code, and in some organizations,
they'll make sure that they're not actually on the same development team.
You automate everything.
We talked about it. Trunk based deploys - this is in Jez Humble's book.
A lot of discussion, in general, you're always committing to trunk, you're
deploying from trunk, and so the idea is
that it lowers the complexity, but it fits the small batch moving fastball.
In that, the assumption is when the developer commits their code
it's fully tested and it's ... the expectation is that it could and may go to
production.
So, it's a form of self-defining resilience.
But also, when you have all sorts of branches, and again, Jez does a really good
job explaining the detail,
So, we'll get into all this in a later chapter, but,
you know, if you have lots of branches you have more likely of getting mixed
builds, mixed code in development, and harder debugging.
Done means released.
I love this. This goes back to kind of the shared responsibility, but a developer
now doesn't just commit code and then says "I'm done"
Done means that it's actually in production.
And then, we've got this depth directly from kind of Toyota, this stop the line,
and Toyota, the production lines for manufacturing cars,
they actually had a cord, they called it the Andon cord,
and it could have anybody ... if they saw a defect or a bug they would actually
pull the cord
to stop the line and it ... and everybody was empowered to do that.
And today's Andon cord is the build break the build.
So, if, you know, if you're doing a trunk-based deploy,
basically, if your code breaks the build, then it needs to get fixed right away.
Stop the line. In fact, in some cases, people swarm to do the fix.