►
From YouTube: Sponsor Demo: CircleCI - Increase App Confidence using CI/CD and Infrastructure as Code
Description
Ever run code in CI/CD and builds pass only to fail during deployment? This presentation will discuss the advantages of Smoke Test patterns in CI/CD pipelines using Infrastructure as Code (IaC). Learn how teams can leverage automation to ensure apps are tested live in target environments which provide valuable insights pre-deployment. Angel will demonstrate how to leverage IaC to provision infrastructure, deploy apps, test then destroy all the resources created in a single CI/CD pipeline run.
A
Hello,
everyone.
I
want
to
welcome
you
all
to
this
talk.
The
talk
is
titled
increasing,
app
confidence
using
ci,
cd
and
infrastructure's
code,
and
in
this
talk
I'm
going
to
be
talking
primarily
about
smoke,
testing
and
some
of
the
benefits
you
can
gain
in
increasing
the
confidence
in
your
releases
by
leveraging
infrastructures
code
and
ci
cd.
A
A
It's
a
pretty
cool
job
where
I
get
to
actually
learn
a
lot
about
how
folks
are
actually
using
technology
right
in
real
world
instances
versus
theory.
So
today
I
want
to
kind
of
share
some
information
that
I've
gained
over
time.
Regarding
increasing
you
know
your
application
release
confidence,
meaning
you
know
it's
been
kind
of
tested
and
different
strategies
on
how
to
do
that
quickly
as
well
right
because
the
cicd's
all
about
being
gaining
velocity
in
your
software
development
life
cycle.
So
I
definitely
want
to
share
some
of
that
information
with
you.
A
So
let's
talk
about
smoke
tests.
I
speak
to
a
lot
of
developers
like
I
mentioned
earlier,
and
when
I
speak
to
them,
I
always
ask
them
about
you
know
what
kind
of
smoke
testing
are
you
doing,
because
we're
always
discussing
how
to
make
our
pipelines
more
efficient,
more
optimized
and,
quite
frankly,
I'm
very
surprised
that
the
amount
of
responses
that
I
get
basically
telling
me
you
know
their
test
runs
are
pretty
comprehensive
and
expensive,
meaning
they
do
a
lot
of
rigorous
testing
on
every
build.
A
So
with
that,
you
know
when
we're
talking
about
smoke,
testing
smoke
tests
are
designed
to
be
simple
tests
right
that
you
run
every
time
on
your
builds,
because
you
want
to
kind
of
suss
out
the
low-hanging.
Fruit
is
what
I
call
it.
So
you
know
there
are
configurations
that
you
know
will
cause
problems
if
they're
not
set
correctly,
so
you
would
run
a
smoke
test
against
that
right
and
again,
these
are
kind
of
tests.
A
You've
run
against
things
that
you
already
know
about
for
the
most
part,
and
you
want
to
make
sure
that
nothing
has
changed
right,
because
we
all
kind
of
modify
code
and
we
maybe
change
a
configuration
or
a
flag
in
our
code.
A
That's
not
what
smoke
tests
are
smoke.
Tests
are
the
simple
things
that
you
can
do
really
really
quickly:
they're
designed
to
be
lightweight
and
scale
all
right
and
so
and
effort
as
well.
So-
and
you
know
good
analogy-
is
when
I
was
a
kid
in
high
school
working
summer,
jobs
in
construction.
A
I
would
watch
the
plumbers
kind
of
build
out
their
whole
project
in
the
construction
of
a
building,
and
one
of
the
things
I
noticed
was
like
they
were
testing
these
the
plumbing
with
by
injecting
smoke
into
into
the
plumbing,
and
I
always
wondered:
why
would
they
do
that?
The
reason
was
think
about
it.
If
you,
you
know,
if
you're
a
plumber
and
you
join
two
pipes
together
and
you
make
a
joint
right
and
let's
say
you
want
to
test
that
joint.
A
If
you
throw
water
in
that
plumbing,
just
going
to
have
a
big
mess
on
your
hands,
if
you
have
any
kind
of
leaks
right,
so
the
smoke
is
kind
of
their
really
lightweight
way
to
engage
their
work
and
test
their
work
without
having
to
create
a
big
mess
and
get
everything
wet
right,
so
it
kind
of
was.
I
thought
it
was
genius
at
the
time
and
then,
as
I
you
know,
progressed
on
into
developing
software.
A
This
term
came
up
a
few
times
and
it
kind
of
made
sense
to
me
already
so
right.
So
if
you
think
about
smoke,
testing
think
about
it
that
way
right.
So
it's
the
way
to
test
some
things
without
really
getting
messy.
A
Now,
that's
not
an
extensive
test
right
per
se,
because
if
you
stick
water
inside
those
pipes
and
you
can
still
have
leaks,
but
at
the
end
of
the
day
you
can
kind
of
suss
out,
any
kind
of
you
know
leaks
that
you
have
or
bad
seals
that
you
have
in
your
joints
just
by
running
smoke.
So
when
you
think
about
smoke,
testing
right
again,
keep
in
mind
it's
supposed
to
be
lightweight
and
very
limited
in
scale,
and
obviously,
if
you're
finding
you
know
problems
during
your
smoke
test
right
now.
A
Smoke
testing
will
help.
You
also
avoid
the
unknowns,
or
at
least
you
know,
help
identify
some
of
the
problems
that
you
didn't
know
about
in
your
code.
Right
tests
are
only
as
good
as
I
guess,
the
experience
that
you've
had
with
your
code
and
the
way
that
you've
run
it
right.
So
I
get
this
question.
A
Often
a
lot
is
like:
when,
should
I
run
smoke
tests
and
again
these
tests
are
supposed
to
be
designed
to
be
lightweight
and
pretty
much
effortless
right,
because,
if
you're
using
automation
you
just
pretty
much
tell
the
system
to
run
it.
So
what
we're
trying
to
do
is
balance
between
velocity
meaning.
You
know
going
really
really
fast,
with
your
ci
cd,
making
sure
that
everything
runs
quickly
so
that
you
get
that
fast
feedback
loop
versus
you
know
extensive
testing,
which
again
can
be
pushed
down
further
into
a
different
pipeline.
A
So
you
should
run
your
your
smoke
test
on
pretty
much
every
code
change,
so
anytime
code
changes
push
through
your
cicd
pipeline
run
a
smoke
test
right,
even
if
it's
you
know,
sometimes
you
can
use
unit
tests
kind
of
to
validate.
That's
kind
of
the
notion
I
get
from
unit
tests
is
that
they
are,
you
know,
kind
of
a
a
smoke
test
to
per
se,
but
I've
seen
some
folks
go
really
really
comprehensive
and
and
and
complex
with
their
with
their
unit
tests,
which
I
think
you
can.
A
You
can
strike
a
balance
there
right.
But
but
if
you
consider
you
know
running
unit
tests
on
every
code
run,
you
can
incorporate
smoke
testing
into
those
unit
tests,
so
you
can
also
leverage
ci
cd
right
to
run
these
tests,
which
you
should
be
doing
in
most
cases
modern
day
software
development
kind
of
dictates
that
we're
all
running
some
sort
of
cicd,
continuous
integration,
continuous
delivery
or
deployment
platform
or
services
right
against
our
code.
A
So
again,
right
you
want
to
run
your
smoke
test
on
every
ci
cd
run,
and
then
one
of
the
things
I
wanted
to
talk
about
today
was
smoke.
Testing
deployments
a
lot
of
folks
that
I
speak
to,
even
though
you're
running
ci
cd.
Maybe
you
even
have
smoke
tests
running
against
your
code
right
how
it's
going
to
maybe
run
in
a
server
environment
as
far
as
like
starting
the
application,
but
when
you're
actually
deploying
to
a
target
environment,
are
we
really
smoke
testing
those
deployments?
And
the
answer
is
generally?
No.
A
So
that's
what
I
want
to
kind
of
talk
about
today
and
the
way
you
would
be
able
to
do
that
really
really
easily
simply
and
almost
effortlessly
effortlessly
is
by
running
infrastructure
as
code
for
those
of
you
that
don't
know,
infrastructure's
code
is
a
way
for
you
to
codify.
All
of
your.
You
know:
creation
of
infrastructure,
especially
in
the
cloud
space
today,
rather
than
cloud
providers,
we're
leveraging
infrastructure
as
code
tools
like
paloomi
and
hashicorp,
which
is
plume,
is
going
to
be
the
one
I
show
in
my
demo
today.
A
But
for
the
most
part
you
want
to
leverage
infrastructure's
code,
so
you
can
build
out
those
target
environments
in
your
ci
cd
pipeline
and
then
deploy
your
application
to
those
and
then
destroy
them
right.
It's
always
a
great
kind
of
again
assurance
that
the
application
is
operating
as
design
in
the
target
environments
or
in
the
environments
that
you're
targeting,
I
should
say
so
again.
A
You
know,
with
with
pushing
smoke
testing
into
your
deployments,
you're
going
to
gain
insights
into
behaviors
within
that
target
environment,
so
real
quickly,
just
going
to
recap
what
I
talked
about:
definitely
automate
your
smoke
testing
using
cicd
or
some
other
form
of
automation.
It
will
help
you
identify
bugs
with
you
know,
low-hanging,
fruit
type
bugs
and-
and
that's
awesome
because
again
you
know
these
are
things
that
you
shouldn't
really
have
to
worry
about,
because
you
already
know
that
they're
there,
but
you
just
want
to
validate
that.
You
know
your
up.
A
Your
application
is
operating
from
jump.
The
way
it
was
designed
and
again
you're,
getting
some
valuable
insights
into
how
the
application
will
run
in
the
target
environments.
Make
sure
that
you
know
you're
down
down
down
towards
the
release
portion
of
your
of
your
pipeline.
Your
release,
managers
and
your
your
team
are
super
satisfied
because
it's
kind
of
been
vetted
right
through
that
whole
pipeline
process
and
finally,
right
to
increase
the
app
confidence
again.
You
know
testing
is
really
important.
A
It
also
helps
with
figuring
out
where
you
have
issues
and
then,
of
course
it
vets,
your
application,
which
then
leads
to
stronger
confidence
right
in
those
builds
and
releases
for
when
you're
deploying
to
the
target
environments.
A
So
this
is
pretty
much
the
end
of
the
talk
portion
and
I'm
going
to
jump
into
a
quick
demo
all
right,
so
I
just
wanted
to
show
you
some
code
for
this
demo.
Basically,
I
have
a
github
repo
and
it
just
has
a
simple
python:
flask
application
that
serves
up
a
static
web
page
again.
The
application
isn't
really
the
focus
here.
It's
just
showing
you
how
to
leverage
some
smoke
testing
strategies
within
your
shacd
pipeline.
A
So
let's
look
at
the
smoke
test
that
we're
gonna
run
against
our
deployment
real
quickly.
This
is
built
on
a
open
source
project
called
smoke.sh
and
basically
it's
a
bash
kind
of
framework
for
building
smoke
tests.
The
quick
thing
that
I
want
to
do
here
is
with
my
smoke
test
is
once
pollumi
instantiates
right,
a
new
kubernetes
cluster
within
gcp.
A
I
want
to
go
ahead
and
just
basically
do
some
basic
tests
on
it.
Make
sure
that
the
application
is
functioning
on
that
cluster
make
sure
that
the
docker
container
is
is
functioning
basically
executing
and,
and
you
know
starting
up
on
the
on
the
cluster
and
then
I'm
going
to
run
some
quick
tests.
So
one
of
the
things
I
want
to
run
is
obviously
check
for
the
server
make
sure
I
get
a
response
of
okay
200.,
that's
the
first
test.
A
The
next
test
is
going
to
be
validating
that
there's
some
specific
strings
that
I'm
looking
for
in
in
the
body
of
my
website.
Since
it
is
a
static
web
page,
we
can
do
that.
We
can
test
for
some
static
text
and
that's
what
I'm
doing
here
with
these
two
statements
and
once
that
happens
right,
the
tests
pass
and
then
pollumi
will
then
destroy.
A
So
that
means
all
that
infrastructure
that
I
built
will
be
completely
destroyed
because
you
don't
want
to
leave
infrastructure
upright
running,
that's
a
security
kind
of
concern,
as
well
as
wasting
money
for
the
most
part.
When
you're
doing
those
things
you
know
just
leaving
infrastructure
up
for
no
reason
and
again
it
served
its
purpose.
So
you
want
to
destroy
it,
which
literally
you
know
for
every
cicd
run.
You
want
to
run
a
check
against
this
deployment
in
the
environments
that
we're
targeting.
A
So
this
is
a
really
nice
way
to
kind
of
get
that
app
confidence.
I'm
talking
about.
So
let's
go
ahead
and
demo
this.
So
I'm
going
to
change
this
to
version
number
13.,
I'm
gonna
quickly
save
it
again.
This
is
just
a
quick
way
to
you
know,
show
off
some
of
that
stuff.
We're
gonna
go
ahead
and
do
a
okay
and
now
we're
gonna.
Basically
kick
off
by
pushing
this
commit
upstream
we're
going
to
jump
over
to
our
circle,
ci
dashboard
and,
as
you
can
see,
things
started
kicking
off
and
running.
A
Let's
take
a
look
real
quickly.
Take
a
look.
So
this
is
what
we
call
a
pipeline.
It's
the
overall
overarching
object
in
circle,
ci
and
then
what
we're
running
here
the
build
test
deploy
is
an
actual
workflow,
so
this
orchestrates
the
jobs
which
are
grouping
of
commands
right
that
serve
a
certain
purpose.
A
So
the
workflow
is
orchestrating
my
jobs
as
you
can
see,
I'm
running
two
jobs.
At
the
same
time.
This
is
called
running
in
concurrency
and
what
we're
doing
here
is
trying
to
save
time
right.
Ci
cd
is
all
about
quick.
You
know
software
development
processes,
so
one
of
the
ways
that
you
can
you
can
speed
things
up
in
your
feedback.
Loops
is
by
doing
multiple
things.
A
At
the
same
time,
right
it
makes
sense
when
you
have
multiple
tasks,
if
you
can
get
them
done
at
you
know,
at
the
same
time,
simultaneously
things
will
move
a
lot
quicker.
The
cool
thing
here
is
one
thing
I
want
you
to
note
is
there's
there
is
a
dependency
right,
so
this
deployed
to
gcp
will
not
occur
unless
both
of
these
pass.
So
if
any
one
of
these
jobs
fail,
this
will
not
kick
off
great.
So
now
we
have
our
kubernetes
cluster
deployed.
A
Our
smoke
test
ran
and,
as
you
can
see
here
on
the
system
here
are
the
results
right
here:
get
got
the
200
okay
response.
The
body
of
the
the
web
page
has
the
text
that
we
were
looking
for,
which
were
the
two
statements
here
and
then
the
application
is
actually
still
running
now,
while
that's
running,
let's
go
to
quick
check
just
to
see
it
visually
and,
as
you
can
see,
here's
the
application,
I'm
basically
running
right
with
version
13.
A
and
basically
that's
it
at
the
end
of
the
day.
What's
going
to
happen
next
is
the
system
well,
this
the
pipeline
will
then
run
paloomi,
destroy
and
all
that
infrastructure.
As
I
mentioned
earlier,
you
don't
want
to
leave
that
lingering
collecting
debt
and
then
also
being
available
there,
for
maybe
some
security
problems
right
or
concerns.