- Finally, we're ready to release on demand.
Let's talk about what we mean by that.
We talked about cadence and synchronization at length,
I definitely belabored the point.
We need cadence and synchronization to make routine
that which can be routine.
We need cadence and synchronization to assure
that we can do objective evaluation of working systems,
either at this level, or at this level.
We need those things.
That's the way we manage our development environment.
We call that develop on cadence.
But we want to decouple that from this other thing,
which is that it may be possible to release here.
It may be that I decide to release at only
these boundaries.
More likely, I have a completely decoupled world.
My development cadence and my release cases are unalike.
I don't remember for whatever reason, but we released
the last version of Safe, I think it was like June 26,
I have no idea if that was on a sprint boundary or not,
it was just a milestone.
That didn't matter.
We approached it with a solid and predictable cadence,
but when the time came, we released it.
We were able to do that because we had used
these practices to get to that point.
So I want to make sure that we separate
those concerns.
And by the way, you can release on cadence.
It can be very handy to do that.
I know some larger enterprises that deliver
big time infrastructure systems, and they've moved
from once a year to quarterly.
That's great.
Their customers are saying we don't want it more
frequently than that.
We all have examples of continuous delivery
and continuous release.
I mean my iPhone continuously releases.
Over the weekend, there was upgrades to my
Apple router software, so I naturally pressed
the upgrade button.
And guess what?
It took down the network.
So there's still risk, even in that model.
So we want to make sure that we separate those concerns.
We do develop on cadence, but release on demand.
What's more, releasing is not a monolithic thing.
Virtually every system that I'm aware of consists
of releasable elements.
And frankly, the more releasable elements you have,
the more quickly you can move to continuous delivery.
When Google says they release x times a minute,
second, microsecond, whatever, I don't know what
their current stats are, they're not releasing
the entire system, they're releasing an element
of that system.
Even our simple Safe website has a big picture.
We don't want to update that very often because
people don't like it when the big picture changes
very often, they're in the middle of a large
implementation, that big picture is integrated
into this course where I'm delivering.
If I change that big picture tomorrow,
the courseware is immediately obsolete.
That's not gonna work.
I have really some constraints about how frequently
we release Safe.
However, if there is a defect or a bug,
we could fix it now.
There are people sitting in this room with me
right now that if we logged in and found a bug,
they could fix that instantly.
If there's a security flaw or a patch, within an hour
we can fix that, so there are different cycles
of different types of things.
Now, we blog kind of asynchronously.
We release articles asynchronously, so we have
lots of ways to deliver value without changing
the big picture, because we're architected
for releasability.
Big systems are.
The SAAS companies that I'm familiar with most closely
have gone through to get to the point from a major
big bang release every six months, to continuous delivery,
they've gone through two and three significant
architectural refactors.
If you're going to release frequently, you have to
design for releasability, and that's an architectural
concern a little outside the scope of what
we're talking about here.
We call these things, just to give 'em a label,
a value streamlet.
So if we think about our value stream, the value stream
of Safe is delivering hopefully great intellectual
property to the end user, streamlets include things
like the blog that has its own release cycle.
It still has release governance, we don't just shove
a thing on the blog when somebody thinks it's a
good idea, but it's entirely different governance
than we do on an article.
So let's say this is an article.
Articles have to go through fairly extensive
peer review.
The graphics have to be rendered.
We have to create high resolution images,
because it's eventually gonna appear in the book.
So that's a different release cycle, and as I
mentioned, big picture is the slowest of all.
Every system has that potential.
You're either already able to release it, but you
just hadn't thought about it that way, or you start
to architect now for releasability.
And now when we think back a little bit,
just a few modules ago about how you
form agile teams, how about you form a team
so it can release something.
You form a feature team because it releases features
independently, how about agile release trains
in a large organization?
Obviously they want to release, it's in their various names.
How about creating large solutions where specific
agile release trains can release their piece of that
large solution at the large solutions level?
So we have to architect and design for releasability.
We also recognize that continuous delivery runs
into a few barriers.
There are some things that we need to do that
simply aren't economically efficient every day.
One example is user acceptance testing.
Another example is it might be a tough time
for me to get my hands on all the tools I need
to be able to test that my infusion pump meets
all it's non functional requirements.
Does it work under heat and load?
Does it work under certain kind of failure modes?
Are all the air conditions addressed?
If I crash the processor at any point,
will it recover in such a way as it won't overrun
infusion and kill the patient?
All of those things--I may not be able to do that
every single day, so I may have to batch some of this.
Sometimes I have to get into a lab to test my
avionics with the airplane manufacturer.
I can't do that every day.
And sometimes I have to get documentation sign offs,
official meetings and assignments.
As we talk about compliance a little bit later,
we're gonna push all of those things back as far
in the life cycle as we possibly can, but the
net result is still the fact that there are
things to do that are not economically viable
every single day.
Well, so we have to communicate release communications.
We do release notes when we update even a toolkit.
Do I do a release not every day in case I might
release it that day?
No, that's silly.
I only do the release notes when I'm prepared
to release.
Same goes for certain other types of things.
The final bomb is to prepare to finalize.
And you know what these things are.
Am I gonna train people in stuff I haven't
released yet?
No.
So I'm gonna wait for that.
So there is some batching of certain types of
economics based upon the u-curve optimization
of the frequency versus cost of doing that thing.
And that brings us to the point where we can
release, very frequently.
I heard one person call it 'continuish' delivery,
because it's largely continuing, but still has
some kind of frequency or cadence or pace of release
that's other than every single hour, every single day.
And for most of us, that's kind of a more practical event.
Tell me about your continuous deliver pipeline,
or pretend like I could hear if you told me.
Take a minute, and take a note.
It's not an easy thing to implement the
continuous delivery pipeline.
You've seen it here, you've seen the elements of it.
You've seen continuous exploration, you've seen
continuous integration, you've seen continuous deployment,
you've seen release on demand.
It's a non-trivial feat.
So if your organization is moving towards dev ops,
you're gonna need lean and agile to do it.
You can't separate the two.
You can't do waterfall dev ops, you have to have
small batches, you have to have automation.
You have to bust everything up into small batches
that move through the system more quickly.
Take a moment.
What are some improvements that you could make?
Just jot down a few.
In five minutes or so, I bet you will have identified
some things that you could do better to be able
to help facilitate migration to your ability
to provide more continuous releases.