►
Description
If you’re interested in decreasing your time-to-market and hitting your business goals faster, today’s session is for you. DevOps is a term commonly used across the industry, but putting it into practice and understanding the deep impact it can have on your business is harder to grasp. Let’s dive into how DevOps is both a process framework and a cultural practice, and how it can be implemented practically to accelerate innovation.
Join Anthony Borton, Solutions Engineering Manager at GitHub, Damian Brady, Senior Developer Advocate at GitHub, and Daniel Cho, Field Solutions Engineer at GitHub, to discuss all things DevOps in this interactive session. We’ll have polls, online chats, and live Q&A available to help you share your thoughts and experiences.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Let's
go
to
the
next
slide.
What
you'll
see
is
I'm
joined
today
by
someone
that
many
of
you
probably
know
you've
probably
seen
him
at
other
events
along
the
way,
but
damien
brady
is
a
senior
developer
advocate
here
at
github
and
has
been
working
in
the
devops
space,
both
in
australia
and
internationally
now
for
for
many
years
so,
rather
than
me
talk
too
much
about
it
damian.
Would
you
like
to
introduce
yourself
please,
sir.
B
Sure,
thanks
anthony
yeah,
really
good
to
be
here.
I
always
loved
talking
about
devops.
So
when
anthony
asked
whether
I
could
come
on
whether
I'd
be
interested.
Yes,
it
was
a
very
quick
answer.
So,
as
anthony
mentioned,
I've
been
working
kind
of
in
the
devops
space
for,
depending
on
how
you
count,
what
devops
is,
I
guess
for
about
10
years
or
so
so,
prior
to
working
at
github
in
developer
relations.
I
worked
at
microsoft.
B
You
may
know
the
team
that
I
worked
at
in
microsoft
under
donovan
brown
for
a
number
of
years
and
then
prior
to
that
I
was
at
octopus,
deploy
which
is
a
deployment
automation
team
did
a
bit
of
developer
relation
stuff,
then,
but
also
cut
a
bit
of
code.
Then,
before
that
I
was
in
consulting
around
agile
and
all
of
that
kind
of
peripheral
stuff
to
do
with
software
delivery.
You
know
the
whole
idea
of
getting
your
code
from
you
know
an
idea
all
the
way
into
production.
B
A
Cool
all
right,
sorry,
it
just
went
a
little
bit
frozen
there.
For
me,
I
apologize
all
right.
Well,
let's
go
on
to
the
next
slide
there.
So
as
far
as
our
session
goes
here
today,
it's
very
much
like
a
fireside
chat,
and
that
means
that
we
want
audience
participation.
We
are
really
excited
to
have
questions
from
the
audience
kind
of
it's
a
ask
us
anything.
Devops
related
kind
of
session,
so
get
involved,
you'll
see
in
the
goalcast
system
that
there's
a
chat
window
so
go
in
there
into
the
chat.
A
Just
introduce
yourself
just
say:
hi
that'd,
be
fantastic.
Hey
you'll
have
plenty
of
your
peers
in
there
as
well.
So
that
would
be
you
know,
wonderful,
there's,
q,
a
so
by
all
means
raise
your
hand,
ask
a
question
any
burning
question:
it
could
be
in
response
to
something
that
you
hear
damien
and
I
talk
about.
It
could
just
be
something
that
you'd
like
us
to
to
talk
about.
We've
got
a
a
bunch
of
topics,
a
few
questions
already,
but
please
to
get
the
best
value
out
of
your
your
time
with
us
today.
A
A
B
A
A
A
A
A
B
B
A
To
see
it,
that's
the
the
leading
one
yeah
excellent,
all
right,
so
there's
certainly,
let's
just
say
room
for
improvement.
That's
not
necessarily
what
I'm
going
to
say,
but
having
been
involved
in
the
industry
for
many
years,
I've
done
my
fair
share
of
manual
deployments
where
you've
opened
a
word
document.
You've
had
the
little
list
of
them
here
and
you
just
cross
your
fingers
that
you're
not
in
a
rush,
and
you
remember
to
do
it
on
each
member
of
the
cluster.
A
A
B
B
Look
so
I
don't
want
to
discount
ci
cd
at
all.
That
is
a
huge
part
of
the
whole
software
delivery
lifecycle,
and
it's
incredibly
important
that
you
know
you
have
this
good
automation
story.
There's
great
surveys
and
literature
out
there
that
demonstrate
that
having
a
good
automation
from
you
know,
all
the
way
from
your
code
being
committed.
All
the
way
through
to
production
is
extremely
important
and
correlates
really
well
with
your
great
outcomes,
but
that's
really
just
putting
stuff
into
production
right.
B
Yes,
you
have
your
tests
and
and
all
of
that
kind
of
stuff
to
make
sure
that
you're
not
yeah
that
you're
not
introducing
bugs
into
production,
but
you
still
don't
know
whether
you're
necessarily
introducing
value
into
the
system
there's
a
few
things
that
are
missing
from
just
straight
ci
cd,
so
I
can
put
a
new
feature
into
production
and
if
I
have
a
great
ci
cd
process
I
might
I
can
make
sure
that
there
are
no
known
bugs.
You
know
I'm
checking
against
bugs
that
everything's
performant.
B
B
A
B
You're
missing
a
few
things
like
the
measurement
of
whether
something
is
actually
actually
valuable
to
the
end
user
or
to
the
business
you're
missing
whether
things
are
working
as
expected
in
production
and
you're
also
missing
the
whole
cultural
side
of
devops,
which
is
you
know,
an
attitude
of
trust
between
the
developers
of
ownership
of
the
stuff
that
goes
into
production.
So
if,
if
something
fails
in
production,
whose
fault
is
it
you
know?
B
That's
quite
a
it's
quite
a
common
thing
in
a
lot
of
organizations,
and
that's
not
really
what
devops
is
about
devops
is
about
you
know,
getting
the
right
stuff
and
providing
value
putting
that
in
production.
So
I
rambled
a
bit
then,
but
the
the
the
ultimate
summary
I
guess
is
cicd
super
important,
but
you've
got
to
make
sure
that
your
focus
is
on
delivering
stuff,
that's
valuable
and
stuff.
That
is
providing
what
people
need
into
production
and
that
may
include
noticing,
when
something
isn't
right
and
being
able
to
remedy
that
quickly
as
well.
A
B
I'm
getting
the
impression
that
we've
got
a
little
freeze
then
as
well,
so
that
culture
is
probably
the
hardest
the
hardest
part
of
devops,
and
I
think
that
you
know
cicd
is
great.
You
can
you
can
learn
about
these
things.
You
know
from
any
number
of
places
you
can
use
any
number
of
tools
to
to
do
the
ci
cd
part,
but
you
know
improving
the
culture
of
an
organization
is,
is
a
hard
part.
So
maybe
we
should
drill
into
that
that
culture
side
a
bit
anthony.
A
Yeah
look
absolutely
while
we're
talking,
I
will
take
a
second
just
to
introduce
daniel
daniel
is
helping
us
he's
our
moderator.
I
should
have
introduced
him
at
the
very
very
start,
he's
a
wonderful
solutions,
engineer
for
github,
and
he
is
there
looking
out
for
questions
from
the
audience,
so
by
all
means
have
a
chat
with
with
daniel.
I
think
he's
introduced
himself
now
in
the
chat
or
the
q
a
window,
so
take
full
advantage
of
that.
Now,
as
we
move
on
to
culture,
I
guess
I've
always
found.
A
A
Something
also
found
is
frustration
among
teams
that
want
to
do
a
devops
transformation
that
wants
to
change
the
way
they're
working,
but
are
often
impeded,
because
maybe
senior
leadership
doesn't
buy
into
it
just
yet
and
the
other.
The
part
two
to
that
comment
might
be
that
they're,
given
a
very
short
window.
Okay,
you
can
try
this
devops
you've
got
a
month.
B
Yeah,
I've-
that
is
a
super
common
story
and
I
know
you've
you've
seen
this
over
and
over
again
as
well.
But,
yes,
I
get
that
impression
as
well
so
kind
of
going
going
some
way
to
convincing
people
that
this
is
a
worthwhile
endeavor,
there's
a
number
of
ways
that
I
kind
of
suggest
that
teams
address
it.
The
first
thing
is:
don't
don't
boil
the
ocean?
Don't
try
to
exactly
like
you
said,
don't
say,
you've
got
a
month
to
implement
a
complete
end-to-end.
B
A
B
Be
a
really
strong
part
of
it
so
yeah.
If
the
messaging
comes
from
the
top
and
says
we
are
going
to
do
devops
now,
you
have
this
much
time
to
implement
it.
We've
bought
you
a
devops
solution.
You
know
here's
a
tool
set.
That
means
we're
going
to
be
good
in
a
month.
That's
it's
really
not
how
it's
going
to
work.
My
suggestions
would
be
to
start
small
and
continuously
improve
your
end-to-end
kind
of
life
cycle
and
improve
one
thing
at
a
time.
B
So
to
quote
my
previous
boss,
donovan
brown
look
at
what
hurts
the
most
and
fix
that
and
then
look
at
the
next
thing
that
hurts
the
most
and
fix
that,
so
that
combined
with
actually
trusting
your
people
to
you
know
to
improve
things
and
to
be
doing
their
best.
I
guess
is,
is
a
way
to
get
that
going
now.
If
management
is
not,
you
know
as
flexible
with
that,
as
as
you
want
them
to
be
so,
in
other
words,
they
just
say
no.
A
B
B
Although
they're
still
going
on
gene
kim
nicole,
dr
nicole
forsgren,
was
leading
it
and
jess
humble,
I
believe
one
of
the
stats
from
there
was
around
a
correlation
between
a
mature
devops
culture
and
a
company's
own
metrics
about
whether
they've
succeeded
and
there's
a
correlation
between
a
high-performing,
devops
culture
in
an
organization
and
how
well
that
organization
performs
based
on
its
own
measures
of
success.
So
we're
not
talking
about
you,
know
obscure
things
like
this
is
how
fast
you
can
get
code
into
production,
although
there's
obviously
correlations
there
we're
talking
about
real.
B
You
know
this
company's
revenue
over
this
period
of
time,
or
even
things
like
employee
retention,
devops,
a
high-performing,
devops
culture
that
has
a
really
good
devops
environment
is
correlated
with
a
lower.
What's
the
word,
I'm
looking
for
a
lower
rate
of
people
leaving
to
go
for
other
companies
go
and
work
for
other
companies
which,
especially
in
the
us,
is
a
serious
issue
right
at
the
moment.
So
all
of
these
things,
like
that
that
literature
is
in
you,
can
just
find
one
of
these
reports.
Look
for
a
state
of
devops
report.
B
Look
for
a
gartner
report!
Look
for
mckinsey
report,
any
other
number
of
those
print
it
out,
throw
it
on
a
desk
does
support
not
just
the
fact
that
devops
improves
the
company
outcomes,
but
these
are
the
ways
that
you
can
do
it
and
it's
gradual.
It's
not
a
pick
up
everything
change
at
all
and
and
expect
to
get
success.
B
A
I
just
want
to
amplify
one
of
the
the
things
from
the
you
talk
that
really
stood
out
to
me.
It
was
it
was
that
quote
from
donovan
brown
around.
If
it
hurts
do
it
more
often,
I
look
back
in
the
early
parts
of
my
career
doing
those
manual
deployments
with
word
documents
and
grumbling
every
time.
I
did
it
and
I
did
it
again
and
I
did
it
again,
because
the
mindset
was
just
do
it
as
quick
as
you
can
and
get
back
to
the
interesting
work
with
the
devops
mindset
today.
A
A
Well,
the
first
one
is
a
little
bit
long,
so
yeah
when
a
project
starts,
we
create
a
main
branch
from
the
main
branch
we
create
feature
f1,
let's
say
now:
we
want
to
start
creating
ci
cd
scripts
from
feature
f1,
but
github
actions
don't
allow
us
to
create
a
workflow
from
a
branch
other
than
main
azure.
Devops
is
better
at
this
aspect.
A
B
Yeah,
so
there's
a
there's
a
benefit,
obviously
of
having
your
build
definitions,
so
your
your
ci
living
alongside
the
code,
and
it
is
that
if
you
change
the
way
you
build
your
application,
you
can
change
that
alongside
the
code
that
you've
changed,
but
this
this
the
point
on
it's
only
the
actions
running
in
maine
or
only
the
the
workplace
that
run
in
maine,
I'm
not
100.
Sure
on
that
one
do
you
know,
do
you
know
if
that
is
the
case,
I'm
just
going
to
assume
that
it
is,
unless
you
tell
me
otherwise,.
B
We
can
research
that,
but
the
other
thing
that
you
could
do-
I
guess,
is
fork
that
repository
rather
than
create
a
branch.
If
you
need
to
change
the
workflow,
which
presumably
is
not
going
to
happen
on
every
single
feature-
branch
that
you
create.
If
you
do
need
to
change
the
workflow
forking
to
another
repository,
so
you
can
really
have
your
own
freedom
with
that.
That
workflow
is
probably
a
good
idea.
B
That
said,
if
you
are
using
azure
pipelines
right
now-
and
this
is
a
feature
that
your
you
value
a
great
deal-
my
suggestion
would
be
to
continue
using
azure
pipelines.
I
mean
if
this
is
a
feature
that
is
solving
a
problem
for
you
and
it's
in
one
product
and
not
the
other,
then
that
that
kind
of
answers
itself.
B
I
am
a
huge
fan
in
the
agile
system
of
being
really
really
close
to
your
main
branch,
and
that
means
yes,
feature
branches
are
a
great
idea,
but
having
them
very
short-lived,
so
really
small
feature
branches
that
don't
stray
from
maine
very
long
and
don't
stick
around
very
long
is
a
great
idea.
Pull
requests
back
into
your
main
branch
to
make
sure
that
you
know
everything
is:
is
being
merged
really
regularly
great
idea
as
well,
but
for
smaller
teams
and
I'm
probably
going
against
the
grain
here
for
smaller
teams.
B
I
don't
hate
committing
directly
into
the
main
branch
provided
you
have
decent
checks
and
balances
decent.
You
know
ci
systems
as
well
for
smaller
commits
and
smaller
changes.
I
don't
mind
working
against
the
main
branch.
Primarily,
I
think
that's
probably
more
agile.
I
guess
more
fast
moving
if
everybody
is
committing
to
the
same
code
as
opposed
to
long
periods
of
work
in
a
feature
branch
that
get
merged
in
you
know
several
weeks
or
a
month
later.
B
That
seems
to
be,
in
my
mind
at
least
a
bit
more
waterfally.
I
guess
go
away,
do
some
work
and
then
come
back
so
yeah
my
preferred
way.
I
guess
is
really
short
feature
branches
and
pull
requests
back
into
the
main,
but
I
don't
hate
committing
directly
to
maine
or
pushing
directly
to
maine,
especially
in
small
teams.
A
B
B
B
Yeah
I
mean
working
with
open
source
is
a
thing
that
github
does
very
well
also
open
source.
Tooling,
though
it's
a
bit
it's
a
bit
difficult
because
most
of
my
open
sorry,
most
of
my
devops
tooling,
is
is
azure
pipelines
or
or
github
actions,
and
parts
of
that
are
open.
Parts
of
that
code
base
is
open
source
so,
for
example,
the
the
runners,
the
actual
actions
themselves
or
the
tasks
themselves
and
the
runners
themselves
in
pipelines.
Those
are
open
source,
but
the
engines
behind
them.
A
A
A
Okay,
I'm
gonna
go
ahead
and
just
click
on
end
for
the
moment
and
I'll
see.
If
there's
anything
interesting,
I
can
come
back
to
on
that
one
all
right.
So
let
me
go
back
to
another
question
here:
would
we
get
a
sandbox
or
test
console
for
creating
and
executing
actions
and
workflows
without
committing
them
to
the
repository.
B
A
B
B
This
is
a
a
project
that
comes
from
the
community
that
allows
you
to
run
your
your
actions,
workflows
locally
on
your
local
machine.
Now
the
difficulty-
I
guess
with
running
these
on
your
local
machine
is-
we
have
quite
well
defined,
hosted
runners,
for
example,
that
have
certain
software.
They
expect
things
in
a
particular
place.
They
have
a
very
specific
setup.
If
you're
running
these
actions
just
locally
on
your
machine,
there
may
be
aspects
of
it
missing.
B
So
this
this
project
tries
to
recreate
them
as
much
as
possible,
and
it
does
quite
a
good
job
in
a
lot
of
cases,
but
it
may
not
pick
up
everything
that
you're
that
you're
doing
so
yeah.
There
is,
I
believe,
as
well
in
actions
now
I'm
going
to
just
do
this
in
the
background
as
well,
because
I
want
to
make
sure
that
I'm
giving
everybody
the
right
information.
B
B
Let
me
see
if
I
can
and
apologies
for
this
I've
just
got
another
screen,
I'm
just
going
through.
I
just
want
to
make
sure
I'm
giving
everybody
the
right
information
it
may
be
in
the
future,
and
hopefully
it's
something
that
I'm
allowed
to
talk
about
where
in
the
future
there
will
be
a
way
of
checking.
I
guess
whether
a
pipeline
looks
right
or
not
a
pipeline.
A
workflow
looks
right
before
committing
it,
I'm
not
seeing
it
in
my
account.
B
A
B
So
short
answer
I'd
say:
no,
I
don't
think
it
is
a
requirement.
It
can
certainly
speed
things
up.
I
guess
for
teams
that
are
unfamiliar
with
devops
practices
in
general.
However,
I'd
say:
don't
discount
the
domain
knowledge
that
your
team
has
as
well.
So
a
devops
consultant
who's
done
a
lot
of
automation,
a
lot
of
deployment,
a
lot
of
infrastructure
as
code
and
all
that
kind
of
stuff
they
can.
B
Bring
that
kind
of
knowledge
and
that
kind
of
expertise
and
those
skill
sets
to
your
organization,
but
they
haven't
worked
on
your
product
before
they
don't
know
what
your
code
looks
like,
how
it
runs
and
how
it
works.
So
that
is
extremely
useful
knowledge
if
you
work
on
that
premise
of
finding
something,
that's
that
hurts
and
fixing
that
and
then
finding
the
next
thing
that
hurts
and
fixing
that
it's
relatively
easy
to,
or
not.
B
I
won't
say
easy
sorry,
but
it's
relatively
it's
entirely
possible
to
learn
what
you
need
to
know
as
you
go
if
you're
just
improving
these
things,
one
at
a
time,
so
I
would,
I
would
say
I
don't
think
it's.
I
don't
think
it's
vital
that
you
get
a
devops
consultant
or
a
devops
expert
in
your
organization.
A
A
B
I
would
say
no,
I
think,
I've
already
kind
of
touched
on
this,
a
little
bit
that
if
there
is
a
tool
that
you're
currently
using
that
solves
your
problems,
I
would
recommend
continuing
to
use
that
tool.
It's
a
really
common
thing
in
our
industry.
I
think
to
look
at
the
new
shiny
tool
set
or
the
new
shiny
platform
or
framework,
or
something
like
that
and
want
to
change,
but
I
think
there
needs
to
be
a
bit
of
pragmatism
around
whether
it's
worthwhile
making
that
change
now.
B
The
flip
side
of
that,
obviously,
is
that
if
your
tool
set
is
lacking
in
a
particular
way
or
if
there's
something
you'd
like
to
do
that,
you
can't
do
with
your
current
tool
set
without
you
know:
horrible
work,
arounds
or
writing
a
whole
bunch
of
your
own
code.
Then
that's
probably
a
good
opportunity
to
have
a
look
at
what
alternatives.
There
are
I've,
seen
very,
very
effective
devops
practices
and
devops
processes
in
organizations
that
are
ultimately
writing
and
maintaining
their
own
scripts
they're,
not
really
using
anything
other
than
command
lines.
B
That,
obviously,
though,
if
you
are
spending
a
huge
amount
of
time,
maintaining
all
of
your
own
custom
scripts
and
your
own
custom
work
like
that,
that
is
time
that
you
could
probably
outsource
to
something
like
azure
pipelines
or
github
actions.
You
know
where
github
actions,
for
example
the
actions
team,
make
sure
that
we
always
have
you
know
a
newer
version
of
the
operating
systems
that
it
runs
on
a
newer
version
of
the
libraries
that
you
might
need,
and
we
we
test
those
things
quite
thoroughly.
B
So
you
know
that
when
you
actually
go
and
build
the
latest.net
framework
using
our
hosted
runners
that
all
of
that
infrastructure
is
in
place,
you
don't
have
to
worry
about
that
side.
So
much
so
yeah
that
that's,
I
guess
you
know
kind
of
down
in
the
in
the
weeds
a
bit,
but
the
yeah.
The
short
version
is
don't
change
just
for
changes,
changes
sake.
I
think
look
at
what
the
offerings
are
and
look
at
what
how
these
things
can
help
you
and
what
you
might
be
lacking
in
your
organization
or
your
process.
A
B
A
B
Does
that
means
you
know
you
can
use
any
of
the.
I
think
it's
we're
getting
close
to
14
000
actions
in
the
marketplace
now,
so
you
can
use
any
of
those
and
actually,
while
I'm
talking,
I'm
just
gonna,
have
a
quick
look
at
the
marketplace
to
see
if
there
are
some
wordpress
ones,
but
so
you
can
use
you
know
any
of
those
actions,
but
you
can
also
just
run
something
from
the
command
line.
B
So
if
you
are
using
wp
cli,
which
I
assume
is
a
command
line
interface
for
wordpress,
you
could
quite
easily
call
wp
cli
from
a
step
or
from
a
task.
Sorry,
you
know
in
a
github
actions
workflow,
which
kind
of
gives
you
the
power
of
that
that
ci
cd,
but
you
know
also
the
power
of
that
automations
platform,
but
also
using
whichever
tools
you
have
so
I'm
just
doing
a
really
quick
search
for
wp
cli
and
there's
nothing
there
by
the
way.
B
If
you
wanted
to
have
a
look
at
this
as
well
github.com
marketplace
and
then
you
can
search
so
I've
got
28
results
for
wordpress
in
actions.
I
can't
see
anything
specifically
for
wp
cli.
However,
there's
some
for
deploying
wordpress
there's
some
for
vulnerability,
checks,
tag,
cleaners,
wordpress,
pod
file,
generator.
I
don't
know
what
that
is.
That
even
is
so
I
mean
you
may
find
something
in
that
marketplace.
That
can
do
what
you
want
it
to
do,
but
if
not,
you
can
always
just
run
a
command
line.
B
Now,
if
you
need
tools
installed,
you
can
either
install
them
as
part
of
that
workflow,
so
pull
down
an
executable
and
then
run
that
as
part
of
your
workflow
or
you
could
use
your
own
kind
of
hosted,
self-hosted
runners
and
run
it
on
your
own
machine,
even
your
own
wordpress
machine.
If
you
need
to
be
right
there
on
that
same
machine
and
the
actions
workflow
will
run
on
that
wordpress
machine,
which
means
you
know
it's
just
like
typing
in
commands
on
that
local
machine,
so
definitely
options
for
that.
A
B
Right
three:
I'm
limited
to
three
critical
principles
to
consider
we're
moving
code
to
production
for
the
first
time.
So
my
my
ultimate
one-
and
I
hope
this
doesn't
incorporate
everything
else,
I'm
going
to
say,
but
my
ultimate
one
is
to
be
as
sure
as
you
possibly
can
that
the
code
that
you're
going
to
end
up
running
in
production
is
the
same
code
that
you've
tested
so.
B
B
If
you
want
to
make
sure
that
they're
running
they're
going
to
run
okay
in
production,
you
should
try
and
deploy
those
artifacts
to
a
production
like
system.
Now
I
say
production
like
because
you're
never
ever
going
to
get
a
test
server
that
works
the
same
way
as
production,
the
specs
might
be
identical,
but
the
users
aren't
real
production
users,
so
you
know
you're,
never
you're
never
going
to
be
at
a
100
match.
B
However,
if
you're
using
that
same
artifact
deploying
it
to
a
system
that
looks
the
same
as
much
as
you
can
tell,
then
you
can
be
relatively
sure.
I
guess
if
you
run
the
correct
tests
and
some
comprehensive
tests
that
when
you
put
that
same
resources
or
those
same
resources
into
production,
then
it's
going
to
work
the
same
way
now.
B
B
So
that
would
be
one
critical
principle
principle:
if
you're
putting
it
into
production,
try
to
test
it
as
close
to
production,
as
you
possibly
can.
The
next
principle
I'd
say
is
make
sure
you
have
a
roll
back
or
roll
forward
option.
So
my
preference
is
if
something
goes
wrong
in
production.
You
can
fix
that
problem
and
put
a
new
version
into
production
to
fix
that
issue
very
very
quickly,
but
rollback
is
a
real
situation
for
a
lot
of
organizations.
So
if
you
put
code
into
production,
what
happens
if
that
goes
wrong?
B
If
you
know
it's
very,
very
likely
to
work
in
production,
then
hopefully
you're
not
gonna
have
to
roll
back,
but
things
always
go
wrong,
so
you
need
to
at
least
account
for
what
happens
when
you,
when
you're
doing
that
work
and
that
final
critical
principle,
it
doesn't
even
sound
like
I'm
coming
up
with
these
off
the
top
of
my
head.
Doesn't
it
sounds
like
I've
said
that
the
final
one,
I
would
say
is
try
to
try
to
maintain
a
culture
of
trust
and
ownership.
I
guess
so
when.
B
Goes
into
production,
it
shouldn't
be
a
case
that
you
know
you
put
it
in
production
on
a
friday
afternoon,
and
then
the
person
has
to
deal
with
any
repercussions
is
whoever's
on
call
over
the
weekend
and
maybe
I'll
look
at
it
on
a
monday
right.
The
deployment
to
production.
If
I
write
code
that
ends
up
in
production,
I
should
be
responsible
to
a
large
extent
for
making
sure
that
that
code
is
is
what
it
should
be.
It's
solving
the
right
problems.
If
something
goes
wrong,
I
should
feel
ownership
over
what
is
in
production.
B
A
A
You
know
each
of
those
teams
owned
everything
from
talking
to
the
customers,
the
design,
the
security,
the
deployment,
the
operation
building,
the
features
you
name
it,
and
that
really
goes
to
your
point
of
of
ownership
and
when
they,
when
people
heard
that
they
also
did
production
support,
they
were
a
little
surprised.
But
what
I
learned
with
the
culture
was
that
they
they
had
that
ownership.
A
B
Exactly
and
it
comes
down
to
sorry,
not
ownership,
but
kind
of
feeling
like
this
is
yours
rather
than
you're
just
performing
a
task
like
this
is
the
thing
that
you
know.
This
is
the
thing
that
you're
you're
building
and
it's
not
just
ticking
some
things
or
you
know,
moving
some
cards
from
one
side
of
the
board
to
another.
B
Cultural
advisors-
I
I
think
I
don't
know
whether
you
call
himself
that,
but
some
of
the
work
that
he's
done
especially
around
his
more
recent
one
about
the
five
ideals,
a
lot
of
that
kind
of
comes
into
play
here,
as
well,
that
first
ideal
of
locality
and
simplicity
which
he
talks
about,
which
is
basically
you
know,
can
I
make
this
change
and
see
that
change
go
all
the
way
through
to
production?
Or
you
know
it's
like
the
reverse
bus
factor,
which
is
you
know
the
coffee
factory?
B
How
many
people
do
I
need
to
talk
to
in
different
departments
to
get
something
working?
Ideally,
I
don't
need
to.
I
have
the
ability
to
make
that
change
within
you
know
my
my
immediate
sphere
and
then
all
the
way
through
that
fifth
ideal,
that
he
has
there,
which
is
customer
focus,
so
that
should
be
your
aim
like
the
customer
being
happy.
Not
you
know
you
moving
a
card
from
one
end
to
the
other
anyway,.
A
B
B
With
azure,
but
I
know
this
principle
exists
in
a
lot
of
places,
but
an
azure
web
app.
You
can
deploy
to
a
slot
so
to
a
staging
slot
or
a
pre-production
slot,
and
then
you
can
hit
that
url
and
make
sure
everything's
up
and
running,
and
then
you
can
just
swap
that
slot
with
the
production
one.
So
the
url.
B
Just
starts
pointing
the
production.
Url
starts
pointing
to
the
other
one.
I
think
that
process
of
making
sure
it's
all
running
and
then
flicking
the
switch.
I
don't
think
that
needs
a
human.
I
think
that
can
be
a
you
know:
a
curl
command,
if
you
really
want,
but
if
pre-production
means
a
qa
environment
or
a
staging
environment,
or
something
like
that,
then
I
think
having
human
eyes
on
it
makes
sense.
B
A
B
So
yeah
you
can
absolutely
use
those
ones.
I
think
all
I'm
all
I'm
coming
up
with
really
is
the
stuff
that
that
writing
android
and
ios
applications
in
you
know
c-sharp,
for
example,
was
open
source,
I
believe
originally,
and
I'm
blanking
as
well
in
the
name
of
that
product,
but
yeah
see
open
source,
crcd
tools
for
android
and
ios.
A
A
B
B
Guys,
how
did
I
not?
How
did
I
not
remember
xamarin
there
you
go
yeah,
so
I
mean
the
short
version
for
writing.
Android
apps
is
really
you
just
need
a
java,
anything
that
can
compile
java,
so
any
open
source,
devops
tool
or
any
devops
tool
or
ci
cd
tool
that
can
run
java.
You
can
compile
an
android
application
and
end
up
with
an
apk.
B
Fastlane
is
also
a
good
good
tool
thanks
to
kev
for
ios,
though
you
do
need
to
compile
on
a
mac.
I
know
github
actions
and
azure
pipelines.
Allow
you
to
run
on
hosted
macs,
so
you
can
just
run
on
a
mac
and
compile
your
ios
application
on
a
mac.
Your
hosted
brother,
or,
if
you
have
your
own
mac,
you
can
run.
You
know
your
your
own.
You
know
self-hosted
runner
as
well,
so
you
should
be
able
to
do
it
really
with
any
any
tool
that
that
can
run.
A
A
A
B
Let
me
just
quickly
and
I'm
going
to
try
and
multitask
here
as
well.
I
would
so
my
my
immediate
reaction
for
this
one
is,
you
know
I
don't
know
the
answer,
but
I
can
where
I
would
look
for.
That
answer
is
by
looking
at
the
github
docs
and
there's
a
reference
section
for
the
graphql
api,
which
should
give
you.
B
B
Nodes
and
then
yeah
so
yeah,
I'm
going
to
give
you
the
the
url
that
I'm
looking
at,
but
I
think
it
would
take
me
a
little
bit
of
time
to
to
actually
hunt
it
down.
However,
I
do
know
that
the
graphql,
so
whenever
I've
worked
with
that
graphql
api,
occasionally
I
come
across
something
that
is
not
there
or
I
don't.
I
don't
think
I
can
find.
B
If
you
wanted
to
ping
me
directly,
I
can
hunt
it
down
a
little
bit
more
or
at
least
speak
to
the
actions
team
to
see
whether
that
should
be
there.
My
guess
is
it
should
so
either
it'd
be
somewhere
or
you
know,
or
it
is
a
thing
that's
missing,
but
yeah.
If
you
could
ping
me
directly,
that
would
be
I
can.
I
can
hunt
that
down.
A
B
Ultimately,
that
is
rather
than
taking
two
silos
and
putting
them
together.
So
everybody
works
together.
It's
just
putting
another
silo
in
the
middle,
so
that
is
a
really
common
pattern
and
unfortunately,
you
see
that
a
lot
if
you're
in
an
organization
that
has
a
devops
department-
or
you
know,
a
team
that
does
all
the
devops
you're
not
really
doing
it
correctly
right.
You've
introduced
a
new
silo
like
a
new
team
that
doesn't
communicate
well
with
the
other
teams.
B
B
It
doesn't
really
make
sense.
It's
it's.
A
devops
is
about
a
team
effort
like
about
a
team,
a
group
of
people
working
together
with
a
common
goal
rather
than
an
organization.
So
yes,
if
you
have
a
devops
team
that
does
all
of
the
devops,
that's
not
really
the
point.
That
said
you
can
have
a
devops
team
that
provides
kind
of
a
center
of
excellence.
B
A
B
B
Yeah
definitely
it
should,
in
my
mind,
cover
everything
from
an
idea
and
that's
even
gathering
ideas
or
gathering
feedback
from
customers
all
the
way
through
to
running
in
production
and
then
feeding
back
the
information
that
you
have
in
production
back
to
that
life
cycle.
So
I
don't
know
whether
you've
seen
this
like
a
figure.
Eight
sideways
figure.
Eight,
like
an
infinity,
sign
diagram
that
that
people
see.
I
talk
about
a
lot
when
it
comes
to
devops.
B
That
simplifies
it
a
bit.
Obviously,
there's
just
like
plan,
develop
test,
deploy
and
then
go
all
the
way
around,
but
devops
ideally
should
cover
everything
that
you
care
about
with
that
product,
all
the
way
from
idea
to
production
and
and
back
again,
so
there's
a
common
strategy
of
as
a
common
thing.
That
happens
where
devsecops
is
a
perfect
example
where
they're
like,
oh
you
know,
we
were
doing
devops,
we
didn't.
B
B
If
these
are
things
you
care
about
with
the
delivery
of
your
software
to
your
customers,
then
they
should
be
part
of
that
process.
So
yes,
I
I
totally
agree
with
that
statement
that
it
should
be
about
the
entire
life
cycle.
It
should
be
about
everything
from
idea
to
production
and
feeding
back
into
those
ideas
as
well
so
yeah
100
with
you.
There.
A
Awesome
well,
thank
you
very
much
for
taking
the
time
to
join
us
today,
hopefully,
by
the
sounds
of
it.
You
know.
You've
certainly
had
a
lot
of
experience
in
the
devops
arena,
based
on
some
of
those
questions
and
sorry
the
answers
that
you've
had
there
for
us.
So
it's
been
an
absolute
pleasure
damian.
We
might
get
back
to
the
slides
and
get
people
excited
about
tomorrow's
in
focus
session.
A
A
We
do
take
your
feedback
seriously
and
our
learnings
are
important
to
optimize
our
future
programs
to
continue
to
raise
the
bar
for
you.
So
don't
be
shy.
Please
tell
us
what
you
think
and
with
that
note
my
battle
thanks
again
daniel.
It's
been
a
pleasure
thanks
daniel
in
the
chat
there
for
all
your
wonderful
support
there
and
thanks
for
joining
us
here
today
at
infocus.