►
From YouTube: Rethinking the SDLC - GitHub Universe 2021
Description
Presented by Emily Freeman, Author, DevOps for Dummies
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
#SDLC #DEVOPS
A
A
A
A
Azure
and
gcp
didn't
exist
yet
at
least
not
publicly.
The
majority
of
companies
maintained
their
own
infrastructure
developers,
wrote
code
and
relied
on
sys
admins
to
deploy
new
code
at
scheduled
intervals.
Sometimes
months
apart,
container
technology,
hadn't
been
invented
and
applications
adhered
to
a
monolithic
architecture.
Databases
were
almost
completely
relational,
serverless
wasn't
even
a
concept.
A
Everything
from
the
application
to
the
engineers
was
centralized.
Our
current
ecosystem
couldn't
be
more
different.
Now,
don't
get
me
wrong.
Software
is
still
hard,
it
always
will
be,
but
we
continue
to
find
novel
solutions
to
consistently
difficult
persistent
problems
now.
Some
of
these
end
up
being
a
sort
of
rebranding
of
old
ideas,
but
others
are
a
unique
and
clever,
take
to
abstracting
complexity
or
automating
toil
or
perhaps
most
important,
rethinking
even
challenging
the
premises
that
we
have
accepted
as
canon
for
years,
if
not
decades.
A
A
For
some
it
can
be
distilled
to
continuous
integration
and
continuous
delivery,
ci
cd
for
others.
It's
simply
deploying
code
more
frequently
adding
tests
security
gates
for
others.
It's
organizational
they've
added
a
platform
team,
even
a
questionably,
named
devops
team,
or
have
created
an
engineering
structure
that
focuses
on
a
separation
of
concerns,
leaving
feature
teams
to
manage
the
development
deployment,
security
and
maintenance
of
their
siloed
services.
A
Whatever
the
interpretation
what's
really
important,
is
there
isn't
a
universally
accepted
standard
of
what
devops
is
or
what
it
looks
like
in
execution?
It's
a
philosophy,
more
than
anything
else,
a
framework
that
people
can
utilize
to
configure
and
customize
their
specific
circumstances
to
modern
development
practices.
A
The
characteristic
of
devops
that
I
think
we
can
all
agree
on
is
that
it
attempted
to
capture
the
challenges
of
the
entire
software
development
process.
It's
that
broad
umbrella.
That
holistic
view
that
I
think
we
should
breathe
life
into
again.
The
challenge
we
face
is
that
devops
is
an
increasingly
outmoded
solution
to
a
previous
problem.
A
A
I
believe
the
era
of
devops
is
waning
and
in
this
moment,
as
the
sun
sets
on
devops,
we
have
a
unique
opportunity
to
rethink
rebuild
even
re-platform.
Now
I
don't
have
a
crystal
ball.
That
would
be
mighty
handy,
I'm
not
completely
certain
what
the
next
decade
of
tech
really
looks
like,
and
I
can't
write
this
story
alone.
I
need
you,
but
I
have
some
ideas
that
I
think
can
get.
A
The
conversation
started,
I
believe,
to
build
on
what
was
we
have
to
throw
away
the
assumptions
that
we've
taken
for
granted
all
this
time
in
order
to
move
forward,
we
must
first
step
back
the
software
or
systems
development
life
cycle.
What
we
call
ubiquitously
the
sdlc
has
been
in
use
since
the
1960s,
and
it's
remained
more
or
less
the
same
since,
before
colored
television
and
the
touchstone
phone
over
the
last
60
years,
we've
made
tweaks
slight
adjustments,
we've
massaged
it
a
little
bit.
A
A
A
Nearly
everything
around
us
is
a
construct,
a
model,
an
artifact
of
a
human
idea,
the
chair
you're
sitting
in
the
desk.
You
work
at
the
mug
from
which
you
drink
coffee
and
sometimes
wine,
buildings,
toilets
plumbing
roads,
cars,
art,
computers,
everything,
the
sdlc
is
a
remnant,
an
artifact
of
a
previous
era,
and
I
think
we
should
throw
it
away
or
more
accurately,
replace
it,
replace
it
with
something
that
better
reflects
the
nature
of
our
work.
A
It
just
can't-
and
these
two
ideas
aren't
mutually
exclusive-
that
the
sdlc
was
industry,
changing
valuable
and
extraordinarily
impactful,
and
that
it's
time
for
something
new,
I
believe
we
are
strong
enough
to
hold
these
two
ideas
at
the
same
time
showing
respect
for
the
past
while
envisioning
the
future.
I
don't
know
about
you.
I
have
never
had
a
software
project
go
smoothly
in
one
go,
no
matter
how
small,
even
if
I'm
the
only
person
working
on
it
and
committing
directly
to
maine
like
a
maverick
software
development
is
chaos.
A
It's
a
study
in
entropy
and
it's
not
exactly
getting
any
more
simple.
The
model
with
which
we
think
and
talk
about
software
development
must
capture
the
multi-threaded
non-sequential
nature
of
our
work.
It
should
embody
the
roles
engineers
take
on
and
the
considerations
they
encounter
along
the
way
it
should
build
on
the
foundations
of
agile
and
devops
and
represent
the
iterative
nature
of
continuous
innovation.
A
A
What
I
settled
on
is
the
revolution
model.
I
believe
the
visualization
of
revolution
is
capable
of
capturing
the
pivotal
moments
of
any
software
scenario
and
I'm
going
to
dive
into
all
the
discrete
elements
in
a
moment,
but
I
want
to
give
you
a
moment
to
have
a
first
impression
to
really
absorb
the
idea.
A
I
am
challenging
a
60
year
old
model
that
is
embedded
into
our
daily
language.
I
don't
expect
gartner
to
build
a
magic
quadrant
around
this
tomorrow,
but
that
would
be
super
cool
and
you
should
call
me
instead.
My
mission
in
this
is
to
challenge
the
status
quo
and
to
create
a
model
that
I
think
more
accurately
reflects
the
complexity
of
modern
cloud
native
software
development.
A
The
revolution
model
is
constructed
of
five
concentric
circles,
describing
the
critical
roles
of
software
development
architecting,
developing
automating,
deploying
and
operating
intersecting.
Each
loop
are
six
spokes
that
describe
the
production
considerations.
Every
engineer
must
consider
throughout
any
engineering
work,
testability,
securability,
reliability,
observability
flexibility
and
scalability.
A
The
considerations
listed
are
not
all
encompassing.
There
are,
of
course,
things
not
explicitly
included,
but
I
figured
if
I
put
20
spokes.
Some
of
us
might
get
a
little
overwhelmed
myself
included.
So,
let's
dive
a
little
bit
deeper,
we
have
long
used
personas
as
a
default
way
to
divide
audiences
and
tailor
messages
to
group
people.
Every
company
in
the
world
right
now
is
repeating
a
mantra
of
developers.
Developers,
developers
but
personas
have
always
bugged
me
a
bit
because
the
approach
typically
either
oversimplifies
someone's
career
or
needlessly
complicates
it.
A
A
On
the
other
hand,
I
don't
think
we
need
to
tailor
messages
so
specifically
as
to
call
out
the
difference
between
a
devops
engineer
or
a
released
engineer,
certainly
not
between
a
security
administrator
and
a
security
engineer,
but
perhaps
most
critically,
I
believe,
personas
are
immutable.
A
persona
is
wholly
dependent
on
how
someone
identifies
themselves.
It's
intrinsic,
not
extrinsic,
their
titles
may
change,
their
jobs
may
differ,
but
they're,
probably
still
selecting
that
same
persona.
On
that
ubiquitous
drop
down.
We
all
have
to
choose
from
when
registering
for
an
event.
A
A
Roles
are
very
different.
Roles.
Are
temporary
inconsistent
constantly
fluctuating.
If
I
were
an
actress,
the
parts
I
played
would
be
lengthy
and
varied,
but
the
persona
I
would
identify,
as
would
remain,
an
actor
an
artist.
Your
work
isn't
confined
to
a
single
set
of
skills.
It
may
have
been
a
decade
ago,
but
not
today,
in
any
given
week
or
sprint,
you
may
play
the
role
of
an
architect
thinking
about
how
to
design
a
feature
or
service
a
developer,
building
out
code
or
fixing
a
bug,
an
automation,
engineer.
A
Looking
at
how
to
improve
the
manual
processes,
we
often
refer
to
as
toil
a
release,
engineer
deploying
code
to
different
environments
or
releasing
it
to
customers
or
an
operations
engineer,
ensuring
an
application
functions
in
consistent,
expected
ways
and
no
matter
what
role
we
play.
We
have
to
consider
a
number
of
issues.
The
first
is
testability.
A
All
software
systems
require
testing
to
assure
architects
that
designs
work
developers.
The
code
works
operators
that
infrastructure
is
running
as
expected,
and
engineers
of
all
disciplines
that
code
changes
won't
bring
down.
The
system.
Testing
in
its
many
forms
is
what
enables
systems
to
be
durable
and
have
longevity.
A
A
A
system
without
tests
is
a
disaster
waiting
to
happen,
which
is
why
testability
is
first
among
equals
at
this
particular
round
table
security
is
everyone's
responsibility,
but
few
understand
how
to
design
and
execute
secure
systems.
I
struggle
with
this
security.
Incidents,
for
the
most
part,
are
what
we
call
high
impact
low
probability.
Events,
the
really
big
disasters,
the
ones
that
end
up
on
the
news
and
get
us
all
free
credit
reporting
for
a
year.
They
don't
happen
super
frequently
and
thank
goodness
because
you
know
that
there
are
endless
small
vulnerabilities
lurking
in
our
systems.
A
This
approach
meant
that
security
was
a
consideration
early
in
the
process,
not
something
that
would
block
a
release
at
the
last
moment.
This
is
also
the
consideration
under
which
I'm
putting
compliance
and
governance,
while
not
perfectly
aligned.
I
figure
all
the
things
that
you
have
to
call
lawyers
about
should
just
live
together,
I'm
kidding,
but
in
all
seriousness,
these
three
concepts
are
really
about
risk
management,
identity,
data
authorization,
there's
lots
of
different
aspects
of
it,
but
the
question
is
really
who
has
access
to
what
when
and
how?
A
And
that
is
everybody's
responsibility
at
every
stage
site,
reliability,
engineering.
What
we
call
sre
is
a
discipline,
a
job,
an
approach
for
good
reason.
It
is
absolutely
critical
that
applications
and
services
work,
as
expected
for
the
vast
majority
of
the
time
that
said,
availability
is
often
mistakenly
treated
as
a
synonym
for
reliability.
A
A
Reliability
may
be
the
end
result,
but
resiliency
for
me
is
the
journey.
The
action
that
engineers
can
take
to
improve
reliability
observability
is
the
ability
to
have
insight
into
an
application
or
system.
It's.
The
combination
of
telemetry
monitoring,
alerting
all
available
to
engineers
and
leadership,
there's
an
aspect
of
observability
that
overlaps
with
reliability,
which
is
why
they're
neighbors,
but
the
purpose
of
observability
isn't
just
to
maintain
a
reliable
system,
though
that
is,
of
course,
important.
A
It
is
the
capacity
for
engineers
working
on
a
system
to
have
visibility
into
the
inner
workings
of
that
system.
The
concept
of
observability
actually
originates
in
linear
dynamic
systems
and
is
defined
as
how
well
the
internal
states
of
a
system
can
be
understood
based
on
information
about
its
external
outputs.
A
A
The
only
thing
constant
in
our
work
is
change.
In
every
role
we
play
creating
flexible
systems
that
will
grow
as
applications
grow
is
critical.
Finally,
scalability
scalability
refers
to
more
than
a
system's
ability
to
scale
for
additional
load.
It
implies
growth
and
a
system's
ability
to
grow
over
time.
A
A
It
requires
each
of
us
in
our
various
roles,
to
consider
everyone
around
us,
our
customers,
who
use
the
system
and
rely
on
its
services,
our
colleagues
current
and
future,
with
whom
we
collaborate
and
even
our
future
selves.
We
have
to
read
that
code
too.
Software
development
isn't
a
straight
line,
nor
is
it
a
perfect
loop.
It
is
an
ever
changing,
complex
dance.