►
From YouTube: Accelerate your Cloud Development with Buildpacks and Screwdriver - Juan Peredo, Bolbeck llc
Description
Accelerate your Cloud Development with Buildpacks and Screwdriver - Juan Peredo, Bolbeck llc
In the current ecosystem, developers are expected to deliver solutions faster than ever. And yet, with the arrival of newer paradigms like micro services and containers, we now have to setup and maintain additional technologies like Docker, Kubernetes and CI/CD. During the talk will walk through a demo that shows how to leverage Cloud Native Build Packs to speed creation of all those additional components with little developer effort. It will also show how to use Screwdriver to quickly setup and operate pipelines and easily manage your application.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
Errors
are
starting
to
crop
up.
Pipelines
are
there's
no
pipelines
to
run
which
is
causing
a
problem
in
in
their
work-life
balance,
so
our
mission
will
be
to
create
an
automatic
pipeline
that
will
help
our
team
get
back
their
work-life
balance,
and
this
pipeline
should
work
natively
with
monorepos,
encourage
drive
principles
and
implement
ops
and
use
containers.
A
But,
more
importantly,
we
want
to
do
everything
as
code
so
that
we
can
recreate
the
steps
as
needed.
So
I'll
be
your
guide
in
this
mission.
My
name
is
juan
pereiro,
I'm
a
tech
consultant,
architect
and
developer,
and
everything
in
between-
and
here
is
what
we're
planning
to
do.
So
we
will
take
the
code
and
we'll
push
it
to
github
and
then
we'll
have
screwdriver
cd,
which
is
a
csd
tool.
Pull
the
changes
from
github,
build
our
containers
and
push
them
to
docker.
A
A
Let
me
just
show
you
what
the
repo
looks
like.
So
we
have
our
root
folder
inside
the
root
folder.
We
have
our
different
services,
like
our
audit
service,
our
customer
service,
our
promotion
service,
and
we
also
have
our
web
folder
that
contains
the
front
end,
including
a
docker
file.
That's
in
charge
of
building
our
application.
A
Additionally,
we
also
have
a
screwdriver.yamalpha,
which
is
what
will
be
in
charge
of
defining
our
pipeline
for
us
and
we'll
walk
through
this
screwdriver,
the
ammo
in
a
few
minutes
all
right,
but
speaking
of
screwdriver.
Let's
take
a
quick
look
at
it,
so
here
I'm
logged
into
screwdriver.
I
can
see
that
we
have
two
pipelines
defined.
A
A
A
And
we
can
see
that
testing
our
application.
This
particular
step
is
taking
a
whole
what's
taking
a
whole
lot
longer
than
it
should
have
compared
to
what
it
took
the
last
time
we
run.
It
was
over
twice
as
long
and
that's
really
cool
when
we're
trying
to
figure
out
what
how
application
pipeline
is
doing.
Health-Wise,
and
here
we
can
see
our
screwdriver
the
yamaha
in
more
detail,
and
this
is
what
defines
our
pipeline
and
there's
different
steps
that
are
going
to
run.
A
We're
going
to
say
that
we're
going
to
run
this
pipeline,
or
this
particular
job
of
the
pipeline
anytime,
there's
a
pr
or
a
commit
to
a
github
repository,
but
only
if
it's
hitting
the
promotion
dash
server
directory
or
the
global
util
directory.
If
it's
not
one
of
those
directories,
we're
not
going
to
execute
this
particular
job.
A
And
then,
finally,
we
have
the
steps,
and
these
steps
should
be
very
familiar
to
anybody.
That's
done
go
development
before
now.
These
are
very
common
steps
and
in
fact
all
these
steps
could
be
shared
by
all
the
microservices
that
we're
building
in
go
and
remember.
One
of
the
one
of
our
goals
with
spy
plan
is,
do
not
repeat
yourself,
so
the
fact
that
we're
going
to
have
to
repeat
all
these
steps
every
time
we
build
one
of
our
services
is
not
the
best.
A
A
Now,
a
template
is
a
way
to
abstract
some
of
the
or
extract
some
of
those
steps
and
put
them
in
a
place
where
they're
reusable.
What
does
this?
Let's
walk
through
this
pipeline?
This
pipeline
is
actually
built
on
the
top
by
some
metadata
that
will
allow
us
to
identify
and
call
our
pipeline
and
the
the
individual
steps
that
we
want
to
reuse.
A
So
here
I'm
gonna
have
our
second
pipeline
job.
So
this
is
a
continuation
of
our
original
template,
but
instead
of
having
all
those
steps
there,
I'm
basically
gonna
use
the
template
and
the
way
I'm
gonna
use
that
template
is
I'm
going
to
have
I'm
going
to
call
it
by
namespace,
name
and
version,
and
then
I'm
going
to
provide
any
additional
steps
that
I
want
to
run.
Besides
the
steps
on
that
template
and
these
steps
will
be
merged
with
the
steps
from
our
template
and
how
does
that
work?
A
Portion
of
the
name
of
the
additional
of
our
additional
steps,
so
anything
that
was
free
so,
for
example,
pre-download
is
put
before
the
download
step.
Anything
that's
posts.
For
example,
here
post
test
is
going
to
be
placed
after
the
test
step
when
it's
actually
executing
the
job
and
creating
the
pipeline
so
awesome.
A
Then
we
are
going
to
tell
it
through
an
annotation
that
we
want
to
enable
docker,
and
what
this
actually
means
is
that
we
want
screwdriver
to
run
an
additional
container
within
our
pod.
That's
going
to
be
building
our
pipeline,
then
this
particular
job
and
this
traditional
pod
will
be
running
docker
in
docker,
so
that
we'll
be
able
to
run
docker
to
build
our
image.
A
A
You
can
see
the
different
steps
we
can
see
the
setup
steps
of
the
setup
steps
are
actually
automatically
created
by
screwdriver
and
in
particular
I
want
to
show
you
at
this
point
this
one,
because
it's
automatically
pulling
our
code
from
github
into
the
image,
so
you
can
build
it.
So
it's
something
that
we
don't
have
to
worry
about.
It
automatically
happens.
A
A
Job
I
want
to
show
you
here
in
the
setup
I'm
going
to
look
at
the
screwdriver
cache
bookend
and
we
can
see
that
the
first
one
of
the
first
things
is
done
is
downloaded
our
cache.
And
now,
if
I
look
at
the
download
step,
the
download
step
took
only
two
seconds,
because
I
go
smart
enough
to
detect
that
all
its
dependencies
are
already
in
that
direction
and
it
doesn't
do
the
load
anymore.
So
the
cache
has
saved
us
a
certain
amount
of
time
and
bandwidth
all
right.
A
Take
a
look
at
our
code.
They
push
to
push
it
to
a
builder,
and
this
builder
has
all
the
steps
necessary
to
build
a
number
of
code
bases,
and
this
builder
will
pass
the
code
to
the
build
packs
that
will
analyze
the
code
and
determine
if
they
are
applicable
to
that
particular
code
base.
So,
for
example,
if
you
had
a
nodejs
application
and
you
had
a
package.json,
then
it
would
run
some
package.json.
A
A
A
A
A
Then
we
have
some
build
commands,
so
we're
indicating
which
builder
is
our
default
builder,
so
we
don't
have
to
specify
on
every
command
we
also
specifying
which
files
we
want
to
exclude
when
we're
building
our
our
application.
So
you
can
think
about
the
exclude
flag
here
as
a
git
ignore,
and
we
can
also
have
some
build
environment
variables
if
we
wanted
to.
A
All
right
and
the
images
that
pack
and
buildbacks
in
general
are
going
to
create
a
fully
oci
compliant,
meaning
that
you
can
run
in
docker
with
docker
docker,
compose
and
kubernetes
anywhere.
You
can
run
an
image
and
pack
can
be
integrated
with
any
cicd
tool
and
there
is,
and
pack
itself
needs
a
docker
daemon
to
run,
but
there's
other
implementations
of
build
packs
that
don't
need
them
at
all.
A
A
A
A
A
That
will
allow
me
to
log
into
in
to
the
container,
if
need
be
all
right,
but
now
we
can
see
that
it's
actually
doing
its
thing
and
if
we
go
back
up
here,
we'll
see
the
first
thing
that
he
did
was
it
detected
which
build
packs
to
use.
So
it's
gonna
install
some
certificates,
it's
gonna
download
our
dependencies
and
it's
gonna
build
our
application.
A
Then
you
start
that
then,
is
actually
going
to
start
the
process
of
building
so
downloaded
the
buildpack
certificate,
building
the
go
mod
and
building
the
actual
application
now
and
that's
going
to
take
a
few
more
seconds,
so
I've
run
these
commands
before.
So
let
me
show
you
what
the
difference
is
between
the
two
images
just
based
on
which
build
pack.
I
used
I'm
going
to
come
up
here.
A
A
Oh
that's
pretty
cool,
and
now
it's
done.
You
come
up
here
and
I'm
gonna
do
show
me
the
images
for
we
just
built.
We
can
see
the
first
one
is
167
megs
for
our
dev
image,
and
while
our
prod
image
is
74.
72.,
it's
much
smaller
and
that's
the
power
of
build
packs.
You
can
build
images
for
a
specific
purpose,
just
by
changing
the
builder
that
you're
using
or
the
build
pack
that
you're
using
the
key
type
coast
of
what
we
just
discussed
right.
A
A
We've
simplified
the
process
of
building
our
application,
including
the
use
of
build
packs.
So
we
don't
have
to
maintain
additional
files.
We
use
it
with
technology,
that's
meant
to
be
scalable
and
all
that
results
in
productivity
and
cost
reductions
for
our
company,
but,
more
importantly,
that
allows
us
to
regain
our
work-life
balance
and,
with
that,
come
to
an
end
of
our
presentation.
A
A
A
So,
for
example,
one
of
one
of
the
main
differences
between
screwdriver
and
jenkins
is
the
fact
that
screwdriver
supports
monorepos
out
of
the
box.
All
right,
we
saw
in
the
demo
how
I
could
tell
screwdriver
to
execute
a
particular
job
based
on
a
particular
based
on
where
the
change
that
was
committed
went.
So
if
it
was
committed
to
a
particular
folder,
then
we
would
execute
job
a
if
it
was
committed
to
a
different
folder.
We
could
execute
job
b
or
both
if
we
wanted
to.
A
At
the
end
of
the
day,
it
depends
on
what
you're
trying
to
achieve
another
really
cool
thing
that
I
really
like
from
screwdriver
is
the
fact
that
you
can.
You
have
reusable
pipelines,
which
is
what
we
saw
in
the
demo
as
well,
where
steps
that
are
repeated
across
multiple
pipelines
and
not
necessarily
just
the
pipeline
you're
working
on,
but
it
could
be
pipelines
that
somebody
else
is
building
is
that
you
can
take
those
pieces
and
put
them
into
a
template,
and
you
reuse
that
template
all
the.
A
A
A
Screwdriver
has
a
section
where
you
can
publish
those
the
templates
and
therefore
you
can
share
with
different
people
so
yeah.
Absolutely
it
should
it's
something
that's
out
there
and
it's
something
that
would
that
makes
screwdriver
more
shareable
and
community,
driven
speaking
of
which,
if
you
go
to
their
website
and
you
can
see
all
the
information
and
additionally,
they
have
a
slack
channel
that
you
can
join
where
they're
very
responsive
and
they
like.