►
From YouTube: Tutorial: DevOps Tooling for Java Developers in a Cloud Native World - Melissa McKay, Stephen Chin
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Tutorial: DevOps Tooling for Java Developers in a Cloud Native World - Melissa McKay, Stephen Chin, & Baruch Sadogursky, JFrog; & Ixchel Ruiz, Karakun AG
With the rise of DevOps, low-cost Cloud Computing, and emerging Container technologies, the landscape for how you approach development has dramatically changed. This tutorial is focused on helping Java developers to adapt to this new landscape and take advantage of microservices, serverless, and cloud-native technologies with the latest DevOps techniques to simplify their build and create hyperproductive teams. The entire DevOps toolchain will be covered including source control, build declaration, CI/CD, package management, containerization, and security. Learn from the combined experience of the presenters who are experts in the Java and DevOps domains on the best tools, technologies, and methodologies to build your next cloud-native application or refactor your monolith.
https://sched.co/ekFf
A
Okay,
so
welcome
everybody
to
devops
tools
for
job
developers,
we're
very
excited
to
be
able
to
talk,
be
able
to
talk
to
all
the
folks
at
kubecon
about
how
you
can
uplevel
your
development
skills
by
adding
in
a
bunch
of
cloud
native,
kubernetes
and
deployment.
Skill
sets
to
kind
of
extend
what
you're
doing
with
continuously
deploying
to
production
environments.
A
B
C
I'm
melissa
mckay
and
I
come
from
a
developer
background
as
well
about
20
years
now.
Just
recently
I
decided
to
become
a
developer
advocate
for
jfrog
and
I'm
hoping
that
all
of
my
development
experience
I'll
be
able
to
use
that
to
share
with
you
at
talks
virtually
here
and
hopefully
someday
in
the
future
physically,
maybe
we'll
cross
paths
at
a
conference.
D
Yeah,
so
we're
looking
we're
all
looking
forward
to
to
in-person
cube
come
back.
My
name
is
baruch
sadogursky.
I
am
the
chief
sticker
officer
of
jfrog
speaking
about
in
person
conferences.
I
would
love
to
be
there
with
you
and
give
you
some
awesome
stickers
of
jfrog,
also
head
of
developer
advocacy
and
being
developer
myself
for
in
more
than
almost
20
years.
D
C
C
D
D
Oh
then,
you
know
what
let's,
let's
drop
a
bomb
here.
Let's,
let's
ask
the
big
questions:
why
should
developers
care
about
devops
and
as
I
mentioned,
I
I
come
from
developers
perspective
and
I
remember
what
developers
care
about
and
they
care
about
code
right
as
a
developer.
Our
definition
of
done
is,
we
wrote
some
code,
we
tested
it.
Quality
is
very
important
right
and
then
we
kind
of
shown
it
to
all
the
shareholders.
D
We
we
we
showed
what
we
wrote
to
a
product
manager
or
to
a
project
manager,
obviously
to
qa
to
our
team,
lead
who
checked
for
and
they
they
checked
for
for
all
the
stuff
right.
If
the
features
are
there
non-functional
requirements
at
the
court
style
and
the
the
court
review,
the
qa
people
checked
for
quality
and
and
once
all
of
those
stakeholders
approve
and
say
it's
good.
This
is
where
we
are
done.
Our
work
is
done.
It's
friday,
let's
go
drink
now
the
ops
people
they
are
going
to
deploy
it.
D
C
This
is
exactly
the
perspective
I've
had
as
a
developer
for
most
of
my
career.
We
were
pretty
siloed
when
it
came
to
the
actual
deployment
piece.
I
was
never
on
call
for
a
deployment
or
anything
like
that.
It's
very
different
atmosphere.
Today,
my
most
recent
time
in
my
career,
I
was
on
a
devops
team
that
really
opened
my
eyes.
I
did
not
realize
the
pains
that
ops
takes
to
deploy
the
applications,
and
once
I
started
learning
several,
you
know
things
some
of
that
process.
I
realized
there
were
actually
big
decisions.
C
I
would
have
made
differently
about
the
writing
and
the
organization
of
the
app
had
I
known
all
of
this
pain
that
they
were
going
through.
So
I
think
this
is
a
good
move
in
the
industry
having
these
silos,
where
you
just
you
know,
throw
code
over
the
wall
and
then
just
let
ops
handle
it.
I
think
it's
just
not
the
best
way
to
do
things
anymore.
A
Let
me
let
me
pitch
in
from
a
developer
perspective,
so
I
I
think,
if
you,
if
you
look
at
this
from
from
a
very
selfish
perspective,
what
we
all
care
about
is
is
how
much
we
get
paid
as
developers
right
and
if
you
look
at
the
stack
overflow
survey,
which
was
recently
done,
you
know
full
stack
engineers
and
back-end
engineers
and
everyone
gets
paid.
You.
C
A
Quite
well,
so
I
think,
even
amid
the
current
pandemic,
we're
very
lucky
to
have
technology
jobs,
devops,
engineers
and
site
reliability.
Engineers
are
actually
even
higher
paid
than
development
positions,
and
I
think
this
this
reflects
the
the
number
of
languages
and
technologies,
the
adding
in
additional
cloud
native,
deploying
to
cloud
environments
or
hybrid
environments
and
learning
all
these
skills
and
getting
really
good
at
it
actually
is
a
way
of
improving
your
career
and
and
getting
paid
more,
which
you
know,
that's
not
too
bad.
B
Well,
I
agree
with
all
of
you
actually
first
and
the
most
interesting
reason
for
me
is,
as
steve
mentioned,
this
set
of
practices
that
were
devops
and
agile
are
here
to
stay
so
outside
there
if
you're,
looking
for
a
new
job,
a
better
pay
job,
these
are
the
skills
that
you
have
or
the
concept
that
you
have
to
know
and
use.
The
second
reason
is
because
there
are
good
practices
in
there.
B
There
are
good
practices
that
will
make
your
life
easier
and
when
this
whole
concept
of
devops
started
probably
the
best
book
that
describes
the
ideas
behind
it
is
the
phoenix
project.
If
you
have
started
with
this
topic
in
a
more
serious
way,
you
probably
have
been
recommended
this
book.
I
do
recommend
this
book.
First
of
all,
it's
a
novel,
so
it's
entertaining
second
of
all,
it's
going
to
give
you
a
perspective
from
management.
B
So
and
steve
mentioned
another
important
thing
right
now,
with
this,
the
with
kobe,
the
pandemia,
it
is
important
that
we
react
fast.
We
adapt
fast,
we
deliver
fast,
so
this
idea
of
going
really
really
fast
and
also
providing
quality,
making
the
the
user
happy
or
providing
new
functionality.
It's
really
important.
B
So
this
is
a
really
good
book,
because
for
us
developers
it
provides
us
with
a
glimpse
of
what
were
the
management
concerns
and
when
you
start
learning
the
language
of
management,
you
can
also
talk
back
and
probably
you
as
a
developer,
I'm
going
to
have
my
list
of
metrics
c.
We
reduce
our
whatever
for
20,
and
then
I
go
with
management
or
stakeholders
and
they
are
like.
B
But
what
does
that
mean?
Well
now
you
have
the
language
of
management,
you
know
the
concerns
and
you
can
translate
whatever
you
are
improving
into
their
language.
There's
another
book
and
it's
the
companion
I'd
like
to
call
it.
The
companion
of
the
phoenix
project
is
the
unicorn
project.
This
is
the
same
story
again
a
novel,
but
the
main
character
is
a
female
developer
and
it's
going
to
describe
the
working
environment
and
also
the
things
that
can
go
wrong
in
a
software
development
team.
B
So
it's
also
interesting
because
it
provides
you
a
nice
depiction
or
sometimes
a
not
so
nice
depiction,
but
you
also
see
that
the
principles
or
the
concepts
or
the
practices
that
devops
is
proposing
will
help
you
in
your
day-to-day
life.
So
you're
going
to
be
a
less
annoyed
and
hopefully
a
happy
developer.
D
And
that's
that's
a
great
review
of
those
two
books
and
I
would
like
to
suggest
if
you
wish
an
alternative
relationship
between
them
and
it's
interesting
both
in
terms
of
timing,
the
unicorn
project
released
10
years
after
the
phoenix
project
and
it's
interesting
to
see
how
the
views
on
devops
progressed
during
this
time.
If
we
look
at
the
phoenix
project,
we
see
how
the
story
of
devops
is
actually
a
story
of
ops,
people
of
I.t
people
winning
with
devops.
You
can
see
how
the
main
protagonist
of
the
story
bill
palmer.
D
He
is
a
vp
of
I.t
ops
and
that's
like
a
completely
ops
concept
and
his
devops
kind
of
invention
is
the
solution
to
the
exact
problem.
We
spoke
earlier
of
how
the
developers
are
done
and
they
are
out
of
the
building
and
now
go
ahead
and
deal
with
it
and
good
luck,
and
this
is
kind
of
view
of
how
devops
came
to
be
solving
the
problem
of
it.
Ops,
people.
Now,
10
years
later,
we
see
a
completely
different
picture,
the
unicorn
project
as
being
an
alternative
timeline.
D
If
you
wish
the
same
company,
the
same
problem
now
solved
from
a
completely
different
perspective:
maxine
the
lead
developer,
as
as
you
mentioned,
israel
is,
is
she
solves
her
problems
of
a
very
bureaucratic,
rigid
and
and
slow
organization
for
her
needs?
Her
developer
needs
again
by
adopting
devops,
so
it's
it's.
D
The
same
win
is
the
same
companies
the
same
problems,
it's
the
same
solution
in
the
end
of
the
day,
but
it
came
to
be
from
a
developer
perspective,
and
I
think
this
is
the
ultimate
answer
to
the
question
that
I
asked
in
the
previous
slide
why
the
developers
care
about
devops?
Yes,
they
didn't
have
to
care.
In
the
beginning,
it
was
ops,
people
solving
their
own
problems,
but
this
is
not
true
anymore.
Nowadays,
the
problems
of
developers,
the
autonomy,
the
mastery,
the
purpose
of
developers
are
also
can
be
solved
and
can
be
elevated
through
devops.
B
Yes,
we
have
to
keep
in
mind
what
is
the
big
picture
in
the
software
development
cycle
and,
of
course
we
are
one
part
we
are.
I
will
argue
the
most
important
part,
but
that's
me
but
we're
a
part
of
of
this
whole
process,
and
even
if
we
speak
different
languages,
we
express
our
concerns
in
different
ways.
B
We
still
have
like
main
things
we
have
to
follow,
and
this
is
something
that
devops
practices
and
actual
practices
are
very
focused
on,
for
example,
speed,
quality
security
having
enough
information
feedback,
early
feedback,
early
failure,
whatever
you
need
to
go
at
the
speed
that
you
need
to
go.
If
it's
fast
super
fast
it
it
all,
it
all
depends
and
also
what
do
you
use?
What
metrics?
What
are
the
benchmarks?
What
are
your
requirements?
What
are
your
service
level
requirements?
B
D
Absolutely
and
now,
let's
talk
about
the
development
cycle
and
the
development
cycle
changed
in
the
last
years.
You
remember
how
it
always
being
a
three-step
diagram,
because
everything
in
it
is
three-step
diagram,
but
those
three
tabs
were
different.
The
three
steps
that
we
kind
of
were
were
used
to
is
a
write
code,
build
code
and
then
deploy
code.
That
was
the
three
steps,
and
today
we
still
have
three
steps,
but
they
are
different
steps,
and
this
is
what
you
see
in
the
screen.
D
The
sourcing
part
of
finding
the
the
building
blocks
that
you
are
going
to
integrate
in
your
application
is
not
a
new
concept,
but
it
matured
to
be
a
very
important
part
of
our
development
life
cycle,
and
why
is
that?
Because,
nowadays,
80
to
90
percent
of
our
application
is
a
taking
someone
else's
code.
Is
that
the
open
source
frameworks,
the
open
source
libraries
that
we
use
and
most
of
our
code
is
just
glue
around
it?
D
It's
just
in
the
integration
code
between
those
different
libraries,
so
the
process
of
sourcing
and
by
sourcing
I
mean
finding
validating,
bringing
physically
the
code
to
where
we
can
use
it
and
then
caching
it
so
it
will
stay
forever
and
won't
disappear
under
our
figures.
This
is
something
that
is
critical,
because
80
to
90
of
our
application
will
be
this
code.
So
sourcing
is
a
very
big
deal.
How
do
we
find
the
libraries
that
we
want
to
use?
D
How
do
we
know
that
those
libraries
are
good
good
in
terms
of
they
do
what
we
need
good
in
terms
of
their
easy
to
use
user
experience
good
in
terms
of
they
don't
have
bugs
they
don't
have
security,
venerabilities
and
good
in
terms.
We
can
actually
go
ahead
and
use
it.
How
can
we
validate
all
those
things?
So
how
do
we
know
if
the
user
experience
is
good?
We
need
to
ask
our
peers-
and
here
is
where
the
problem
of
you
know.
We
never
considered
it.
This
way
come
and
kind
of
bites
us.
D
If
you
look
at
maven
central
as
being
the
primary
source
for
your
dependencies
in
the
java
world,
you
have
no
metadata
that
can
help
you
make
this
decision.
It's
a
file
server
that
you
can
grab
the
artifacts
and
use
them.
You
don't
know
anything
about
them.
You
might
write
some.
You
might
read
some
blogs,
you
might
see
some
conference
talks
and
then
you
might
decide.
Well,
I
heard
that
I
don't
know.
D
J
unit
is
is
good,
let's
use
junit
and
then
you
go
to
maven
central
and
fight
genuine,
but
the
aspect
of
ratings
of
popularity
of
user
experience
is
just
not
there.
We
need
to
do
our
own
research,
and
this
research
can
be
long,
can
be
a
time
consuming
and
even
can
be
wrong
right,
not
everything
that
has
hype
around.
It
is
necessarily
good
for
you.
So
what
I'm
saying
is
you
need
to
invest
your
time?
You
need
to
do
your
research.
D
You
need
to
be
able
to
smartly
pick
what
your
application
is
going
to
build
on,
and
this
is
where
we
talk
about,
what's
good
for
you
in
terms
of
usability
and
maybe
even
quality,
etc.
Now
the
second
problem
is:
how
do
you
validate
that?
They
don't
have
security
abilities,
and
this
is
where
tools
like
jeffree,
x-ray
and
aqua
and
sneak
and
white
source
and
black
duck,
and
there
are
tons
of
other
tools
that
can
help
you
validate
those
dependencies.
D
D
D
Is
this
library
even
allowed
to
be
used
in
your
organization?
Maybe
it
has
a
viral
open
source
license,
and
it
means
that
if
you
are
going
to
use
it,
then
legally
you
have
to
open
source
all
your
development.
Sometimes
it's
acceptable,
but
most
of
the
time,
it's
not
because
you
probably
work
chances.
Are
you
work
in
for-profit
organization
that
wants
to
make
money
from
the
software
and
it
means
that
it
has
to
be
not
free
and
not
open
source
right?
That's
like
the
default
use
case.
If
you
wish.
D
So
all
those
questions
they're
there
in
the
sourcing
and
doing
your
research
for
what
you
cannot
automate
and
automating
what
you
can
is
critical
now
the
second
step
is
the
most.
If
you
wish
to
reveal
one.
This
is
what
we
do
for
years.
We
write
code,
we
build
we
test,
we
validate
our
code.
This
is
all
we
know
how
to
do.
We
use
our
build
tools:
maven
gradle
bazel,
whatever
you
use,
and
then
you
just
compile
the
chord
you
get
gyros,
you
start
promoting
them
through
quality
gates
in
our
pipelines.
D
We're
going
to
talk
about
that
in
a
second
and
and
then
you're
done
right.
You
have
your
artifacts
ready
to
be
distributed
or
ready
to
get
to
your
users
and
then,
when
the
third
kind
of
the
third
part
of
your
three
steps,
diagram,
kicking
and
that's
the
distribute,
what
does
it
mean
well
distributing
is
bringing
it
to
the
runtime.
What
is
the
runtime?
Everything
right
so
back
in
the
day
of
like
pure
java
development
in
distribution.
D
It
was
you,
build
a
war
file
and
you
put
it
in
your
tomcat
or
your
other
ceremony
container
or
you
build
your
application
archive,
and
then
you
put
it
in
what
was
it
a
web
websphere
got
for
bid
or
or
web
logic
or
or
or
whatever
it
is
right
and
but
those
those
days.
Well.
Those
scenarios
are
still
out
there,
but
there
are
other
scenarios
that
there's
r.
That
are
reason.
D
Obviously,
here
at
kubecon
we
are
going
to
talk
about
and
we
are
going
to
show
you
how
you
distribute
to
your
kubernetes
cluster,
and
this
is
kind
of
the
cloud
native
use
case,
but
there
are
others
as
well
how
about
edge
computing,
how
about
iot?
How
about
for
computing
or
even
other
people's
computers?
You
have
now
a
distributable
application,
a
minecraft
that
people
download
and
play
this
distribution
scenario
is
also
as
as
distribution
scenarios
as
as
others.
D
B
Yes,
I
I
just
wanted
to
mention
baroque.
You
are
totally
a
writer,
that's
one
of
the
things
that
are
very
effective
of
devops
and
the
practices
and
agile
that
now
our
code
bases
have
exploded.
Our
deliveries
are
also
exploded
because
we
have
a
more
fragmented
market.
It's
very
typical
for
me
to
go
to
a
client
and
suddenly
they
ask
you
to
deliver
in
different
flavors
the
software
that
you
are
preparing
and
with
different
requirements.
B
A
Okay
and
I'm
going
to
I'm
going
to
dig
in
a
little
bit
more
on
one
of
these
practices,
which
is
how
you
manage
your
code
that
you're
doing
for
developing,
and
I
kind
of
looking
at
the
the
history
of
software
development.
There
have
been
a
bunch
of
different
approaches
to
this
problem
and
just
just
a
quick
call
from
you
know,
of
course,
our
audience
we'd
love
to
hear
from
you,
as
well
as
the
the
other
speakers
here.
So
what
what
was
your
first
version
control
system.
D
A
Okay,
so
so,
mercurial
and
and
git,
which
I
think
what
a
lot
of
people
are
using
today
are
actually
considered
the
most
modern
version
control
systems.
But
if
you
go
back
in
history,
what
we
started
with
were
systems
like
sccs
rcs,
clear
case
falls
in
this
category.
Two
commercial
systems
tend
to
lag
behind
open
source
solutions,
and
they
were,
they
were
locking
version
control
systems
where
you
you'd
actually
lock
the
files.
You'd
say
this,
I'm
working
on
this
file.
Nobody
else
can
touch
it.
A
A
Now
now
cvs
and
subversion,
of
course,
this
doesn't
work
for
large
teams.
If
you
had
a
refactoring
and
you
changed
something
across
the
entire
code
base
like
a
package
or
something
that
is
in
every
file,
you
would
you
would
lock
the
entire
code
base
and
nobody
else
will
get
any
work
done.
So
cvs
and
subversion
fix
this
with
optimistic
locking,
which
essentially
means
that
you
let
everybody
change
the
files
whenever
you
want
to,
and
if
it
turns
out
that
two
people
change
the
same
file,
you
go
back
and
you
resolve
a
merge
conflict.
A
You
you,
you
try
to
merge
and,
and
hopefully
you
can
automatically
resolve
the
changes.
Sometimes
you
can't
automatically
resolve
changes
and
you
have
to
to
manually
resolve
a
merge
conflict,
and
this
takes
us
to
the
the
third
generation
of
version
control
systems,
so
cvs
and
subversion.
You
were
always
thinking
with
a
server
and
getting
mercurial
introduced
a
distributed
concept
where
now
you're
syncing,
with
the
local
repository
you
have
your
own
version
of
the
entire
repository
locally,
actually
so
kind
of
kind
of.
Ironically.
A
This
is
this.
This
takes
us
back
to
the
early
version
control
system,
so
so
rcs
and
cvs
were
actually
initially
designed
just
to
be
used
on
mainframes,
and
so
they
also
technically
considered
the
repository
to
be
local,
but
what
they
were
missing
and
and
what
of
course,
server-faced
version
control
systems
are
missing.
Is
they
they're
missing
the
capability
to
sync,
your
repository
with
other
repositories
so
distributed
version
control
systems?
A
It's
very
fast.
It's
very
efficient.
It
does
a
great
job
of
merging
and
resolving
conflicts,
and
it's
basically
pushed
other
systems,
like
you
know,
cvs,
mercurial
and
even
subversion
to
to
be
of
very
low
usage.
Now
in
in
the
industry.
Some
folks
are
still
using
subversion
for
commercial
purposes,
but
I
think
most
of
us
have
moved
on
and
moved
to
to
get
and
accepted
that
distributed
version.
A
Control
systems
are
the
the
path
forward
and
when
you,
when
you
look
at
how
distributed
version
control
systems
work,
you
have
your
own
working
copy
of
the
code
which
you're
committing
and
updating
to
a
local
repository.
So
all
that
exists
on
your
your
machine
and
then,
when
you're
ready
to
to
push
your
code,
then
you
push
this
to
the
remote
repository,
so
you'll,
actually,
sync
your
code
with
essential
repository
and
other
people
will
pull
and
push
from
that
central
repository
and
a
lot
of
modern
workflows
like
github,
further
introduce
the
concept
of
pull
requests.
A
Where
you
ask
people
to
accept
your
change
and
then
they'll
pull
from
your
repository
to
integrate
the
changes
which
you've
made,
which
actually
makes
it
safer
for
for
merging
and
code
control,
because
you
don't
have
random
people
pushing
changes
which
break
the
build,
and
then
we
we
all
get
well.
This
is
favorite
analogy,
a
a
a
donut
day
when
the
build
breaks
or
there's
various
other
ways
of
shaming
people
as
well,
but
I
think
I
think,
rewards
are
better
than
shaming.
So
donuts
are
a
nice
reward,
so
distributed
version.
A
Control
systems
make
this
much
easier,
workflow
wise
to
avoid
having
your
entire
build
impacted
by
this,
and
I
I
think
the
de
facto
standard
for
distributed
version
control
systems
has
become
systems
like
like
git
and
specifically
cloud
systems
like
github.
So
in
the
stack
overflow
survey,
github
was
the
highest
used
tool
by
developers
across
the
board.
A
He
flipped
the
next
slide,
melissa,
the
of
course.
You
know
we
are
using
slack
and
jiren
other
tools,
but
github
is
used
by
over
80
of
the
developers
and
then
there's
a
bunch
of
other
tools
going
down
the
list
which
other
folks
use.
But
I
think
that
when
you're
looking
at
how
you
can
manage
your
source
control
work
with
large
teams
and
efficiently
create
the
source
code
pipeline
to
deploy
to
production
it,
it
makes
sense
to
start
with
a
solid
foundation
with
a
distributed
version.
D
D
D
You
will
deploy
your
integration
level
artifact
to
your
integration
cluster
and
you
will
pack
them
obviously
in
docker
container,
also
in
ci
server-
and
this
is
you
you
will
you
will
deploy
the
container
to
your
integration,
kubernetes
environment?
This
is
where
you
do
your
integration
testing
and
if
the
quality
requirements
are
hit,
if
you
are
satisfied
with
the
quality
of
your
artifacts,
you
promote
them
through
quality
gates
to
another
level
to
another
staging
area,
and
what
does
it
mean
promote
through
quality
gates?
D
In
this
more
simplistic
way,
you
will
just
move
them
from
one
repository
in
your
artifact
repository
manager
to
the
next
repository.
You'll
have
repository
for
integration,
for
system
testing,
for
staging
for
production,
and
your
movement
through
quality
gates
will
be
promotion
of
those
artifacts
from
one
repository
to
another.
In
next
repository
now
we
promote
it
from
integration
repository
to
system
testing.
We
again
deploy
those
artifacts
to
a
system
testing
cluster
kubernetes
cluster.
In
our
example
in
system
testing,
kubernetes
cluster,
we
start
doing
our
tests
again
other
tests.
D
Now
it
will
be
system
testing,
but
also
can
be
security
performance,
any
anything
that
you
care
about
in
terms
of
what
you
can
automatically
test
and
again,
if
the,
if
the
tests
are
failing.
Well,
you
just
discard
those
artifacts,
but
if
the
tests
are
successful
and
the
quality
requirements
are
met,
you
are
going
to
promote
it
further
to
staging
and
in
the
end
of
the
day,
to
production,
so
our
pipeline
is
you
build
the
artifacts.
C
So,
just
to
reiterate
some
of
the
points
that
baruch
has
made
about
sources,
I
want
to
drill
down
into
what
actually
happens
at
the
very
beginning,
which
is
the
building
of
everything
they're.
Not.
There
may
not
be
many
times
in
your
career
that
you're
involved
in
a
greenfield
project
where
you
can
start
from
scratch,
and
you
know
where
everything
is
coming
from,
and
you
know
how
everything
is
built
and
how
everything
is
put
together.
C
C
I
may
be
responsible
for
fixing
bugs
that
kind
of
stuff,
given
that
it's
so
super
important
when
you're
in
that
situation,
you've
just
joined
a
team
part
of
your
ramping
up
process
know
your
build
get
to
know
your
build,
get
to
know
the
ins
and
outs
of
it
you'll
be
able
to
work
better
and
more
efficiently.
If
you
know
where
everything
is
coming
from
and
how
everything
fits
together.
C
One
specific
story
I
have
for
that
early
on
in
my
career,
I
joined
a
software
team
and
it
happened
to
be
a
project
that
was
pretty
large.
There
were
multiple
java
modules
all
over
the
place
at
the
time
I
was
using
eclipse
and
in
my
in
my
ide,
and
I
had
everything
you
know
pulled
in,
and
I
was
really
excited
to
work
on
this.
I
I
was
pointed
to
a
particular
module,
a
particular
bug
that
I
I
needed
to
fix.
C
So
I
got
the
code
up
and
every
time
I
made
a
change,
I
would
turn
around
and
run
maven
clean
well
after
a
while
of
doing
that
very
inefficient
way
to
work,
because
I
didn't
understand
what
was
going
on
behind
the
scenes.
At
some
point,
one
of
my
colleagues
came
over
and
was
kind
of
watching
over
my
shoulder
to
answer
some
questions
and
noticed
that
this
is
what
I
was
doing
and
figured
out
immediately.
C
It
was
because
I
I
had
not
taken
that
first
step
to
really
understand
how
this
project
was
put
together.
I
didn't
understand
how
my
sources
were
coming
in
how
they
were
being
cashed.
How
every
time
I
did
a
maven
clean,
I
was
actually
blowing
away
my
cash
and
just
spending
a
lot
of
time
repeating
work
that
didn't
need
to
be
done
come
to
find
out.
C
So
this
is
something
important
to
know
and
understand,
even
if
you're,
an
ops
person
that
you
they
need
to
know
this
too,
because
building
your
pipelines
out,
you
need
to
understand
how
long
your
builds
are
going
to
take
if
you
repeat,
building
pieces
every
time
over
and
over
through
your
software
cycle
through
the
pipeline,
it's
going
to
take
forever.
So
there's
a
lot
of
efficiency
improvements
that
can
be
made
there.
C
The
other
part
of
this
is
where
are
your
sources
coming
from
so
now
that
we're
in
this
new
world,
where
containers
are
really
popular?
This
is
the
thing
to
do
you,
you
build
a
docker
file.
You
put
in
you
pull
in
a
base
image.
You
write
some
stuff,
you,
you
know
put
everything
together
and
now
you
have
this
image
that
you
can
send
out
there
and
provide
as
a
service
for
everyone.
Well,
there
are
some
specific
things
to
look
for
these
base.
C
Images
are
actually
coming
likely
from
default,
docker
hub,
unless
you
are
specifying
a
particular
registry
that
you
have,
which
I
would
recommend
getting
a
private
registry,
because
you
don't
know
how.
Often
these
images
are
going
to
go
away.
Your
base
images
may
disappear.
I
was
on
a
project
once
where
we
were.
We
were
all
relatively
new
to
docker.
It
was
pretty
new
for
us,
so
just
getting
you
know,
getting
it
built
and
up
and
running
was
was
awesome.
C
We
started
at
the
very
beginning,
definitely
the
the
documentation
on
docker
so
having
something
to
start
with
was
great.
However,
as
time
went
on,
I
came
to
realize
when
our
build
started,
breaking
that
our
base
image
was
coming
from
a
repository
that
was
managed
by
a
contractor
who
was
no
longer
employed
by
the
company.
C
Well,
eventually,
that
quit
working
eventually
that
base
image
disappeared,
they
were
no
longer
responsible,
for
it
probably
had
assumed
that
we
had
already
moved
it
into
a
safe
place
that
we
managed.
Obviously
that
didn't
happen.
So
there
was
some
communication
that
had
to
be
done
to
retrieve
that
base
image
so
that
our
builds
would
stop
breaking
that's
one
thing
to
look
at
another.
Is
you
don't
know
necessarily
anymore
where
the?
If
you
haven't
paid
attention
to
what's
going
on
inside
your
doctor
file,
you
could
be
pulling
in
external
resources
that
you
didn't
realize.
C
One
example
of
this
was
I
found
a
place
where
we
were
actually
pulling
in
an
external
script
and
then
that
script
was
being
launched
during
the
build
not
recommended
to
do
that
at
the
very
least,
we
needed
to
retrieve
that
script
from
wherever
it
was
from
and
also
store
that
in
a
local
repository,
so
that
we
had
access
to
it
always
and
it
wasn't
constantly
being
pulled.
You
know
over
the
over
the
internet
to
pull
that
thing
down.
C
The
other
was
knowing
what
that
script
was
actually
doing,
and
there
may
be
security
vulnerabilities
being
added
that
we
weren't
aware
of
there
could
be
licensing
issues
if
there
happens
to
be
third-party
applications
or
installations
happening
during
your
builds
that
involve
installing
products
that
do
not
have
a
license.
That
is
good
for
your
company.
C
So,
yes,
so
make
sure
you
understand
your
build.
That
is
the
whole
point
of
this
slide.
Here
also
note:
the
bananas.
I
refuse
to
use
shipping
containers
to
represent
containers
anymore
in
any
talks
or
any
slides,
and
I
challenge
anyone
in
the
future
to
start
moving
away
from
shipping
containers.
So.
D
B
I
I
like
to
work
a
lot
with
containers,
because
when
we
first
started
in
our
projects,
I
think
the
first
time
we
use
it.
It
was
for
developing
purposes.
For
example,
we
in
the
product
that
I
was
working
on,
we
need
to
support
several
databases
and
instead
of
installing,
in
my
local
machine,
postgres
and
mysql,
and
then
later
on,
polluting
my
my
system
folder.
Now
we
had
the
opportunity
to
create
the
image
or
download
the
image
in
if
we
needed
to
create
the
specific
postgres
version
with
our
own
configuration
file
even
better.
B
So
that's
why
I
support
totally
melissa's
idea
of
having
your
own
at
the
at
the
company
level,
your
own
repository,
because
you
can
do
the
things
like
this
later
on
when
you're
using
them
for
integration
tests.
You
may
want
to
customize
it
because
integration
tests
usually
takes
a
long
time
so
they're
they're
expensive
in
bootstrapping,
the
depending
on
how
many
services
you
have
to
to
test.
Remember
integration
test
is
testing
two
components.
You
don't
have
to
test
your
entire
application.
You
can
of
course,
do
it
do
end-to-end
tests,
but
integration
tests.
B
B
D
Yeah,
but
I
think
that
the
promise
of
java
right
once
right,
right
once
run
anywhere,
actually
didn't,
didn't
fulfill
and
it
didn't
fulfill
because
dependencies,
because
our
application
cannot
really
be
isolated
from
everything
around
it,
and
this
is
why,
even
in
java
works
on
my
machine,
a
joke
is
is
actually
a
reality
right.
I
even
with
java.
D
It
might
very
well
be
that
something
that
runs
on
my
machine
actually
breaks
in
in
any
other
environment,
obviously
including
production
and-
and
I
think
containers
are
really
the
next
step
of
minimizing
the
impact
of
external
of
external
dependencies.
It's
almost
like
someone
said
works
on
my
machine,
and
then
we
said
you
know
what
fine.
We
will
just
ship
your
machine
to
production
and
that's
exactly
what
and
that's
exactly
what.
D
B
The
other
thing
that
attracted
me,
it
was
a
change
of
how
we
thought
marti
powder
and
has
this
snowflake
server
versus
phoenix
server
and
it's
the
same
metaphor
as
the
cattle
versus
patch,
because
in
the
past
we
had
the
servers
that
nobody
knew
how
they
came
to
be.
Nobody
knew
how
they
were
working.
Nobody
wanted
to
touch
them
because
you
cannot
reproduce
it
so
they
were
like,
like
so
dear,
even
if
they
were
not
working
correctly,
nobody
attempted
to
change
it.
So
now
we
have
to
think
in
a
different
way.
B
C
Up
all
right,
so
in
this
new
world
of
containers
and
everything
in
the
context
of
delivering
your
application,
choosing
your
tools
can
be
pretty
overwhelming
and
there's
a
lot
of
stuff
out
there
that
you
have
to
learn
now
as
a
developer
in
order
to
make
this
process
efficient
and
get
your
stuff
out
into
production.
So
something
that
I
really
recommend
is
make
sure
that
you
understand
as
a
developer
and
as
your
team,
that
you
understand
what
you
need
and
what
your
goals
actually
are,
not
just
service
oriented
but
business
goals
as
well.
C
This
means
involving
representatives
from
other
parts
of
your
company
to
come
in
and
and
help
to
determine
what
is
most
important
for
you.
The
first
thing
you
need
is
the
list.
The
list
of
priorities,
your
you
know,
is
it
fast?
Is
it
efficient?
Is
it
reliable?
Should
it
be?
You
know
more
economical.
These
are
all
just
examples
of
of
goals
that
you
have
but
make
sure
that
you
prioritize
these
so
that
across
the
company
you're
all
on
the
same
page,
working
toward
the
same
thing,
the
same
goal.
C
You
won't
have
pockets
of
the
company
wondering
why
on
earth
are
developers
doing
this,
when
they
should
be
doing
that.
These
are
important
things
to
make
sure
that
you
know
up
front.
This
picture
is
of
my
car.
This
is
my
actual
car
sitting
in
my
garage
right
now.
This
is
really
is
a
good
example
of
what
I'm
talking
about,
especially
for
legacy
systems.
This
is
a
legacy
car,
it's
about
18
years
old
and
I
live
in
colorado.
The
tires
on
this
car
right
now
are
likely
more
expensive
than
I
could
get
selling
this
car.
C
So
when
I
got
into
a
little
accident
goodness
more
than
a
year
ago
now
I
got
a
little
dent
on
the
side
of
the
car
and
it
was
definitely
not
worth
it
to
me
to
take
it
to
a
body
shop
and
get
that
fixed.
Instead,
I
went
to
amazon,
got
a
band-aid
magnet
and
put
it
over
the
dent
in
my
car.
So
sometimes
this
might
be
the
right
thing
to
do
for
some
of
your
legacy
applications
just
because
that
particular
thing
is
not
a
priority
for
your
business
at
the
moment.
C
It
would
be
it's
really
valuable
to
also
come
together
as
a
team,
not
just
developers
but
with
representatives
from
other
departments
as
well,
come
as
a
team
and
decide
you
know
which
part
which
steps
are
we
taking?
That's
your
your
first
thing,
whiteboard
what
you're
actually
doing
to
get
your
software
into
production
and
it
doesn't
have
to
be
perfect
and
it
likely
won't
be,
but
you
need
to
have
that
documentation
of
the
actual
steps
that
are
taking
place.
You
don't
want
to
get
in
a
situation
where
only
one
person
knows
step
three
of
the
process.
C
They're
sick
on
the
day
of
you
know
deploying
a
fix
to
production.
Nobody
knows
what
to
do.
You
want
to
make
sure
to
have
that
documentation
and
I
don't
care
if
it's
a
manual
step
write
it
down
once
you
have
this
documentation
in
front
of
you,
then
you
can
start
going
through
each
one
and
find
out
which
which
steps
are
the
most
costly
for
you
right
now,
as
a
team
which
steps
seem
to
be
causing
the
most
problems
for
you,
which
steps?
Can
you
improve
one?
C
One
idea
is:
this
was
also
something
introduced
to
me
recently.
It
was
the
whole
idea
of
one
percent
improvement.
Pick
one
thing
pick
one
thing
in
your
development
cycle
and
improve
that
one
thing
this
this
is
a
good
transition.
This
was
really
brings
back
some
memories.
For
me,
how
do
you
deploy
for
me
my
first
devops
team
and
my
first
experience
realizing
what
ops
goes
through
and
actually
deploying
an
application?
C
C
C
C
There
were
a
lot
of
little
shell
scripts
running
around
on
people's
machines
in
various
places,
various
folders
on
a
shared
drive,
and
these
little
scripts
were
what
were
used
and
they
were
patched
together
to
actually
deploy
this
service
to
various
locations,
whether
it
be
a
staging
environment
or
a
production
environment,
and
every
time
a
deploy
was
done
on
this
particular
service.
Now
this
was
back.
You
know
you
always
hear
deploy
fast
deploy.
Often
this
was
not
a
service
that
followed
those
rules.
A
deployment
was
a
big
deal.
C
We
did
not
deploy
very
often,
and
it's
a
good
thing,
because
every
one
of
those
little
scripts
you
had
to
find
them
and
fix
the
little
hard-coded
details
that
may
have
changed
between
each
deployment.
Oh
and
you
got
to
make
sure
that
you
make
the
script,
you
know
that
it
is
working
for
staging
and
for
production.
Make
sure
that
you
know
all
the
urls
are
correct
and
blah
blah
blah.
We
had
a
situation
where
accidentally
a
url
for
a
test,
am
q
server
was
put
into
a
production
environment.
C
So
if
you
can
imagine
this
was
something
that
we
experimented
with.
We
didn't
know
it
at
the
time,
but
we
were
creating
our
infrastructure
as
code,
we
started
putting
our
deployment
scripts
all
of
those
little
scripts.
We
got
them
together,
we
put
them
into
source
control
and
we
started
versioning
them
for
each
and
every
deployment.
C
So
I
I
don't
advise
going
in
and
you
know
making
hard-coded
changes
every
time.
However,
that's
what
we
started
with-
and
it
was
a
lot
better
for
us
to
be
able
to
do
that
quickly,
get
all
of
that
stuff
in
source
control
version
it
and
then
be
able
to
apply
variables
based
on
whether
it
was
a
a
production
environment
or
a
staging
environment.
That
kind
of
thing,
and
then
we
were
able
we
were
able
to
deploy
much
faster
and
we
avoided
those
silly
mistakes
of
putting
in
the
wrong
url
in
the
wrong
place.
C
The
other
advantage
of
doing
that
is
that
now
you
have
the
option
and
capability
of
of
going
back
to
a
previous
version
if
you
need
to,
for
whatever
reason
it's
going
to
happen,
nothing
is
ever
perfect
in
life.
At
some
point.
You're
going
to
need
to
roll
back
a
release
as
we
get
better
and
better
at
this.
Rollbacks
may
not
be
as
common
as
roll
forwards,
but
for
a
while,
I
think
you
know
you
still
need
to
have
that
safety
measure
in
place
until
you
get
a
lot
of
these
practices.
B
I
totally
agree
with
you
melissa.
You
have
to
externalize
as
much
as
the
knowledge
as
possible,
reduce
the
magic
happening
because
life
happens,
and
sometimes
the
person
that
knows
the
magic
it's
on
vacations
and
then
it
scales
that
you
have
a
bottleneck,
a
dependency
that
it's
not
right
or
not
needed.
B
C
C
C
There
also
needs
to
be
available
for
the
benefit
of
everyone
involved.
You
need
a
staging
environment.
You
must
have
a
staging
environment
generally.
This
is
an
environment
that
matches
production
in
every
way
possible,
but
it
it's
the
first
environment
that
you
would
deploy
a
new
version
to
when
you're
in
ready
in
your
cycle
to
deploy
a
new
version
very
important
to
have.
I,
if
you
want
to
test
on
production,
good
luck
to
you,
you
you're
likely
going
to
have
some
pretty
miserable
user
experience.
C
C
I
was
in
a
situation
where,
in
order
to
an
expensive
in
time,
specifically,
is
what
I
was
thinking,
something
that
we
would
do.
We
would
add
to
our
unit
tests.
You
know
the
like
interaction
with
the
database,
for
example.
We
would
just
use
an
in-memory
database,
you
know
because
it
was
faster,
but
the
problem
is,
is
the
in-memory
database
is
not
the
same?
It
did
not
have
the
exact
same
syntax
as
what
was
used
in
production.
C
So
it's
pretty
ridiculous
to
have
all
of
these
tests
and
they
all
pass
and
they
all
run
and
then
put
your
service
into
production
and
everything
breaks
because
of
a
silly.
You
know,
sql
mismatch
or
syntax
difference,
so
use
test.
Containers
containers
are
everywhere.
Containers
are
good
for
you,
you
can
use
them
for
your
integration.
Testing
and
test
containers
has
a
lot
of
available
options
for
you.
C
You
can,
you
know,
grab
your
version
of
database
that
you're
using
and
be
able
to
deploy
that
in
an
integration
environment
and
be
able
to
use
that
you
will
catch
things
like
any
api
problems.
You'll
catch
any.
You
know,
syntax
problems.
Any
differences,
make
sure
that
your
integration
environment
actually
matches
your
production
environment
and
just
avoid
that
mess.
B
Full
disclosure-
I
really
like
integration
tests.
One
thing
that
martin
fowler
said
once
is
that
integration
test
is
you
don't
have
to
test
the
whole
system?
Sometimes
an
integration
test
is
testing
the
the
communication
or
the
coupling
of
two
modules.
So
you
can
break
down
your
integration
test
as
you
seem
fit,
and
if
you
increase
the
richness
of
this,
and
this
different
configurations
of
your
test
is
going
to
be
even
better
for
you.
B
When
you
start
doing
integration
tests,
you
have
to
bootstrap
all
these
resources
and
run
them
turns
out
that,
at
the
time
where
I
started
doing
that,
I'm
a
gradle
most
of
the
time
girl.
Maybe
I
also
work
with
with
maven,
but
at
that
time
we
have
different
plugins
for
gradle
and
they
were
fantastic.
They
allow
you
to
bootstrap
and
automatize
everything,
but
the
functionality
that
they
provide
were
very
limited.
For
example,
you
cannot
have
randomized
boards
yay
so
not
running
the
test
integration
test,
concurrently,
which
is
a
bad
thing.
B
So
at
that
time
it
was.
There
were
so
many
limitations.
When
I
discovered
test
containers-
and
I
saw
what
they
allowed
you-
and
how
powerful
and
flexible
they
are
because
they
already
have
like
pre-created
templates
for
databases,
even
with
their
own
weight
strategies,
very
targeted
to
the
specific
type
of
container
database
or
different
other
tools.
B
They
do
have
one
kind
of
operation.
It's
called
ryuk
that
make
sure
that
your
containers
are
well
behaved.
This
means
that
once
they
are
running
well,
they
start
off
they
run
and
then
they
are
killed.
Even
if
your
tests
are
failing,
because
in
that
years
back
I
would
usually
get
the
call
from
the
itis
excel.
B
You
crush
the
machine
because
you
have
like
one
thousand
zombie
joker
containers
and
I
was
like
what
and
it
was
because
sometimes
the
test
failed
and
I
I
we
didn't
dispose
of
the
resources
correctly.
There
were
some
workarounds
like
before
running
the
test.
You
kill
everything
in
the
machine,
but
it's
not
okay.
B
So
if
you
need
to
work
with
integration
tests
you
if
the
simple
ones
or
the
very,
very
complex
ones,
I
totally
recommend
you
to
have
a
look
into
this
project.
It's
going
to
worth
your
while
and
it's
easy
to
set
up
and
it's,
as
I
said,
it's
flexible,
there
are
already
some
predefined
types
of
content
of
containers
or
test
containers
and
you
have
the
generic
one
so
totally
recommended.
C
In
my
personal
experience
as
a
developer
on
a
development
team,
before
I
was
on
a
devops
team,
I
had
little
exposure
to
the
deployment
itself.
My
life
was
all
about
just
you
know.
I
was
in
my
ide.
I
fixed
things
checked
things
in
I
was
done,
went
home
for
the
night
and
slept
well
now
that
I'm
on
a
devops
team,
no
I'm
just
kidding
now
it's
definitely
more
of
a
concern
for
me
like
what
exactly
is
going
on
in
deployment
world
and
along
with
the
automation.
C
Now
that
you
have
all
these
containers
and
everything
the
bigger
your
project
is
the
more
likely
it's
going
to
become
difficult
to
manage.
All
of
that
kubernetes
is
an
awesome,
orchestration
tool
if
you
may
not
get
into
the
nitty
gritty
of
cluster
maintenance
as
a
developer.
In
fact,
you
know
it's
possible.
You
may
have
an
infrastructure
team
that
deals
with.
You
know
upgrading
clusters,
that
kind
of
stuff,
but
it's
important
to
understand
how
it
works.
C
C
Each
of
these
it
sounds
overwhelming.
It
takes
50
days
to
learn
kubernetes
right,
but
each
of
these
little
points
you
know
there
are
a
a
single,
a
blog
or
a
little
video.
It's
not
going
to
take
you
all
day,
you
know
or
all
week
for
for
each
of
these
steps
here
day.
One
is
my
absolute
favorite
in
this
process.
Here
it's
I
actually
picked
up
a
hard
copy
of
these
children's
books.
C
It's
all
about
fippy,
which
is
a
php
app
learning
how
to
live.
You
know
in
kubernetes
land
and
it's
basically
a
child's
you
know
written
as
a
child's
book
to
teach
you
the
basics
of
kubernetes
and
there's
cute
metaphors
in
there.
Some
of
them
might
be
a
little
forced,
but
that's
okay,
there's
always
a
page
that
is
more
technical.
That
describes.
You
know
exactly
what
they're
talking
about.
C
C
Another
way
to
learn:
kelsey
hightower
has
a
really
good
github
repository
called
kubernetes
the
hard
way
this
really
gets
down
into
the
details
of
kubernetes
and
forces
you
to
start
at
the
beginning,
so
that
you
learn
how
actually
everything
is
put
together
and
how
everything
works
highly
recommended
directly
from
the
readme
here.
Kubernetes.
The
hard
way
is
optimized
for
learning,
which
means
taking
the
long
route
to
ensure
you
understand.
Each
task
required
to
bootstrap
a
kubernetes
cluster
so
definitely
go
here
to
learn
once
you've
learned.
C
These
are
some
of
the
things
that
you're
going
to
need
to
consider
when
you're
building
your
app
or
when
you're
modifying
an
ex
existing
app
to
behave
the
best
in
this
new
environment
in
this
container
and
cluster
environment.
So
this
comes
directly
from
a
white
paper
available
at
jfrog.
I
have
the
link
here.
C
C
So
these
looking
through
these
questions,
as
a
team
kind
of
gives
you
a
little
bit
of
an
idea
of
what
can
potentially
happen
in
a
production
environment,
things
that
you
should
be
concerned
about
and
things
to
optimize
on.
I
like
this
one
data
persistency,
you
know,
don't
don't
persist,
everything
persist.
What
you
need,
I'm
you
kind
of
defeat.
The
purpose
of
having
a
container,
you
know,
make
sure
you're
persisting
what
you
need,
of
course,
because
your
container
can
die
and
go
away,
but
make
sure
that
you,
you
aren't
overkill
here
termination
signals.
C
This
is
one
I
personally
had
a
problem
with.
It
was
something
I
added
to
one
of
our
services,
because
there
really
was
no
graceful
way
to
shut
it
down.
There
was
no
end
point.
It
was
just
you
know,
kill
it
and
be
done
well.
If
you
killed
it,
while
it
was
actively
being
used
in
production,
the
only
thing
for
your
user
to
do
is
just
you
know,
try
their
process
again.
Unfortunately,
this
particular.
D
Server
yeah
and
it
comes
from
the
from
the
pet
from
the
pet
concept
right
that
you,
you
shouldn't,
kill
your
application.
Instead,
you
try
to
fix
it
and
try
to
keep
it
alive
as
long
as
possible.
One
of
the
big
changes
are
exactly
that
that
you
now
need
to
be
ready
to
kill
your
application,
and
it
should
go
down
very
fast,
and
this
is
why
you
need
the
kill,
the
kill,
monitoring.
C
Exactly
and
gracefully
our
services,
some
of
the
processes,
were
very
lengthy
amounts
of
time.
So,
having
you
know
forcing
a
customer
to
redo
their
stuff
was
pretty
painful,
and
there
are
many
reasons
why
you'd
want
to
kill.
You
know
you
may
want
to
you
need
to
work
on
an
upgrade,
or
you
need
maintenance
of
some
kind.
Consider
you
know
how
you've
deployed
your
cluster.
You
know
if
it's
possible
to
only
kill.
You
know
part
of
your
cluster.
Only
some
pods
update
those
and
then
reroute
traffic.
C
C
Like
that
exactly-
and
it
is
a
different
way
of
thinking
it's
exciting
when
you
get
something
up
and
running-
and
you
just
want
to
push
it
out
there,
but
you
really
need
to
think
of
these
scenarios.
You
know
when
it
doesn't
work
and
we're
trained
to
do
this.
In
our
you
know
our
code,
when
you
get
down
to
the
the
details,
you
know
we're
trying
to
look
at
a
a
function,
for
example,
and
make
sure
that
it
behaves
the
right
way
and
we
consider
all
the
failure
scenarios
but
bigger
picture
failure.
C
D
C
I
really
like
the
visual
this
provides
with
the
actual
pipeline.
When
you
know
the
just
the
term
software
pipeline
can
sometimes
seem
like
magic.
It
isn't,
it
is
not
magic.
It
is
just
the
steps
that
you
take
to
progress
your
software
down
the
line
so
in
this
particular
pipeline,
this
is
a
development
pipeline.
C
C
Then
we
we
publish
the
container,
we
put
it
in
an
appropriate
repository
and
then
we
we
can
run
some
tests
on
it
here.
You
know
run
it
through
integration
test
that
kind
of
thing.
When
everything
passes
you
promote
your
artifact,
promote
your
container
image
to
the
next
step
in
your
cycle,
which,
in
this
one,
is
a
staging
repository,
a
lot
of
these
tools
operate
in
the
same
way,
this
particular
one
integrates
with
various
tools.
D
I
have
a,
I
have
a
question
elisa.
So
what
I
see
here
is
that
what
we
triggered
in
the
beginning
was
the
front-end
the
front-end
build,
and
that
was
like
an
august
to
committing
a
change
into
one
of
the
npm
files
now
and
that
that
generated
like
run
number
11..
When,
when
we
look
at
the
back
end,
when
we
look
at
the
maven
build,
it
is
run
number
seven.
C
D
C
C
C
C
D
C
Okay,
we
can
look
at
the
the
docker
file
here.
A
lot
of
these
tools
are
are
using
this
wonderful
language
called
yaml,
get
used
to
it,
because
it's
not
going
away.
You
find
it
everywhere
in
ops,
tooling,
all
over
the
place,
this
pipeline
product
also
uses
yaml,
and
it
just
uses
it
to
describe
each
and
every
step
that
we
take
as
long
as
well
as
the
resources
where
we
get
our
source
from
our
github
repos.
All
of
that.
C
So
this
describes
each
step,
the
packaging
there's.
Also
some
you
know
you
can
add
conditionals.
I
don't
have
a
lot
of
conditionals
in
here,
but
you
can
add
conditionals
something
to
consider
what
happens
if,
at
a
certain
step,
the
build
fails.
What
do
you
want
to
do
really
important
to
look
at
that
failure
scenario
because
otherwise
you're
going
to
end
up
with
a
lot
of
you
know,
headaches
fixing
builds
quickly
because
everyone's
stalled
so
make
sure
that
you
have
the
you
know.
Good
messaging
alerts,
that
kind
of
thing
when
a
build
fails.
C
Yep
this
particular
product
has
a
lot
of
built-in
mechanisms
and-
and
you
know
like
jenkins,
there's
a
lot
of
plug-ins-
you
can
use
it's
kind
of
nice
if
you
have
stuff
built
in
it,
makes
it
a
little
easier
to
read,
but
you
can
always
re.
You
know
go
back
to
just
shell
scripting.
If
you
need
to
do
something
special.
D
Because
I
think
this
is
where
kind
of
everything
happens
right,
this
is
where
we
see
how
we
build
all
those
parts
together.
How
we
bring
the
maven
build
that,
obviously,
all
the
java
developers
are
familiar
with
and
the
npm
build,
which
doesn't
matter
how
it
works,
it's
all
javascript
magic,
but
in
the
end
of
the
day,
in
in
the
docker
file,
this
is
where
we
bring
everything
everything
together,
great.
C
Right
so
here's
the
docker
file
what
this
file
does
is.
It
builds
an
image
using
the
sources
from
our
repositories
that
we
have.
We
have
some
private
repositories
set
up.
We
grab,
you
know
our
our
back
end
and
our
front
end,
and
then
we
put
them
together
into
our
image.
Now
there
is
a
lot
that
can
be
improved
here
in
this
particular
docker
file.
As
you
can
see,
there's
there's
quite
a
few
hard-coded
values.
C
Some
things
can
should
be
passed
in
like,
for
example,
you
might
not
want
to
hard
code.
Your
your
registry
that
you're
getting
your
artifacts
from
here.
This
is
something
that
you
might
want
to
pass
in,
because
it's
likely
different
per
environment
or
per
stage.
You
know
whatever
stage
you're
you're
building
your
image
in
yeah.
D
Another
another
idea
that
can
you
can
implement
very
easily
and
then
have
more
flexibility,
is
the
versions
of
the
dependencies
that
you
use.
We
use
here,
1.0
and
3.0
as
kind
of
a
snapshot.
If
you
like
right,
we
are
going
to
re
re
override
them
every
time,
and
this
is
obviously
a
very
big
practice
when
you
go
and
build
your
production
pipeline,
it's
fine
for
demo,
but
that's
not
how
you
actually
should
do
stuff
in
real
life.
Instead,
you
can
use-
and
this
is
a
very
kind
of
popular
practice
and
it's
good.
C
That
makes
sense,
I'm
sure
you
have
strong
opinions
on
this.
A
lot
of
docker
files
out
there
do
not
specify
versions,
you
can
have
base
images,
it
just
has
the
name
of
the
base
image
other
artifacts
pulled
in
and
there
is
no
version
specified,
and
that
means
that
you're
pulling
the
latest
whatever
latest
means.
C
Sometimes
you
might
even
see
the
tag
specified
latest
latest,
is
a
pointer
that
is
assigned
to
a
particular
version,
doesn't
always
mean
that
it's
actually
the
latest
so
be
careful.
When
you
are
referencing
artifacts
make
sure
that
you
are
using.
You
know
that
you
have
your
head
wrapped
around
your
versions
and
what
you
actually
want
to
pull
in
what
you
want
to
build.
D
D
D
It
will
probably
be
security
patches
and
they
won't
probably
build
break
anything,
but
sometimes
it
might
to
avoid
that
what
you
need
to
do
is
actually
not
use
what
you
have
in
line
number
four,
but
instead
use
what
you
have
in
line
number
five,
and
this
is
bring
the
base
image
from
your
own
registry
and
when
you
bring
it
from
your
own
registry.
This
is
how
you
guarantee
that
it
will
always
consistently
resolve
the
save
the
same,
build
build
image
every
time
you
build.
So
this
is
actually
even
when
you
specify
the
version.
D
C
One
other
comment
I
have
about
this
particular
pipeline:
it's
very
good
to
show
you
know
an
example
of
possibilities.
What
you
can
do,
but
one
thing
I
would
do
differently,
probably
is
definitely
use
create
images
separately
for
the
front
end
and
the
back
end,
because
in
this
way
you
can
really
take
advantage
of
your
scaling
capabilities.
C
You
may
want
to
scale
your
back-end
server
differently
than
your
front-end
application.
There's
some
advantages
to
doing
that
so
based
on
load
or
you
know
other
performance
metrics.
You
may
notice
some
improvements
by
scaling
those
differently,
so
one
reason
to
definitely
separate
them
out
into
their
own
services.
For.
C
C
Likely,
though
you're
going
to
have
multiple
pipelines,
each
team
may
have
their
own
development
pipelines.
You
are
also
going
to
have
multiple
deployment
pipelines.
You
may
have
a
pipeline
that
is
specific
for
deploying
to
your
staging
environment,
for
example,
pipeline
that
deploys
to
your
production,
environment
and
those
might
be
manually
triggered.
You
know
if
you
don't,
if
you
aren't
comfortable
or
don't
have
enough
enough
of
a
security
blanket
set
up
to
protect
you
from
mistakes,
you
may
want
to
schedule
your
deployments,
in
which
case
you
would
have
a
separate
deployment
pipeline.
C
This
has
been
really
informative.
We've
learned
a
lot.
I
love
that
the
four
of
us
have
such
diverse
backgrounds
and,
like
we
all,
have
some
good
ideas
and
thoughts
about
how
all
of
this
should
be
pulled
together.
This
has
been
an
amazing
experience.
I
hope
that
everyone
in
the
audience
has
gotten
something
out
of
this,
that
you
can
take
back
to
your
teams.
Let
us
know
if
you
have
any
questions.