►
From YouTube: Ship-It – Build & deploy your open source projects with Azure Pipelines - GitHub Universe 2018
Description
Presented by Jeremy Epling, Head of Product for Azure Pipelines, Principal Group Program Manager (Microsoft).
Azure Pipelines is Microsoft’s new fully-managed CI/CD service and it’s free for open source projects and supports any language or framework. In this demo-heavy session, you'll learn how to build your open source projects using Azure Pipeline’s Continuous Integration (CI) pipeline using our cloud-hosted Windows, Linux and Mac build agents. We’ll also explore how to deploy to Azure or any cloud using the same service.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
I'm
Jeremy
Epling
thanks
for
coming
I
know
it's
the
last
talk
of
the
day
at
the
end
of
the
conference,
so
take
some
willpower
till
I
get
up
and
get
in
here,
but
I've
got
some
exciting
stuff
to
talk
about.
Today.
We
just
recently
launched
a
new
service
called
Azure
pipelines
and
what
Azure
pipelines
is
all
about
is
a
sea
icd
service.
They
can
build
anything
from
an
open
source
project
to
a
really
complicated
multi
cloud
web
service
deployment
and
what
I'm
gonna
do
so.
Today's
talks
mainly
gonna,
be
a
lot
of
demos.
A
So,
starting
with
a
little
bit
about
me
so
I'm
a
product
manager
on
Azure
pipeline's,
one
of
the
other
things
I
work
on
is
actually
a
bunch
of
our
git
client
work.
So,
as
you
know,
Microsoft's
been
making
big
strides
in
open
source,
and
one
of
the
things
that
we've
been
doing
is
a
lot
of
work
into
the
courgette
codebase
to
make
sure
get
scales
to
really
large
repos.
We've
moved
windows
over
to
get
which
is
kind
of
like
a
huge
mind,
binned.
If
you
think
of
where
Microsoft
was
10
years
ago.
A
To
think
that
you
know
the
version
control
system
that
Linus
built
is
actually
what
we're
using
for
Windows.
So
we
do
work
there.
Other
stuff,
husband,
dad
rock
climber,
definitely
in
the
wannabe
artist
phase.
Now
one
of
the
funny
things
that
happen
recently,
though,
was
you'll
notice.
This
video
I'm
sure,
but
he's
wondering
like
what's
going
on
with
this
video,
so
one
of
the
things
was
I
was
at
home
a
couple
days
ago,
watching
the
kids
by
myself
and
I
was
looking
down.
A
You
know
take
a
drink,
get
on
my
phone,
maybe
spent
too
long
on
my
phone
and
I
look
down
to
my
daughter's
disappeared,
my
one-year-old
daughter
that
just
learned
how
to
walk
and
I'm
like
oh,
my
gosh,
where
is
she
so
I'm
like
running
into
the
kitchen
I'm
running
over
here,
trying
to
figure
out
like
running
all
around
the
house?
I'm
like
oh,
my
gosh
I
just
lose
my
daughter.
A
My
wife's
gonna
kill
me
when
she
comes
back
what
is
going
on
and
then
all
of
a
sudden
I
hear
some
like
giggling
from
the
kitchen
counter.
I
walk
over
the
kitchen
counter
and
I
see
this
little
thud
on
the
door
and
I
open
it
up
and
she's
decided
that
she
loves
to
hide
in
empty
cabinets
and
play
peekaboo.
So
when
my
wife
gets
home,
I
ask
her
and
I'm
just
like
hey
did
you
know
about
this
and
she
gives
me
this
like.
A
Why
are
we
doubling
smile
she's,
like
oh
I,
forgot
to
tell
you
that
I
was
like?
Oh,
that
was
cold,
so
my
dad
was
watching
kids
next
week.
So
obviously,
what
did
I
do?
I
didn't
tell
him
either,
so
this
is
a
little
video
of
her
playing
peek-a-boo
with
my
dad
that
I
just
got
yesterday
and
I
know
she
would
love
to
be
playing
peek-a-boo
with
all
of
you
now.
A
Like
me,
when
I
started,
my
career,
I
was
working
on.
W3C
working
groups
have
been
very
active
and
a
lot
of
open
source
projects,
mainly
kind
of
on
the
get
side
of
things,
and
it's
great
to
see
the
company
kind
of
move
and
contributing
even
directly
to
Linux
and
kubernetes
over
time.
One
of
our
next
steps
in
this
journey
is
actually
not
just
contributing
to
open
source
and
being
a
part
of
the
community,
but
actually
trying
to
give
back
in
a
more
holistic
way,
and
that's
one
of
the
things
that
we've
done
without
your
pipelines.
A
So
since
the
announcement,
one
of
the
big
things
that
we
did
was
we
decided
hey,
we
want
to
do
more
for
open
source
other
than
just
contributing.
We
wanna
have
a
really
generous
CI
CD
offer
for
all
open
source
repos.
So
what
we
offer
is
unlimited,
build
minutes,
unlimited,
build
minutes
for
any
open
source
project
out
there
and
you
get
10
parallel
jobs
across
Linux,
Mac,
OS
and
Windows.
A
So
this
is
great
if
you're
working
on
any
open
source
project-
and
you
want
to
make
sure
your
node
library,
your
Python
package,
anything
like
that-
builds
a
altitude
of
different
operating
systems.
You
can
easily
do
that
now
with
one
product
and
have
blazing
fast
builds
with
ten
parallel
jobs
and
then
also,
if
you're,
using
containers.
You
can
also
use
windows,
containers
or
Linux
containers
as
well.
A
So
you
have
your
choice
if
you
want
to
run
directly
on
the
VM
and
do
that
or
run
inside
a
container
and
just
in
the
last
month,
we've
seen
a
lot
of
great
adoption,
so
you
know
some
of
the
ones
you
probably
expect
like
dotnet
and
vs
code,
one
of
the
great
things
was
I
was
talking
to
one
of
the
engineers
from
Venus
code.
The
other
night
he's
like
I
just
want
to.
Let
you
know
we
actually
moved
your
product
cuz,
we
like
it
better.
We
didn't
feel
forced
to
go.
A
A
Gatsby
react,
UI,
pandas,
many
many
more
repos
and
we
have
more
moving
over
every
single
day
just
because
they
love
the
generous
offer
that
we're
giving
of
being
able
to
have
really
fast
CI
in
kind
of
one
CI
system
that
will
actually
scale
across
all
the
major
platforms
they
need
to
test
on,
and
then
one
of
the
other
things
is
a
lot
of
the
technology
that
we've
used
to
kind
of
create.
Azure
pipeline's
was
a
previous
service
that
we
have
kind
of
grown
up
with
a
new
UI
and
a
new
experience.
A
So
we
have
actually
a
lot
of
Microsoft
pretty
much.
Every
team
at
Microsoft
is
running
all
their
course,
the
ICD
through
Azure
pipelines
today,
and
we
actually
have
over
21
million
jobs.
We
run
every
single
month.
So
it's
all
of
Microsoft
is
kind
of
getting
powered
by
this.
So
we
have
the
scale
the
breadth,
as
well
as
the
kind
of
simplicity
that
you'll
see
in
a
second.
A
So
one
of
the
things
I'm
going
to
start
with
here
is
we're
actually
just
gonna
get
set
up
with
the
github
marketplace
app.
So
one
of
the
first
things
that
we
did
when
we
launched
was
create
a
marketplace
after
because
we
wanted
to
have
that
native
integration
directly
into
github,
so
I
can
go
through
here.
I
can
go
ahead
and
set
up
a
new
plan.
You'll
notice.
A
A
A
No,
it's
okay,
I
can
work
around
it.
Let's
actually
jump
right
over
to
this,
then
so
I'm
gonna
go
ahead
and
go
over
here.
I'll
go
through
the
getting
started
experience
in
a
second,
so
one
of
the
things
that
we'll
go
do
is
what
I
did
was
I
selected,
one
of
the
open
source
repos,
that's
moved
over
to
us
recently
and
just
kind
of
want
to
show
you
kind
of
how
they're
going
about
using
the
product.
So
one
of
things
you'll
notice.
This
is
parcel.
It's
one
of
the
top
repos
on
github
and
you'll
notice.
A
They
have
an
azure
pipeline's
yamo
file
just
directly
in
the
repository.
So
if
I
click
on
that
I
can
go
in
and
kind
of
see
how
they're
actually
using
us
today.
So
if
you
look
down
in
here,
you
can
see
that
they're
running
a
set
of
jobs,
as
you
would
imagine
and
they're,
taking
advantage
of
our
multi-platform
support,
so
they're
basically
running
a
template
I'll
get
to
that
in
a
second.
A
It's
basically
a
way
to
reuse
sections
of
your
gambols,
so
a
set
of
steps
or
a
set
of
jobs,
and
you
can
externalize
those
in
two
separate
files.
So
you
can
reuse
that
if
you
want
to
have
multiple
pipelines
for
a
single
repository,
so
they're
running
one
on
Mac
OS
and
that's
the
name
of
it,
they
pass
it
in
a
parameter.
A
A
So
what
you'll
see
when
you
open
up
this
template?
Is
you
start
to
see
some
of
the
power
of
what,
as
your
pipelines
can
do
it's
more
than
just
running
a
set
of
scripts?
What
I
can
go
through
here
and
do?
Is
you
can
see
hey
they're,
passing
in
through
the
template
that
parameter
so
letting
know?
What
is
this
job?
Is
it
gonna
run
on
which
VM
image
isn't
gonna
run
on
here?
So
it's
gonna
run
on
Mac
OS,
on
windows
on
Linux
and
then
what
they're
doing
is
on
top
of
having
three
jobs.
A
A
Then
down
here
you
can
see
the
set
of
steps
that
they're
running
so
right
here,
they're
just
setting
the
version
of
node
they're
going
down
here
and
doing
a
rust
install
one
of
the
other
features
that
we
have
here
that
you'll
notice
right
here
is
conditionals.
So
sometimes
in
your
build,
you
don't
want
to
run
everything
the
same
way
you
want
to
say:
hey
only
run
this
step.
A
If
something
has
succeeded,
sometimes
you
only
want
to
run
something
if
it's
a
pull
request
build
versus
a
CI
build,
especially
if
you're
dealing
with
security
or
you're
dealing
with
a
set
of
Secrets
a
lot
of
the
times.
If
a
build
comes
from
a
fork,
you
don't
want
to
be
giving
all
the
secrets
for
publishing
down
to
that
fork,
build
because
they
could
just
steal
those.
So
you
may
want
to
have
a
set
of
things
that
are
conditional
lized
in
your
build.
So
what
they're
doing
here
is
basically
saying
not
equal
to
Windows
so
hey.
A
This
is
something
we're
not
doing
on
Windows
and
then,
if
it
is
Windows
we're
gonna
run
a
slightly
different
script
and
then
a
lot
of
things
you
would
expect
if
you're
familiar
with
JavaScript
run
yarn
run.
My
tests
run
my
lens,
so
we're
gonna
go
over
here
and
what
does
this
actually
look
like?
So
we
can
go
over
to
one
of
their
commits
and
we
can
see
that
hey.
They
had
a
bill
that
ran
successfully
recently
go
over
here,
and
this
is
part
of
the
github
app
integration.
A
So
when
you
install
a
github
app,
one
of
the
things
that
you
get
is
aside
from
having
CI
set
up
for
you
pull
request,
set
up
for
you
and
sort
of
building
that
identity
mapping
between
the
two.
You
also
get
this
checks
experience,
that's
built
in
so
you'll
see,
checks
for
CI
builds,
and
this
is
the
github
feature.
You'll
see
it
for
a
pull
request
as
well,
so
I
can
go
ahead
and
see
this
successful
if
there
were
errors
or
warnings
or
I
wanted
to
dig
in
more
I.
A
Can
click
right
here
and
what
this
is
going
to
do
is
take
me
to
the
azure
pipelines
experience.
So
this
is
where
you
can
kind
of
dig
in
and
peel
that
next
layer
of
the
onion
to
understanding.
What's
going
on
with
my
builds
so
for
here
you
can
say:
hey
they
made
a
change
here
was
the
commit
that
was
in
the
change
they
built
it.
It
was
successful
if
I
wanted
to
go
dig
into
the
logs.
A
This
is
where
things
start
to
get
interesting,
so
you
can
see
how
that
yamo
file
was
kind
of
exploded
out
to
run
multiple
parallel
builds
so
every
single
time
they
have
a
push
of
a
new
commit
to
master.
It's
going
to
kick
off
every
single
one
of
these
builds
so
just
like.
We
talked
about
before
the
running
Mac
here
and
that's
matrix
thing
across
three
different
versions
of
node,
Linux
and
Windows,
again
they're,
taking
advantage
of
that
Fulton
parallel
jobs
immediately.
If
I
wanted
to
dig
in
so
we
need
the
logs.
A
I
can
click
over
here
and
you'll
notice.
I
can
see
all
the
logs
I
have
a
mini-map
over
here.
This
is
actually
using
Monaco,
which
is
the
core
editor
for
vs
code.
So
we
use
that
to
visualize
the
logs
and
from
there
you
can
perform
a
lot
of
other
Monaco
tasks.
I
can
go
ahead
and
find
I
can
bring
up
the
command
palette
for
a
limited
set
of
commands
there.
This
is
really
powerful,
especially
if
you're
a
larger
company
that
often
has
really
long
large
files.
A
A
One
of
the
other
interesting
things
that
we've
done
is:
if
you
go
over
to
web
pack,
you
can
see
some
more
of
the
functionality.
So
a
lot
of
the
times
you
just
don't
have
a
set
of
jobs
that
you
all
want
to
run
in
parallel
a
lot
of
times.
You
want
to
build
kind
of
a
graph,
a
dependency
graph,
so
sometimes
you
may
want
to
fan
out
and
fan
in.
We
make
that
very
simple
with
our
gamal
file.
A
So,
as
you
can
see
right
here,
I'm
over
in
the
webpack
repo
and
as
I
had
highlighted
a
second
ago,
let's
switch
that
over
to
this
one.
You
can
see
right
here
under
this
job,
there's
Linux
job
they're,
saying
hey,
it
depends
on
the
basic
job
and
the
Lindt
job
to
run
first
so
again,
up
above
here,
you'll
see
this
Lintz
job
and
then
this
basic
job,
both
of
those
must
complete
before
this
Linux
job,
is
kicked
off
and
then,
if
I
go
down,
I
also
have
Mac
OS
depending
on
them.
A
So
again,
you'd
see
those
two
jobs
run
in
parallel
and
then
it
kind
of
fans
out
again
to
all
those
you
can
also
do
fan
in
fan
out
any
sort
of
complex
graph.
I'll
show
a
couple
of
more
of
those
a
little
bit
later
in
the
demo,
but
you
can
build
these
complicated
graphs
that
are
as
complicated
as
kind
of
you
need
your
build
system
to
be,
but
it
offers
a
lot
of
flexibility
and
a
lot
of
power
to
the
system.
A
One
of
the
other
things
that
you'll
notice
is,
let's
jump
over
here
to
the
vs
code,
repo
one
of
the
things
I
talked
about
as
well
is
not
only
can
you
run
directly
on
a
VM
image
which
is
needed
for
a
lot
of
open
source
repositories,
but
you
can
also
run
what
we
call
container
jobs
that
are
similar
to
kind
of
VM
jobs.
So
what
you'll
notice
here
is
I
do
say:
there's
a
VM.
This
container
will
be
running
on
Ubuntu.
A
It
could
be
on
Windows,
because
Windows
supports
containers
as
well
with
Windows
Server
and
then
I
give
the
actual
container,
and
this
can
be
whatever
container
you
want.
You
can
bring
your
own
container
and
then
we're
gonna
run.
All
of
those
builds
steps
that
are
defined
in
this
case
they
externalize
those
into
a
template
file,
but
you
could
have
the
steps
right
there.
We're
gonna
run
those
inside
the
container.
So
this
is
a
great
way
to
get
reproducible
protect
a
predictable
builds.
A
Is
you
can
constrain
your
environment
more
instead
of
running
on
the
VM,
where
we
have
lots
of
tools
installed,
and
we
do
a
lot
of
work
to
make
sure
those
aren't
kind
of
clobbering
each
other,
but
you
can
build
a
container.
That's
just
a
minimal
thing
you
want.
Maybe
you
want
alpine
Debian
stretch
and
you
just
want
a
couple
dependencies
in
there
and
you
want
to
make
sure
that's
exactly
what
you
need.
You
can
go
ahead
and
specify
whatever
container
you
want,
we'll
pull
that
down
from
whatever
registry
and
run
your
build
inside
of
it.
A
Now,
let's
look
at
a
little
bit
more
of
a
complicated
build
process.
Maybe
amateur
build
process
even
better
word
for
that,
so
one
of
the
things
that
we
do
is
obviously
we
use
as
your
pipelines
to
build
as
your
pipelines.
So
this
is
actually
a
pull
request
build
of
our
product,
so
it
shows
off
a
little
bit
more
a
lot
of
the
open
source
repositories,
we'll
just
do
a
build.
A
They'll
run
a
set
of
tests,
we'll
see
if
it's
fine
and
kind
of
stop
there,
some
of
them
like
dotnet
or
some
of
the
more
mature
open-source
projects
are
very
advanced
in
what
they
go
use,
but
this
I,
like
is
you,
can
kind
of
see
the
full
gamut
of
things
and
you
can
see
how
we
use
our
own
product.
So
one
of
the
things
you'll
notice
is
this
was
a
PR
that
actually
just
went
in
a
few
days
ago.
You'll
notice
that
we
have
an
associates
that
have
changes
here.
A
A
Is
we
provide
artifact
storage
as
it
built
in
concept
into
Azure
pipeline,
so
you
don't
have
to
go
grab
an
s3
bucket,
manage
that
or
have
things
pushed
to
some
other
system
where
you're
not
sure
when
they're
gonna
delete
it
we
keep
it
around
and
for
companies
that
especially
have
compliance
requirements.
This
is
really
interesting
for
them
because
they
can
set
customized
retention
policies
on
those
artifacts
as
well,
so
I
can
say,
keep
it
around
for
X
number
of
days.
Keep
it
around
for
so
many
different
types
of
build
outputs.
A
So
you
have
a
lot
of
flexibility
in
what
you
can
go
do,
but
that
artifact
storage
is
just
built
directly
into
the
product,
along
with
controlling
retention
for
those
one
of
the
other.
Things
that
you
can
do
is
set
up
a
more
advanced
pipeline
that
doesn't
just
do
CI
or
CD
and
drop
some
artifacts.
It
actually
does
a
full
deployment.
So
one
of
the
things
that
you'll
notice
here
is
I
actually
did
a
full
deployment
to
multiple
different
environments
and
it
was
successful.
A
One
of
the
things
that
you'll
see
in
addition
to
this
is
we
are
this-
is
our
CI
build
so
over
here
is
a
pull
request.
Build
sorry,
I
misspoke
before
in
the
pull
request,
build
one
of
the
things
I
picked.
This
one
up
is
because
it
was
actually
a
failure,
so
it
shows
some
of
the
test
analysis
capabilities
that
we
have
in
the
product
as
well.
So,
as
you
can
imagine,
you
can
see
all
the
steps
in
the
build
we're
a
pretty
advanced
product.
We
have
a
lot
of
steps
there.
A
One
of
things
that
you
can
see
down
here
is:
if
we
immediately
pull
out
the
error
that
was
there.
If
I
want
to
go
see
what
the
areas
I
can
click
I
can
bring
up
the
logs
I
can
go
over
here,
jump
use
the
mini-map
go
find
out
where
the
air
is
kind
of
dig
in.
That's
fine,
it's
a
good
experience
to
go
dig
into
the
logs.
A
Does
a
pretty
good
job
with
testing
I
think
we
have
about
85,000
tests
that
run
on
every
single
pull
request,
and
you
can
go
ahead
and
see
what
the
failure
is.
You
can
see
the
past
percentage
see
how
long
they
take
by
default,
because
this
is
a
fail,
build
we've
filtered
this
down
just
to
the
failed,
builds
and
you'll
notice.
Both
of
these
are
kind
of
new
failures.
We've
actually
tagged
this
one
as
flaky
and
the
way
we
think
about
a
flaky
test.
Is
it
works?
Sometimes
it
doesn't
work
other
time.
A
So
maybe
I
want
to
dig
in
and
really
understand
why
I
have
this
flaky
test.
I
can
go
over
here.
I
can
see
the
error
message.
I
can
see
the
stack
trace,
but
again
this
is
just
let
me
to
this
PR
I
want
to
go
figure
out
like
when
did
this
problem
start
happening?
What
introduced
the
issue
so
I'm?
Actually
gonna
go
back
to
our
pull
request
pipeline,
and
this
is
you
can
see
this
little
star
here.
A
This
is
a
preview
feature
that
we
have
right
now,
I'm,
actually
going
to
run
analytics
on
this
you'll
see
hey
pass
rates
pretty
good,
but
let's
dig
in
a
little
bit
more
to
understand
what
test
failures
we've
been
having
across
this
entire
pipeline.
So
what
you'll
see
here
is
a
couple
things
that
we
have.
We
have
a
lot
of
tests.
It
takes
a
second
or
two
to
come
in
you'll,
see
our
pass
rate.
How
we're
doing
on
failing
tests?
You
can
see
the
result,
count
and
sort
of
see.
Where
is
the
dip?
It's
like.
A
Okay,
there
was
seriously
a
problem
here
with
the
tests
and
then
you
can
go
through
and
if
you
remember
from
a
second
ago
this
people,
picker
drop-down,
was
actually
the
one
that
we
were
looking
at
before
and
you
can
see
hey,
it's
passed
rate
has
not
been
doing
too
well,
it's
at
82%
and
then
I
can
see
that
it's
failed
731
times.
I
can
go
ahead
and
click
into
that
test
and
then
I
can
get
even
more
visibility
into
what's
going
on,
so
I
can
look
on
the
specific
days.
How
well
is
this
test
doing?
A
How
much
is
it
passing?
How
much
is
it
failing
and
obviously
something
seemed
to
happen
right
about
here?
This
test
started
to
fail
a
lot
recently.
So
again,
it's
really
about
trying
to
give
you
those
insights
that
you
need
to
diagnose
and
one
of
the
things
that
we
found
is
as
more
people
are
trying
to
move
to
kind
of
a
DevOps
workflow
as
you're
trying
to
get
see
icd
truly
integrated
into
your
process.
You
want
to
have
that
quality.
You
want
to
have
it
upstream
as
close
to
the
developer.
That's
writing
the
code.
A
You
need
to
have
a
great
item
in
a
test
suite,
but
it's
a
lot
of
work
to
get
a
great,
reliable,
automated
test
suite
and
the
main
thing
that
you
need
to
do
is
be
on
top
of
all
of
the
failures.
Have
somebody
that's
looking
on
it
figuring
out
what
it
is
and
helping
them
quickly
diagnose?
When
did
the
failure
happen?
Who
introduced
the
failure?
How
do
we
get
it
fixed
quickly
and
have
that
fast
turnaround
to
keep
that
productivity?
So
that's
what
this
test
analysis
feature
is
really
all
about.
A
Another
part
of
the
product,
though,
is
not
just
building
and
testing
and
publishing
up
artifacts
and
maybe
having
a
simple
deployment.
You
can
even
have
a
lot
more
complicated
deployments
here.
So,
if
you
look
at
this,
this
is
actually
us
deploy.
This
is
our
actual
product.
Eight,
the
on-prem
version
of
our
product
was
called
TFS
if
you've
heard
of
that
before.
So
this
is
an
actual
product.
A
Eight
I
think
from
three
days
ago
that
I'm
showing
and
you
can
see
kind
of
the
fan
out
fan
in
that
we
talked
about
before
kind
of
visualized
in
this
graph.
So
you
can
see
we
have
this
ring
zero.
These
are
our
kind
of
early
adopter
customers,
our
internal
teams.
They
go
off,
we
kick
all
of
those
off,
then
we
go
through
and
have
a
much
larger
graph,
where
we
kind
of
expand
out
to
different
stages
and
environments
kind
of
over
time,
as
we
roll
out
and
on
each
one
of
these
you'll
notice.
A
A
So,
let's
kind
of
look
at
a
smaller
pipeline
and
smaller
deployment
and
kind
of
look
at
what
that
is
so
I
think
if
this
demo
is
the
like,
we
integrate
with
everything
demo.
So
the
thing
that
I
love
about
this
one
is,
as
your
pipelines
really
isn't
just
about
as
your
stuff
right
like
we
don't
feel
like
it's
really
compelling.
If
all
we
can
talk
to
you
is
as
your
container
registry
and
deploy
to
Azure.
One
of
the
things
we
want
to
be
able
to
do
is
have
a
real
vibrant
ecosystem.
A
So
one
of
the
things
that
you
can
do
is
it
doesn't
matter
what
container
service
you're
using
what
package
service
that
you're
using
to
host
your
packages
where
your
artifacts
are
coming
from,
even
if
you
want
to
deploy
to
Google
cloud
or
AWS,
that's
all
possible
as
part
of
pipelines,
and
not
only
that
one
of
the
things
that
you'll
notice
is.
We
had
kind
of
two
artifacts
that
are
part
of
this
deployment.
What
this
one
down
here
actually
came
from
Azure
pipelines,
this
one
actually
came
from
Jenkins
one
of
things.
A
I
noticed
when
I
talked
to
a
lot
of
customers.
A
lot
of
them
have
Jenkins
for
their
CI
system.
That's
great
I'd
much!
Rather,
they
use
Azure
pipelines,
but
I
understand
what
it's
like
to
have
a
large
system
that
you're
currently
using,
but
one
of
the
things
that
we
do
really
well
is
we
can
pair
with
Jenkins
and
provide
that
more
advanced,
CD,
continuous
delivery,
side
of
things,
and
you
can
still
be
using
your
existing
Jenkins
builds
or
you
can
just
use
us
for
the
entire
pipeline,
so
it
allows
for
that.
A
Easy
onboarding
is
your
transitioning.
So
what
we
have
here
is
a
pretty
simple
build
that
has
two
stages.
This
one
is
actually
taking
these
artifacts.
One
of
them
is
deploying
them
to
AWS
on
Linux.
The
other
one
is
using
ansible
to
deploy
them
to
Azure.
So
let's
open
this
up
for
a
second,
when
I
click
on
one
of
these
stages,
I
can
actually
see
what
happened
in
the
deployment.
So
I
actually
know
the
exact
release
of
the
deployment.
I
can
go
ahead
and
see
what
triggered
it.
I
can
see.
A
The
specific
artifacts
I
can
go
overhead
and
click
on
these
links
and
jump
directly
to
the
Jenkins
artifact
there
a
lot
of
the
times.
What
I
want
to
figure
out
on
the
given
release
is
what
was
actually
in
that
release.
So
I
can
go
right
here.
I
can
click
on
this
commit
this
commit
could
be
on.
You
know,
github.
It
could
be
on
any
other
source
provider.
We
go
ahead
and
link
those
up.
So
again
you
get
that
traceability
across
all
the
different
aspects.
A
In
this
case,
I
also
have
work
items
hooked
up
and
I
have
these
hooked
up
over
to
JIRA.
So
if
I
click
over
here,
I
could
be
using
Azure
boards
or
I
could
just
be
using
JIRA
and
again
that
native
connection,
that
traceability
kind
of
happens
through
everything
and
then
I
can
jump
over
here
and
again.
I
can
see
that
hey
we
have
this
deployment
to
a
surewhat
commits
are
on
it
a
lot
of
the
times.
What
I'll
want
to
go
do
is,
let
me
jump
over
to
this.
A
This
is
kind
of
our
WYSIWYG
visual
experience
for
editing
the
pipeline,
so
what
I
can
go
through
here
is
if
I
want
to
go
ahead
and
add
another
stage,
I
can
go
through
and
click
the
Add
button.
We
have
a
set
of
templates
that
make
it
really
easy
to
start
with
different
types
of
deployments.
So,
hey
are
you
deploying
to
Azure
you
deploying
a
Python
or
you
deploy
into
kubernetes
and
you
can
go
through
and
we
have
a
lot
of
starter
templates.
A
We
actually
have
a
marketplace
of
hundreds
of
different
templates
and
tasks
that
people
have
provided
in.
One
of
the
other
things
that
you
can
go
do
is
exit
out
of
this
is
have
preconditions
and
postconditions.
So
a
lot
of
the
times
in
a
deployment
you
may
want
to
say:
hey
I,
want
this
specific
person
has
to
sign
off
before
it
goes
to
the
next
stage,
so
to
get
to
production.
Maybe
one
of
your
release,
managers
or
someone
has
to
go
sign
off
on
that
build.
A
So
what
we
have
is
a
way
to
kind
of
specify
win
those
triggers
what
they
are
you
can
set
up
scheduled
builds
again.
You
can
have
approvals,
so
I
can
go
through
here.
I
could
enable
approvals.
I
can
go
ahead
and
add
anyone
that
I
want
that
has
to
approve
of
this
I
can
give
a
certain
time
out
determine
if
it's
going
to
go
or
not
based
if
that
time
outs
met.
One
of
the
other
really
interesting
aspects
of
this
is
actually
gates
as
well.
A
So
one
of
the
things
that
I
can
do
is
set
up
a
set
of
gates.
So
in
this
case,
I've
set
up.
Servicenow
I
have
also
have
a
query,
that's
running
to
make
sure
there
are
no
bugs
assigned
to
this
release
and
those
run
on
certain
intervals
and
when
they're
all
passed
in
green
I
can
say:
okay
when
everything's
green
with
this
gate-
and
this
is
an
extensible
thing
that
anybody
can
add
to-
then
we
move
forward
to
that
next
stage.
A
So
it
again
allows
you
to
have
that
control
between
the
different
stages
of
your
pipeline.
I
can
go
over
here
and
you
can
see
we
have
a
number
of
different
built
in
gates
that
are
right
there
and
then
also.
Sometimes
you
want
to
have
pre
deployment
conditions
in
other
cases,
you
would
want
to
have
post
deployment
conditions,
so
you
can
go
up
and
set
up
a
similar
set
of
gates.
It's
the
same
types
of
gates
that
you
maybe
want
to
run
after
a
deployment.
Maybe
you're
fine
with
everybody
going
to
your
test
environment.
A
A
One
of
the
other
interesting
aspects
is
the
marketplace
that
we've
kind
of
built
around
this,
so
you'll
notice.
Here
we
have
a
visual
editor
as
well.
You
can
use
gamal,
but
in
this
case
all
the
artifacts
that
I'm
grabbing
from
this
were:
yes,
they
were
produced
with
Jenkins,
but
we're
grabbing
them
from
artifactory.
In
this
case,
I
was
doing
an
ansible
deployment,
but
one
of
the
things
we
have
is
a
marketplace
of
lots
of
different
tasks
to
help
you
get
started.
A
So
you
can
click
on
this
plus,
and
you
can
see
the
hundreds
of
different
tasks.
We
have
whether
or
not
I'm
doing
ants
I
can
build
mobile
apps
through
here,
whether
it
be
Android,
iOS,
artifactory
tasks,
mini
tasks
for
AWS.
If
you
want
to
do
deployments
to
AWS,
go
through
obviously
deployments
to
Azure,
she
would
expect
you
can
go
through
here.
We
have
deployments
for
kubernetes
kondeh,
almost
anything
that
you
can
think
of.
A
We
have
a
built-in
set
of
deployments,
and
then
we
have
a
rich
marketplace
as
well,
and
this
is
kind
of
pulling
in
these
marketplace
tasks
right
here
and
you
can
just
click.
Add.
Add
those
tasks
over
into
your
pipeline
and
immediately
get
started
using
them
and
whenever
you
add
a
task,
you
can
also
lock
it
to
a
specific
version.
One
of
the
things
we've
noticed
for
people
is,
you
know
a
task
author.
You
may
not
want
to
always
be
taking
their
latest.
A
Right
so
we
walked
through
a
couple
different
things
here.
So
when
you
think
about
as
your
pipelines,
one
of
our
core
value
props
is
really
about
being
able
to
build
any
language
any
platform,
any
cloud
and
that's
kind
of
poor
part
and
parcel
to
being
really.
What
we
want
to
be
is
the
best
open
source,
CI
CD
provider,
so
that
any
open
source
repo
can
go
over
start
building
the
product
have
a
simple
experience.
With
a
single
pipeline.
You
can
use
yamo,
you
can
use
a
visual
editor.
A
You
can
go
through
and
have
a
really
powerful
experience
and
making
sure
you're
testing
on
all
the
core
platforms.
You
know,
I
talked
about
Mac,
Linux
and
Windows
this
month.
We're
also
releasing
support
for
arm.
This
won't
be
in
our
hosted
cloud,
but
our
private
agents
that
you
can
run
on
your
own,
we'll
have
arm
support
and
we'll
also
have
32-bit
support
and
those
are
actually
driven
from
direct
request.
We've
had
from
open
source
repos
as
we've
been
going
out
and
talking
to
different
teams,
especially
a
lot
of
the
lower-level
components.
A
They're
saying
hey,
this
is
really
great,
but
I.
Really,
if
I
want
to
have
this
vision
of
one
pipeline
to
run,
everything
I
need
to
be
able
to
do
more
than
just
the
classic
kind
of
client
and
server
operating
systems.
I
need
to
be
able
to
beyond
IOT
I
need
to
be
able
beyond
armed
devices.
I
need
to
even
be
able
to
run
on
32-bit
hardware,
not
just
like
build
32-bit,
but
actually
running
on
a
real
32-bit
hardware.
So
that's
something
that
we're
adding
today
for
our
private
agents.
A
One
of
the
other
things
is
really
this
flexible,
workflows,
environment,
see
sort
of
kind
of
sauce
go
through
the
extensibility
and
community
that
we've
built
there
and
then
the
third
point
on
there
is
really
around
containers
and
kubernetes.
So
one
of
the
things
that
we
want
to
make
sure
is
like
there's
an
obvious
trend,
especially
if
you're
using
web
services,
maybe
not
if
you're
doing
packages
some
people
are
building
those
and
containers.
Some
people
aren't
a
lot
of
times.
A
You
need
to
make
sure
those
run
on
different
clients,
but
we
have
native
kind
of
built-in
support
through
tasks
for
kubernetes,
so
that
you
can
go
through
all
the
gates
that
I
showed
before
those
will
work
for
a
kubernetes
cluster.
You
can
set
up
a
certain
set
of
gates
there,
and
then
you
can
have
a
set
of
containers
they
kind
of
get
orchestrated
through
your
entire
pipeline.
So
again
you
can
run
your
code
inside
one
container
for
the
entire
job
and
then
very
soon
we're
going
to
be
introducing
container
steps.
A
A
So
that's
everything
I'll
be
up
here
for
a
few
questions.
If
anybody
has
anything
and
thank
you
so
much
if
you
go
up
to
the
second
floor,
upstairs
we
have
a
great
getting
started.
Experience
sorry
hit
that
odd
demo
bug
here,
but
one
of
the
things
you
can
go
up
and
we
can
go
ahead
and
get
you
started.
We
have
plenty
of
people
up
on
the
booth.
I'll
be
up.
There
be
happy
to
answer
questions
here
or
also
afterward
upstairs,
and
we
can
show
you
how
to
get
started.