►
From YouTube: The 5-Step Checklist for your Migration to Tekton - Priti Desai, IBM & Jerop Kipruto, Google
Description
The 5-Step Checklist for your Migration to Tekton - Priti Desai, IBM & Jerop Kipruto, Google
Speakers: Jerop Kipruto, Priti Desai
What do you use to build, test, and deploy your cloud native applications? Is your choice of CI/CD solution powerful yet flexible for all of your use cases? Have you heard about Tekton? Tekton is an Open Source CI/CD pipelines execution engine. Tekton Pipelines can define Steps, Tasks (collection of steps), Custom Tasks (advanced Run objects), and Pipelines (collection of Tasks and Custom Tasks). Pipelines also support resources to connect multiple Tasks through input/output models or workspaces to share a file system across many different Tasks. Tekton is implemented based on four core design principles: Reusability Simplicity Flexibility Conformance Tekton is highly optimized for building and deploying cloud native applications compared to other CI/CD tools. In this session, we will demonstrate migrating common CI/CD pipelines to Tekton by building a checklist for the migration.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
B
A
B
B
The
third
is
a
pipeline,
which
is
a
collection
of
tasks.
Running
a
set
of
pods
a
pipeline
is
a
graph
which
provides
the
flexibility
to
organize
the
workflow
based
on
the
requirements,
applicant
combines
tasks
to
parameters,
results
and
workspaces
and
also
provides
a
task
and
step
level.
Isolation
if
needed.
B
We
have
triggers
for
that
which
has
event
listeners
that
trigger
pipeline
runs
based
on
the
events.
The
trigger
binding
extracts,
relevant
information
from
the
event
payload.
Then
the
trigger
template
provides
a
blueprint
for
creating
the
pipeline
run.
So,
instead
of
everyone
creating
their
own
tasks
and
pipelines,
is
there
any
way
to
share
usable
resources
across
the
organization
or
even
with
the
community?
B
A
So
the
way
we
define
pipeline
intake
is
basically
equivalent
to
a
workflow
in
argo,
workflow
and
github
actions
and
similarly
pipeline
in
jenkins.
The
way
we
define
tasks,
so
this
might
not
be
a
fair
comparison
or
apples
to
apples
comparison,
but
the
way
we
define
task
task
is
a
pod
in
tecton.
There
are
a
lot
of
different
template
types
available
in
argo
workflow,
and
many
of
these
template
types
also
has
like
containers,
scripts,
etc.
So
and
github
actions
has
jobs
for
which
is
very
similar
to
task
and
jenkins
has
stages.
A
So
the
all
of
these
all
of
these
tools.
They
are
meant
for
ci
cd
systems
and
they
have
their
own
principles,
design,
guidelines
and
most
of
these
ci
cd
use
cases
they
they
they
need
the
functionality
where
something
there
has
to
be
basically
getting
executed,
something
before
the
pipeline
ends
or
you
know,
exits.
So
in
tecton
we
have
finally,
which
is
guaranteed
to
be
executed
before
the
pipeline
exits
in
argo
workflow.
There
is
something
exit
handler
in
github
actions.
A
There
is
something
called
post
actions,
similarly
in
jenkins
and
we're
going
to
look
at
argo,
cd
and
github
actions
later
on
and
we'll
have
a
demo
for
that.
So,
let's
first
look
at
a
very
common
ci
cd
use
case.
So
whenever
so,
this
is
a
very
build
test.
Deploy
rollback
pipeline-
and
here
what's
happening,
is
a
developer,
is
committing
some
changes
or
writing
the
application.
What
we
are
trying
to
do
is
cloning,
the
application
repo
into
the
shared
workspace,
then
the
linting
building
and
testing
integration
testing.
A
Everything
is
being
done
on
workspace
where
the
code
was
closed.
After
all
of
these
tasks
finishes,
we
are
building
and
publishing
an
image
to
a
container
registry
and
we
are
using
the
same
image
to
deploy
on
multiple
clusters.
For
example,
here
we
are
deploying
the
same
image
on
div
and
stage
cluster
now
here.
The
important
distinction
between
the
normal
task
and
the
deploy,
the
tasks
that
we
have
defined
before
and
the
deploy
task
is
deploy.
A
Task
is
a
iterative
kind
of
functionality
where
the
same
task
specifications
are
used
to
run
same
task
run
for
develop
dev
cluster
and
the
staging
cluster.
So
basically,
there
is
something
called
custom
task
that
was
recently
introduced
in
tecton,
which
is
being
used
here
and
what's
happening
in
the
end.
Is
let's
say
if
the
deployment
on
any
one
of
the
clusters
fail,
then
we
have
an
option
to
roll
back
so
that
both
the
clusters
basically
are
in
the
same
state.
A
A
So
for
that
particular
use
case
when
a
developer
is
committing
a
change
and
the
image
is
being
built
and
then
the
image
is
being
deployed
and
make
it
basically
is
making
made
available
here
we
need
to
go
cd
applications,
one
for
the
tecton
resources
and
one
for
the
deployment
and
so
the,
but
before
even
before
that,
we
need
the
secrets,
so
we
need
the
so
from
the
pipeline.
The
task
run,
which
is
part
of
the
pipeline.
A
A
So
that's
where
the
image
is
being
deployed
on
the
cluster
and
is
available
so
all
whatever
changes
the
developers
did
are
now
available
on
the
cluster.
So
let's
look
at
this
in
action.
We
have
a
demo
for
this
and
let's
see
so,
if
I
can
play
this
so
here
I
have
a
cdcon
2021
repo,
where
I
have
where
I
have
the
tecton
resources
and
the
deployment
files.
So
here
you'll
see
the
pipeline
it's
in
a
one
directory
and
then
there
is
a
deployment
directory.
A
So
we
are
deploying
see
we
have
created
a
cd
called
namespace
and
that's
where
everything
is
happening
so
deploying
argo,
cd
secrets,
followed
by
the
service
account
for
publishing
the
image.
Now
next
is
I'm
creating
the
the
I'm
creating
here.
The
cd
called
something
called
cdcon
app
build
to
basically
sync
the
tecton
pipeline
resources
here,
the
very
first
argo
cd
application
that
we
looked
at
so
you'll
see
that,
yes,
there
is
an
application
got
created
here
and
it's
referring
to
slash
pipeline
and
has
all
these
resources.
A
A
First
of
all,
let's
go
and
update,
add
a
webhook
so
that
yes
add
a
webhook
so
that
we
can
so
I'm
using
a
service
to
basically
expose
my
so
that
the
github
can
send
a
payload
to
my
cluster,
I'm
using
docker
desktop.
Here
I
want
application
json
and
then
let's
not
worry
about
secret
right
now.
Yes,
so
this
is
my
web
hook.
A
A
A
So
here
yes,
it
says
that
a
few
seconds
ago
we
synced
and
we
have
the
application
running
now,
I'm
changing
the
application
to
make
it
change
the
version
to
zero
one.
And
yes,
we
made
those
changes.
Now,
let's
commit
and
push
those
changes,
updating
version
2201
so
get
push
to
master
again.
So
this
was
the
before
we
updated.
Now,
let's
see
whether
yes,
there
is
one
more
web
hook
and
which
was
created.
A
A
B
B
B
So
if
you
go
to
the
github
marketplace
and
search
for
tecton
you'll
find
tkn
github
action.
Tkn
is
detected
on
command
line
interface
to
prerequisites,
usage
and
version,
and
the
demo
of
the
arrow,
when
you
click
on
useless
version,
you'll
see
a
snippet
as
well
as
a
link
to
learn
more
in
the
repo
itself.
You'll
see
the
same
documentation
and
in
here
we
have
workflows
to
demonstrate
usage
and
you
can
see
that
we
are
validating
that
has
installed
the
expected
version
of
dkn.
So
let's
manually
trigger
this
and
see
what
happens.
B
B
B
Installing
tkn,
then
installing
the
catalog
resources
you're,
expecting
together
with
the
golan
run,
which
is
a
local
task.
You
can
see
there
the
description,
the
parameters,
the
workspace,
that
all
of
these
tasks
expect
are
logged
and
at
the
top
you
can
see
it
can
was
installed
by
joining
10
for
linux,
and
you
can
see
the
logs
for
setting
up,
protect
on
pipelines
itself
with
namespaces
and
all
other
resources
needed.
B
And
you
go
to
the
pipeline
run
logs,
you
see
clone
then.
As
expected,
you
can
see
the
sha
with
650,
which
is
the
sharp
big
change
that
we
just
made.
Then
cleaned
then
successfully,
and
you
can
see
testing
passed
with
the
coverage
literally
included
as
well.
You
can
see
building
then
successfully
and
run
should
be
printing,
hello,
silicon
which
we
have
there
at
the
end.
B
When
you
release
the
pipeline
drums,
you
can
see
the
piping
run
and
it
status.
Similarly,
when
you
describe
it,
you
can
see
all
the
task
trends
that
trend
under
that
pipeline
run
and
we
can
see
the
work
area,
the
volume
clean.
You
can
see
the
results,
which
is
the
share
of
the
chain
that
we
just
made
and
there
we
can
see
the
status
of
the
cds
passing
so
with
that
what's
coming
next
in
tactile.
B
First,
we
have
composability
and
usability
proposals
in
flight
right
now,
for
example,
pipelining
a
pod
pipelines
in
pipelines
remote
jesus
resolution.
Secondly,
we
have
failure
and
skipping
strategies
in
flight
as
well.
This
include:
ignore
safe
errors,
transplant
breakpoints
on
failure
of
a
step,
ignore
task
failures,
graceful
perpendicular
termination
and
skipping
strategies.
B
B
Thank
you.
We
put
some
questions
in
the
poll
if
you're
trying
to
take
a
look
and
answer
them,
and
it
seems
we
have
one
question
here
or
from
surgery-
it's
not
clear
to
me
what
parts
of
the
demo
done
by
texan
versus
argo
from
what
I
understand
a
goal
is
used
for
deployment.
Only
pretty
can
you
answer
that
yeah.
A
A
Right,
so
this
recording
was
done
quite
a
while
back
and
since
then
we
have
been
working
on
some
exciting
features.
We
have.
The
custom
task
was
recently
introduced,
maybe
a
few
months
back
and
we
have
the
sdk
being
designed
for
custom
tasks
so
basically
help
kind
of
instead
of
writing
the
whole
controller
by
yourself,
we
are
trying
to
come
up
with
sdk
which
can
help
in
so
we
don't
have
to
worry
about
all
the
logic
and
all
the
next.
A
We
have
is
techton
workflow,
which
was
recently
very
recently
discussed
in
the
working
group,
where
the
idea
is
basically
so
we
have
a
tucked
on
pipeline
and
trigger
their
two
separate
projects,
so
we
are
trying
to
bring
them
together
and
kind
of
like
we
have
argo
workflow,
the
other.
The
recent
a
couple
of
implementation
features
we
had
is
the
graceful
pipeline
run
termination,
which
is
basically
when
we
have
the
final
task.
A
B
Yeah
exactly
yeah,
I
think
some
of
the
things
that
you've
mentioned,
like
with
custom
tasks
sdk.
Actually
all
of
them
are
in
the
tips
that
I've
linked
there,
but
for
the
custom,
tasks
and
experimental
features,
there's
also
an
experimental
repo.
If
you'd
like
to
try
them
out
yourself,
there's
a
question
from
sergio:
how
do
you
see
tecton
being
used
in
large
organizations?
B
A
So
yeah,
no,
so
the
way
we
have
we,
we
dog
food,
our
own
thing,
so
we
basically,
we
have
dog
fooding,
checked
on
and
we
have
the
cluster.
So
whenever
there
is
somebody
creating
a
pull
request,
we
run
our
own
pipelines.
We
have
created
pipelines
which
is
running
integration.
Tests,
unit
test,
linting
go
coverage
a
lot
of
these
things
and
there
is
one
single
cluster
which
is
being
utilized
for
that
for
the
one
project.
B
A
B
A
It
so
basically
a
namespace.
You
are
kind
of
crossing
the
namespace
right.
I
don't
know
I
haven't
not.
I've
not
tried.
Actually
so,
but
it
depends
on
how
it's
configured.
If
you
have
the
pro,
we
have
these
privileges
right.
So
if
you
have
set
it
to
kind
of
access,
the
entire
namespace
or
whatever
across
the
namespace,
then
yes,
but
basically,
if
you
have
limited
the
access,
then
of
course
you
cannot
so
I
have
not
tried
it,
though.
This
is
interesting.
B
Yeah-
and
I
wanted
to
point
out
that
this
is
like
an
ongoing
discussion,
around
separation
of
concerns
between
teams,
like
platform
teams
versus
developer
teams
and
actually
there's
like
an
ongoing
thread
happening
right
now
in
the
tech
trend,
slack
regarding
separation
of
concerns
across
teams
and
how
we
want
to
represent
them
within
tecton.
Well,
like
possibly
like
one
team,
is
only
authorized
to
write
and
one
team
defines
the
policies
for
executing
the
pipelines
or
whatever
the
case.