►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
What is the Unit of Work in Modern Delivery? - Michael Stahnke, CircleCI
JW Grand Ballroom 3
Speakers: Michael Stahnke
Today, software delivery is harder than ever. Developers are delivering on top of a mountain of dependencies that they can’t always see. Single sources of change within the pipeline are complicated by an external ecosystem of changes that can be anything. Even the most experienced engineers cannot comprehend all of the components and moving parts that go into the products they build, yet they’re still expected to deliver software incredibly fast with no bugs. The last 10 years were all about code, but given the current complexities, focusing on your code is only half of the solution. The future of software delivery operates in an automated network, alive with dynamic, two-way intelligence. In this talk, Michael Stahnke, Vice President at CircleCI will help you prepare your teams for infinite change, and create a resilient network of software to withstand any amount of constant change.
Takeaways include:
Organic patterns to break that encourage incompleteness
How to identify + validate changes from an infinite amount of sources across the software ecosystem
Ways to empower developers and teams to act on these changes
A
All
right,
I
think,
it's
time
to
get
started,
so
I'm
gonna
rock
it
I'm
michael
stonke,
I'm
vp
of
engineering
at
circle,
ci,
I'm
not
gonna,
stand
up
on
that
little
stage.
I'm
gonna
talk
about
the
modern.
What
the
unit
of
work
is
in
modern
delivery.
So
over
the
last,
while
I've
worked
a
different
company,
it's
been
the
automation
space
for
about
10
plus
years,
and
so
I'm
really
interested
in
kind
of
where
this
is
taking
us.
A
What's
going
on
how
we're
managing
what's
happening
out
in
the
world,
I'm
at
cd
conf,
so
there's
a
whole
conference
around
doing
continuous
delivery,
whereas
ten
years
ago
that
was
not
that
common
for
a
lot
of
places.
We'll
say
that.
But
when
you
start
with
something
like
a
unit
of
work,
a
unit
of
work
actually
comes
from.
A
You
know,
classic
physics,
where
you
have
a
jewel
and
all
those
types
of
things,
but
when
unit
of
work
is
really
you
break
something
down
into
the
smallest
thing
that
completes
a
task,
and
so
you
just
you
know
you
break
things
down,
so
you
start
with
the
outcomes
and
what
do
we
have
with
continuous
delivery?
Well,
we
want
to
deliver
some
user
value.
That's
really
the
entire
point
of
doing
continuous
delivery
is
users
get
to
do
something
they
accomplish
something.
We
measure
that
something
so
that
value
runs
somewhere.
A
That
somewhere
has
its
own
characteristics
and
its
own
user
value
that
is
being
delivered
by
someone
else,
probably
that
somewhere
else
has
its
own
characteristics
and
its
own
work.
So
there's
just
a
lot
of
different
stuff
that
happens
where
you
have.
I
have
it
deliver
a
thing
it's
on
top
of
a
thing
it's
on
top
of
a
thing.
These
are
all
being
delivered
at
different
cadences
by
different
folks,
with
different
people
and
different
things.
A
So,
in
the
past,
a
unit
of
work
for
a
lot
of
the
roles
in
technology
was
either
a
user
story
or
a
change
ticket
or
a
phone
call
or
an
email.
It
was
just
a
hey.
I
need
you
to
do
this
thing.
People
would
do
that
thing
and
they'd
complete
it.
You
know,
if
you
think
about
your
cable
person
when
you
call
they're
like
well.
My
dispatcher
says
I
got
to
do
this
this
and
this
that's
their
unit
of
work
like
that's.
Just
how
it
works,
so
this
was
how
it
was.
A
It
was
different
for
different
roles
in
the
operations.
World
change,
tickets
or
incidents
were
kind
of
the
initiator
in
other.
You
know
in
in
developerwork
roles
it
was
user
stories
or
or
just
you
know,
tickets
like
that.
So,
but
over
time
we
began
to
see
convergence
in
that
there
was
kind
of
one
unit
of
work.
A
It
was
a
master
system,
but
before
we
get
there,
I'm
going
to
take
you
back
in
time
to
some
of
the
things
that
I
learned
on
how
we
got
to
what
the
unit
of
work
is
or
or
what
really
makes
us
better
at
continuous
delivery
today
or
what
enabled
this
so
I
went
to
the
first
devops
days
us
in
2009..
It
was
in
san
francisco
was
my
first
time
out
in
the
bay
ever
it
was
amazing.
A
I
was
at
linkedin
headquarters.
They
had
like
frisbee
golf
going
on
in
the
back.
It
was.
It
was
just
one
of
those
places
where
I
came
from
caterpillar,
where
you
know
they
had
just.
Let
us
not
wear
ties
that
was
a
big
deal
there.
So
so
I
was
a
very
different
eye-opening
experience,
but
what
I
got
was
there's
this
whole
thing
called
infrastructure
is
code,
and
I
had
been
friends
with
the
guys
who
founded
puppet
and
eventually
I
went
to
work
there.
A
You
saw
it
earlier,
but,
and
you
know
there
was
a
couple-
other
companies
that
were
doing
this
infrastructure
as
code
thing
and
then
a
couple
years
later.
You
know
you
had
some
others
pop
in
there
but
infrastructure
as
code
was
this
whole
idea
that
we're
gonna
do
all
this
stuff,
that
operations
used
to
do
and
we're
gonna.
Do
it
like
development,
okay,
cool.
So
now
I
have
a
review
of
a
thing
happening.
A
I
can
use
this
as
a
communication
tool,
it's
all
from
code
and
basically,
what
this
got
us
was
auditability,
accountability,
reliability,
understandability
all
the
ilities,
and
that
happened
because
it
was
a
pull
request
or
a
merge
request
or
whatever
it
was.
You
know
there
was
reviewing.
There
was,
I
know,
what's
going
to
happen,
instead
of
going
to
a
change
review
board
on
wednesday
morning
sitting
for
two
hours
talking
about
something
that's
going
to
happen
in
two
weeks.
A
Before
that,
how
many
of
you
ever
worked
with
somebody
who
had
a
job
title
that
was
called
a
build
master
yeah
I
did,
and
this
was
just
the
person
whose
job
it
was
to
keep
the
bill
running.
Basically,
there
was
a
ton
of
maintenance
feeding
machinery,
all
those
types
of
things,
and
it
was
just
a
weird
job.
It
really
kind
of
doesn't
exist
anymore,
only
it
kind
of
does
they
call
them
devops
engineers,
but
they're
basically
build
masters.
A
A
A
And
the
answer
was
usually
yes,
so
you
didn't
know
what
was
going
on,
but
then
we
got
into
this
pipelines
as
code
borrowing
from
the
infrastructure
thing
as
code
and
it
was
well,
let's
move
how
we
talk
about
the
work
and
put
it
right
next
to
the
work,
and
that
was
you
know
all
of
this
yaml
yaml.
So
much
ammo,
please
everyone
stop
it
with
the
yaml,
but
there
is
so
much
gamel
talking
about
work,
so
we
have
a
pipeline
defined
or
we
have
a
delivery.
A
You
know
cadence
defined
or
whatever,
and
it's
all
in
there
with
our
source
code
cool.
So
now
we
have
everything
is
code
right.
We
have
the
way
we
deliver
the
way
we
test
the
way
we
validate
the
way
we
talk
about
it.
Everything
is
code
cool.
Then
we
have
some
policies
code
where
you
get
this
security
standpoints
and
stuff
like
that,
that's
developed
in
code,
so
I
can
again
do
all
those
reviews,
those
merges
all
the
leds.
I
talked
about
earlier
that
all
happened.
A
This
leads
us
to
some
marketing
guru,
calling
this
git
ops
cool.
All
right.
We
do
everything
we
get.
I
I
don't
know
why
this
wouldn't
work
with
any
other
version
control
system,
but
it
was
called
get
ops.
So
now
we
have
git
ops.
We
make
a
pull
request,
we
review
it,
we
merge
it
and
things
happen,
whether
it's
about
source
code
and
applications
or
its
infrastructure
or
its
policy
or
its
pipelines,
or
it's
anything
else.
A
A
Norway
and
no
and
false
are
all
the
same
thing
in
yaml.
It's
really
weird,
but
what
the
problem
is
is
everything
that
I
just
described
is
code.
It's
all
happening
as
code,
so
we're
like.
Okay,
everything
is
code.
We
have
all
these
little
building
blocks
and
that's
what
we
deliver
and
that's
what
we
push
across
the
system
code
and
there's
a
desired
convergence,
that
everything
ends
up
being
code,
which
is
cool
and
in
this
world
the
unit
of
work
is
a
commit.
A
A
commit
is
the
thing
that
you
can
divide
all
your
work
down,
validate
it
see
if
it's
good
make
it
happen,
some
might
call
it
it's
the
pull
request.
If
you
have
many
commits
in
a
pull
request,
we
can
all
debate
hygiene
and
all
that
stuff,
but
anyway
it's
a
commit
more
or
less
so
you
have
a
commit
moving
across
a
system
that
has
been
detailed
and
built
out.
So
you
can
validate
everything,
that's
going
to
happen
on
the
other
end,
because
you
know
everything
is
going
on
in
your
environment,
cool.
A
A
Let
me
give
an
example
of
just
hypothetically
something
that
could
have
happened.
Let's
say
you
have
an
elb
and
you
usually
have
about
five
nodes
behind
it,
a
bunch
of
traffic
happens
and
it
spins
up
ten
more
nodes.
So
now
you
have
15
nodes,
but
when
those
10
spun
up
part
of
their
bootstrapping
process
is
they
run
docker
pull.
A
Yeah,
I
don't
know,
I
have
no
clue
what
latest
is
thanks,
mutable
tags,
so
it's
a
different
version.
My
application
doesn't
behave
the
same
way
on
one
version
of
this
image
versus
another
inversion,
so
two-thirds
of
the
traffic
going
to
my
application
is
now
hitting
a
non-deterministic
endpoint
and
the
other
third
is
hitting
the
thing
that
it
was
exactly
what
I
thought
it
was
that
I
had
validated
cool
cool
cool
cool,
so
some
of
these
instances
are
less
good
than
others.
A
Has
this
ever
happened
to
anybody
else
ever?
No
all
right,
I'm
the
only
idiot,
all
right,
cool
cool
and
then
you
get
into
well.
I
validated
a
whole
bunch
of
stuff,
but
did
I
actually
validate
at
all?
I
had
the
same
set
of
inputs,
but
then
you
have
to
ask
yourself:
did
I
really
have
the
same
set
of
inputs
and
when
I
always
think
about,
did
I
really
have
the
same
set
of
inputs?
I
come
back
to
this
mario
brothers
thing
who
grew
up
playing
super
mario
brothers.
A
A
Any
time
you
run
a
build
time
has
changed,
so
my
inputs,
by
definition,
are
not
the
same
as
what
they
were
the
last
time
I
ran
to
build
just
saying,
so
we
get
into
this
whole.
I
want
determinism,
I'm
all
about
determinism.
If
you
actually
read
like
the
psychological
definition,
determinism,
you
inevitably
inevitably
end
up.
Reading
about
free
will
and
do
we
all
have
our
own
free
will
or
not
beyond
the
scope
of
this
talk,
but
generally
most
people
think
we
do
have
free
will,
and
so
I
have
free
will.
A
But
I
have
this
whole
thing
that
I
have
this
whole
god
complex
that
I
can
be
totally
deterministic
in.
What's
going
on
in
my
cd
pipeline
cool.
Basically,
we
have
all
these
inputs.
Does
anybody
understand
them
all?
No,
they
don't
so
requiring
knowing
all
inputs
to
the
system
is
how
we
get
to
determinism.
We
have
to
know
all
inputs
what
else
required,
knowing
all
inputs
to
a
system
to
make
it
work.
A
Yeah
waterfall
development,
which
I
thought
was
the
whole
thing
we
were
trying
to
get
away
from
doing
ci
and
cd
was
we
were
going
to
do
these
iterations.
We
were
going
to
do
it
really
quickly
because
I
didn't
know
all
the
requirements
up
front
and
waterfall
totally
works.
If
you
know
all
the
requirements
up
front,
I
can
tell
you
that,
like
it's
amazing,
it's
actually
a
really
good
delivery
system.
If
you
do
actually
know
all
the
inputs
up
front
very
few
cases
in
the
world,
do
you
ever
know
all
the
input
up
front?
A
So
I
get
back
to
this
okay,
so
source
code
is
instruction
for
operations
and
change
and
all
this
stuff
and
that's
why
I'm
validating,
and
then
I
start
thinking
about
it
more,
I'm
like
oh
no
source
code
is
for
intentional
change
and
intentional
operations,
and
you
can
say
well
mike.
I
have
written
much
many
source
codes
over
time
and
they
are
sometimes
very
unintentional
in
what
they
do.
And
yes
that
is
happening,
but
there's
at
least
a
log
that
you
made
a
change.
There
was
intention
to
change
something
there's
a
commit.
A
Maybe
it
didn't
do
the
thing
you
thought
it
did,
but
at
least
somebody's
like.
Oh
something
happened.
Let
me
go
look
into
that.
So
code
implies
desired
behavior.
You
know
what
the
behavior
is
supposed
to
be
you're,
trying
to
change
it,
and
then
you
get
into
like
unintentional
change
and
what
type
of
change
is
not
from
github.
Well,
there's
all
this
stuff
that
happens
basically
post
code,
whether
it's
running
on
someone
else's
computer
using
someone
else's
platform,
someone
else's
payment
gateway,
someone
else's
infrastructure
users
go
do
different
things.
A
A
I
had
an
image
that
I
hadn't
pinned
appropriately.
It
grabbed
a
new
version
of
a
library
that
I
apparently
hadn't,
pinned
appropriately,
who
pins
all
packages
inside
their
docker
images,
literally
nobody,
they
all
run
after
get
update.
Then
they
clean
out
their
app
cache
because
they
don't
want
in
the
image,
but
they
have
no
idea.
What
versions
are
there
and
docker
just
came
out
with
a
way
to
do
a
blm
on
an
image
like
what
two
months
ago?
So
there's
just
a
lot
of
stuff.
A
There
is
not
that
deterministic,
so
this
is
kind
of
all
the
stuff
that
goes
into
building
an
application.
These
days
you
have
third-party
apps,
you
have,
you
know
just
different
infrastructure,
and
most
of
this
isn't
something
that
everybody
keeps
in
their
own
brain
anymore.
It's
it's
like
outsourced
to
different
providers
or
to
different
teams,
or
whatever
you
don't
know.
What's
going
on
so
developers
pull
apart
all
these
things,
they
put
it
together
with
their
own
open
source
software,
libraries,
the
things
they
build
upon
and
the
operators
are
doing
stuff.
A
A
That's
why
you
have
outages.
That's
why
you're
up
at
2am-
or
you
know
whatever
the
classic
monikers
are
these
days
on
carrying
a
pager,
but
we
spent
all
this
time
building
pipelines
to
validate
what
was
going
through.
All
this
time,
we
move
code
through
the
system
at
a
super
rapid
rate.
We
can.
We
are
shipping
all
the
time
we
validate
all
of
it.
We
validate
most
of
it.
We
validate
some
of
it.
That's
going
through
the
system.
A
Well,
what
else
is
there
well,
ci
is
for
a
bunch
of
things
that
I
know
about.
I
can
write
tests.
It
should
do
this
and
easy
to
do
this.
I
wish
it
did
this
it's
supposed
to
do
this
when
this
happens,
given
this
set
of
inputs,
that's
what
comes
out
integration.
Maybe
I
have
a
build
this
library
links
to
this.
I
can
validate
they
link
together.
You
know
all
those
types
of
things
ci
we've
been
here
for
years.
A
Cd
things
I
can
define
is
out
of
bounds.
I'm
gonna
deploy
this
to
four
percent
of
traffic
if
it
gets
an
error
rate
higher
than
10
over
the
next
five
minutes
roll
it
back.
You
know
all
that
those
are
still
pretty
advanced
features
for
a
lot
of
a
lot
of
players,
but
you
can
do
that,
and
you
can
say
out
of
bounds
is
when
errors
are
this
high
out
of
bounds
is
when
traffic
stops
going
to
this
or
500.
You
know
we're
at
this.
You
have
an
out
of
bounds.
A
Boundary
yeah,
I
didn't
like
the
way
that
came
out
even
out
of
bounds.
Boundary
yeah
quote
me
on
that,
but
then
you
get
into
the
actual
user
experience,
which
is
reality
what's
really
happening,
because
the
user
is
the
only
thing
that
can
tell
you
if
it's
behaving
or
working
the
way
it's
supposed
to
all
the
monitoring
systems
in
the
world
can
tell
you
you
think
you
know,
but
do
you
know
users
can
tell
you
for
real,
so
we
have
all
these
applications.
We
build
we
test.
A
Maybe
we
pull
in
some
of
these
third
parties
to
even
do
tests
or
we
mock.
You
know
we
mock
a
time
stamp
change
or
we
mock
out
a
library
or
a
platform
or
whatever,
and
you
can
all
get
into
the
reasons
mocking
is
great
or
not
into
why
you
do
testing.
But
then
you
deploy
this
one
piece
of
code
and
it
goes
out
into
the
world
with
all
these
wild
things
happening,
cool
cool
cool,
so
we
have
inputs
where
we
build
test
deploy
release
and
we
have
users.
A
A
What's
right,
what's
wrong?
What's
left
what
the
hell
is
going
on
yeah,
so
what
we
have
is
just
a
whole
bunch
of
sources
of
change
coming
into
this
system
and
some
of
them
we
actually
kick
off
a
build
for,
but
a
lot
of
them.
We
don't
because
we
don't
revalidate
and
we
don't
pull
in
all
those
things
we
rely
upon
and
that's
modern
complexity,
and
we
still
have
these
consumers
of
change
so
in
this
world.
A
There's
change
happening
all
the
time
because
of
the
complexity
of
these
applications,
but
we're
only
validating
it,
a
portion
of
the
time
and
in
this
world
the
unit
of
work
is
no
longer
the
commit.
It's
all
the
changes
happening
around
us
and
that's
actually
why
we
want
to
do
ci.
Why
we
want
to
do
cd.
A
A
Maybe
I
could
maybe
I
can
make
more
things
deterministic
by
saying,
pin
my
docker
versions
and
pin
my
packages
and
you
know
do
all
these
things
to
make
it.
Yes,
you
can
do
that
it's
safe
and
you
should
do
those
things
you
will
not
know
all
the
inputs
in
the
complexity
of
your
system.
Your
payment
gateway
suddenly
decides
that
you're
no
longer
taking
payments
from
russia.
A
You
had
nothing
to
do
with
that
decision.
Nothing.
What
do
you
do
about
it?
Well,
maybe
you
need
to
revalidate
some
things.
So
intentional
and
unintentional
change.
Unintentional
change
happens
constantly
around
you
in
modern
application
delivery,
because
we've
built
on
these
complex
layers
of
platforms
and
apis
and
gateways.
A
So
we
basically
have
a
streaming
amount
of
events
that
are
happening.
Change
events,
just
changes
happening
all
the
time
right
now
nobody's
really
capturing
those
events
and
they're
all
getting
thrown
on
the
floor,
because
they're,
basically
not
even
really
admitting
to
anything
that
you
can
capture
and
play
with.
You
know
the
way
you
find
out
about.
It
is
one
of
your
developers
says:
hey
our
payment
gateway,
no
longer
accepts
russian
stuff
going
through
our
payment
gateway
cool.
A
A
So
there's
a
bunch
of
events,
but
now,
let's
think
about
how
do
we
turn
this
around
and
say?
Well,
if
I
know
that
change
is
the
unit
of
work,
what
do
I
do
differently?
What
do
I
do
differently?
Well,
maybe
I
can
start
thinking
about.
Can
I
start
validating
before
a
commit?
If
the
commit
isn't
the
thing
I
actually
care
about
anymore?
Can
I
validate
earlier
cool
make
some
changes.
It
updates
your
ide.
Maybe
it
runs
unit
tests
in
the
background.
Some
people
have
done
this
for
years.
A
Some
people
don't,
can
I
do
it
on
somebody
else's
computer.
Could
I
be
like
okay
just
submit
this
over
to
circleci
or
submit
this
over
to
your
other
ci
system
or
whatever,
while
you're
just
editing
cool?
You
can
sure
you
can
get
release
time
feedback
of
okay,
this
deployed
out
to
ten
percent
of
nodes,
five
percent-
it
said
get
this
error
rate
all
this
okay.
Well,
let's
get
all
that
into
change
stream.
Let's
get
that
all
captured
and
centralized.
A
A
A
I
have
my
little
piece
of
code,
but
my
little
piece
is
a
small
piece
and
all
that,
but
we
have
to
think
bigger.
So
now,
there's
power
and
a
network
effect
when
you
start
to
think
about
change,
and
this
is
something
that
we
had
with
one
of
our
big
open
source
customers
that
uses
them,
we'll
we'll
we'll
call
them
react.
A
A
That's
pretty
cool
we're
trying
to
make
that
happen.
Like
that's
awesome,
so
that's
changed
before
the
change
like
before
you
receive
the
change
before
the
change
happens
to
you,
somebody's
proactively
thinking
about
how
that's
all
gonna
work,
but
it's
a
network
effect.
It's
not
something
that
you
can
do
just
one
organization
doing
their
own
ci.
You
have
to
share
this
and
make
us
better
because
we're
all
doing
it
together.
A
A
But
basically,
you
control
only
a
portion
of
what
your
user
experience
is.
In
the
end,
you
have
your
code,
that's
what
you
control
on
top
of
other
people's
code,
their
libraries
on
top
of
other
people's
computers,
aws
on
top
of
somebody
else's
network
aws,
and
your
npm
ls
cloud
and
att
and
level
three
and
all
the
people
that
are
providing
all
these
networks
all
over
the
world.
A
You
want
chaos,
engineering
put
real
users
on
something,
that's
chaos.
They
will
do
crazy,
crazy
stuff,
so
just
keep
zooming
out,
though
you
have
a
path
forward.
If
you
can
take
a
change
from
anywhere
and
react
to
it
code
is
all
we've
been
talking
about
from
this
unit
of
work
being
a
commit
code?
Is
this
small
thing
over
here
as
to
what
modern
application
delivery
is
looking
like.
A
So
I'm
asking
you
basically
to
shift
your
thinking
from
code
to
change.
It
doesn't
mean
you're
going
to
change
the
way
you
work
tomorrow.
It
doesn't
mean
you're
going
to
change
the
way
you
talk
about
that
next
pr
review
or
merge,
review
or
whatever,
but
I
want
you
to
think
about
how
there
are
so
many
inputs
into
your
system
that
are
not
the
things
that
you're
trying
to
be
deterministic
about,
there's
so
much
more
than
that.
A
A
I
want
to
be
able
to
absorb
change.
React
change,
deploy
change,
create
change.
Those
are
all
the
things
I
want
to
do
continuously
be
validating
trigger
things
back
in
from
what
going
on
in
release.
What's
going
on
monitoring?
What's
going
on
with
my
upstream
vendors,
my
suppliers,
I
need
like
an
internet
weather
report
and
I
need
to
react.
A
A
And
automating
human
emotions
is
really
really
difficult.
I
keep
trying
been
doing
it
for
10
years
I'll,
do
it
for
a
while
longer,
but
we
keep
trying
but
confidence.
Confidence
in
these
changes
is
actually
what
matters.
So
that's
the
end.
This
is
really
just
a
big
picture.
Big
thinking
thing
of
like
we
go
from
commit
to
changed,
and
that's
all
I'm
asking
you
to
do
is
change
the
way
you're
thinking
about
this
anyway,
I'm
mike
stonke
I'm
at
circleci
thanks.