►
From YouTube: What's New in GitLab CI/CD
Description
A quick overview of highlights from the last three months of CI/CD releases and a brief look at what's coming next.
Slides: https://docs.google.com/presentation/d/1T2coKqK2Ab53bnvIR0AWFfNsUj6sJMwch5kHXAA4iJ8/edit#slide=id.g59bfc474c5_2_145
A
Everyone,
my
name,
is
Jason
Yavana
and
I'm.
The
product
director
for
CI
CD
here
at
gala
I,
wanted
to
talk
a
little
bit
about
what's
new
for
CI
CD,
and
this
will
cover
the
12.5
fill
dot.
Six
and
twelve
s7
released,
which
were
the
last
three
months.
I'll
talk
a
little
bit
as
well
about
some
of
the
themes
that
we're
looking
at
and
then
some
of
the
highlighted
popular
items
that
we
delivered
over
this
period
and
then
very
briefly,
touch
on
what's
next.
A
So
the
themes
that
we're
working
on
in
the
CIC
D
area
are
the
following.
The
first
thing
I
should
mention,
though,
is
over
here
on
the
right.
You
can
see
the
scope
that
the
CI
CD
area
covers,
which
is
verifying
the
stage
that
covers
CI
pipelines
and
testing.
That's
integrated
in
the
CI
pipelines,
our
packaged
stage,
which
covers
the
container
registry
as
well
as
all
the
registries
for
things
like
nougat
may
have
been
and
p.m.
and
so
on,
and
the
release
stage,
which
is
all
about
continuous
delivery
and
release
management.
A
And
so
the
themes
that
we're
covering
here
and
we're
focused
on
in
this
year
are
speedy,
reliable
pipelines
so
improving
the
time
to
first
byte.
If
you
will
for
CI
pipelines
how
quickly
they're
starting
up
how
quickly
you
get
a
runner
all
of
those
sorts
of
things
that
make
just
using
CI
a
lot
nicer.
Multi-Platform
support
covers
things
like
adding
support
for
Fargate
and
Windows
and
Mac
runners
and
things
like
that.
That'll,
let
you
to
deploy
to
more
interesting
targets.
A
It
also
covers
things
like
ml
or
AI
pipelines
and
supporting
different
kinds
of
platforms
that
you
might
not
just
run
on,
but
that
you
might
target
progressive
delivery
is
a
is
a
whole
exciting
area
on
its
own.
That
means
two
takes
continuous
delivery
to
the
next
year.
There's
a
lot
of
technologies
coming
out
things
like
review,
apps,
more
advanced
controls
within
feature
flags
and
other
ways
to
segment
your
user
base.
So
during
a
deployment
you
can,
you
know
micro
target.
A
Essentially,
the
users
that
you
want
to
see
and
get
feedback
on
and
progressive
delivery
is
something
that's
emerging,
that's
kind
of
tying,
all
of
that
together,
single
application,
CI,
CD
and
so
I'm.
One
of
the
big
advantages
that
we
have
great
gitlab
is
that
we've
got
issue
tracking
we've
got
monitoring.
You've
got
security.
Scan
we've
got
all
these
other
things
that
are
part
of
single
application
that
we're
able
to
tie
together
in
CI
CD.
That's
a
big
focus
for
us
doing
powerful
things
easily.
A
One
of
the
huge
focuses
for
this
coming
year
is
the
onboarding
experience
and
making
it
easy
to
get
up
and
running
in
CI
CD
very
quickly
and
to
do
powerful
things
very
quickly.
So
if
speedy,
reliable
pipelines
is
the
time
to
your
first
byte
to
your
first,
you
know
execution
of
your
script
that
you've
written.
Then
this
would
be
kind
of
time
to
your
first
Greenbuild,
so
the
first
time
that
you're
trying
to
play
with
git
lab
or
your
that
you're
importing
any
project
into
it.
A
How
long
does
it
take
before
you
get
your
first
build
up
and
running
that
you
get
your
deployment
and
it's
all
green
and
everything
is
working.
That's
a
huge
focus
for
us
this
year
and
then
compliance
is
code
and
secure
secrets,
so
evidence
collection
doing
the
releases
which
we'll
talk
about
a
little
bit
more
and
making
compliance
governance
and
those
sorts
of
things.
Just
a
part
of
your
normal
workflow
is
another
big
advantage
that
we
can
have
because
of
the
single
application.
A
You
have
access
to
all
of
this
data
and
we
can
automatically
collect
it
for
you,
but
then
also
secure
secrets
is
an
interesting
area,
improving
the
the
way
the
secrets
are
managed
inside
of
get
lab,
our
own
secrets,
your
secrets
and
the
ones
that
are
used
as
part
of
CICE.
That's
all
part
of
our
vision,
there's
more
detail
a
ton
of
more
detail
on
this.
Of
course,
I'll
share
the
link
to
this
presentation
and
be
in
the
video
notes,
I
guess,
and
so
you
can
read
more
there.
You
can
also
read
our
complete
Direction
page.
A
A
This
starts
the
tired,
together
and
empower
our
releases
feature
to
have
access
to
more
data,
be
able
to
do
more
powerful
things
that
help
you
out
in
1205.
We
also
released
an
environment
dashboard
for
pipelines.
This
is
also
kind
of
targeting
that
more
traditional
style
of
release
management
that
we
want
to
improve
within
gitlab,
where
you
have,
instead
of
doing
continuous
delivery
to
a
production
environment.
A
You've
got
you
know,
a
series
of
environments
that
you
might
deploy
to
you
like:
a
a
test
environment
and
a
staged
environment,
a
UAT
environment
of
some
kind
and
then
production,
and
maybe
even
like
a
failover,
or
something
like
that.
So
those
kinds
of
clusters
of
environments
that
can
bridge
projects
and
and
and
deployments.
A
Then
we've
created
this
new
dashboard
that
lets
you
see
what's
the
plate
where
and
see,
if
it's
green
and
if
you're
working
in
those
kinds
of
environments
where
you've
got
a
bunch
of
environments,
that
you
interacted
a
basis
and
you
need
to
know
where
you
should
test
if
we're
ready
to
test
this
will
really
help
with
that
squash
and
murk.
Former
trains
is
another
really
really
great
feature.
So
having
squash
emerge
to
the
to
the
capabilities
is
a
nice
option
but
merge
strength.
A
Overall,
is
what
we're
really
seeing
that
as
a
game-changing
feature,
and
we
launched
that
into
both
auto
and
what
it
does.
Is
it
queues
up
all
of
your
merges
that
are
happening
across
your
project
and
builds
them
all
in
sequence,
off
of
cumulative
rests
that
are
assembled
based
on
the
contents
of
each
of
those
merchants.
A
A
A
We've
also
added
the
Kona
and
Packard
registry,
which
is
a
C
and
C++
package
manager.
It's
a
focus
for
us
to
continue
adding
as
many
of
these
as
possible.
You'll
probably
see
us
launching
Coenen
different
kinds
of
packaged
registries
in
in
most
releases,
going
forward,
we're
also
working
with
our
community
to
try
and
build
these
as
well,
so
that
we
can
go
even
faster.
A
But
this
is
just
such
a
useful
feature
where
you
can
store
your
packages
that
you're
building
and
get
lab
again,
yellow
pad
that
has
the
metadata
and
all
of
the
details
about
what
these
packages
contain,
who
built
them,
what
the
dependencies
were
and
everything
that
can
then
feed
into
the
continuous
delivery
part
of
the
application,
and
then
we
can
handle
those
dependencies
for
you.
This
is
all
part
of
the
ecosystem
of
building
stuff.
Forget
lab,
deploying
it,
and
you
know,
archiving
the
the
binaries
that
you
built
in
12,
X
7.
A
We
also
added
excuse
me
resource
groups,
so
we
heard
from
a
lot
of
our
customers
that
the
you
know
a
lot
of
times
for
a
lot
of
projects
you
can
deploy
concurrently
to
production
or
whatever
environment,
because
you're
deploying
different
things
and
they
don't
necessarily
step
on
each
other.
But
there
are
certain
kinds
of
environments
and
certain
kinds
of
situations
where
you
really
need
to
limit
concurrency
in
some
way.
A
So
we
have
resource
groups
now
which
can
be
defined
at
the
project
level
and
then
in
force,
so
that
only
one
deployment
to
that
environment
could
happen
at
a
time.
So
if
you've
got
a
physical
sort
of
environment,
that
could
only
do
one
kind
of
test
at
a
time.
You
can
constrain
that
if
you
want
to
limit
deployment
to
your
production
environment
to
be
happening
one
at
a
time,
you
can
configure
that
it's
based
on
a
custom
tag.
So
you
can,
you
know,
kind
of
configure
this
to
really
work
in
any
way
that
you
want.
A
It's
a
powerful
feature
that
we
were
very
happy
to
deliver
yeah
and
then
so.
The
build
data
collecting
that
inside
of
the
repository
data
I
sort
of
touched
on
this
earlier,
is
just
such
a
powerful
tool
for
troubleshooting
as
well.
So
we
did
some
user
research
where
we
were
talking
about
why
people
use
the
package
registry
and
something
that
I
wouldn't
say.
We
were
exactly
surprised
to
find,
but
was
interesting
to
confirm.
A
Another
super
super
exciting
one
that
had
been
in
the
works
for
a
little
bit.
Was
the
windows
shared
on
our
beta,
which
is
now
which
is
now
open?
If
anybody
wants
to
play
with
that,
but
you
can
get
windows
window
runners,
which
we've
supported
for
a
long
time,
but
you
can
now
get
them
in
the
shared
fleet.
So
even
if
you're
using
get
lab
comm,
you
don't
have
to
build
your
own
Windows
runtime.
You
can
just
go
grab
one
of
the
ones
that
we
have
and
that'll
be
available
to
you,
and
you
can
do.
A
Windows
builds
if
you're
interested
in
trying
this
out.
We
would
love
to
hear
your
feedback
it's
free
at
the
moment,
but
it
will
be
a
paid
feature
in
the
future.
We'll
also
be
looking
at
Mac
runners
once
this
is
up
and
running
parrot
our
pipelines
yeah.
So
this
is
a
great
one
where
there's
certain
use
cases
where
things
get
really
complex
in
your
configuration,
so
mono
repos
is
kind
of
a
prototypical
example
of
this,
but
anywhere
that
you've
got
a
very
long,
very
complicated
configuration
for
your
pipelines.
A
Child-Parent
pipelines
is
going
to
help
you
out
because
what
it
does
is,
let
you
take
out
the
part
of
your
pipeline.
That's
oriented
around
a
sub
part
of
your
project,
move
that
into
its
own
file
and
then
trigger
that
as
part
of
your
master
pipeline,
so
very
easy
to
think
about
this
in
terms
of
a
mono
repo,
where
you
got
you
know,
maybe
10
or
even
hundred
or
more
individual
projects
that
build.
You
can
still
set
up
your
master
Orchestrator
pipeline,
which
kind
of
keeps
track
of
all
these
things
the
dependencies
between
them.
A
But
it
also
will
let
you
move
the
configuration,
that's
specific
about
building
a
single
one
of
these
repos
or
not
repos,
but
a
project
into
you,
its
own
configuration
file
that
lives
with
that
project,
and
then
you
can
trigger
that
as
a
downstream
pipeline.
It
will
run
concurrently
and
then
you
can,
you
know,
move
on
and
and
run
your
pipelines
in
this
way.
One
thing
that
I'm
excited
to
touch
on-
and
it's
not
already
out
but
I
just
can't
resist
it-
is
that
we're
going
to
allow
for
dynamically
generating
these
configurations
in
the
future.
A
So
if
you're
doing
things
like
matrix
builds
where
you're
targeting
you
know
a
number
of
different
architecture
and
a
number
different
projects-
and
you
don't
want
to
write
your
configuration
to
contain
every
single
one
of
those
permutations,
then
you
can
use
parents,
child
pipelines
to
dynamically
generate
the
see.
I
am
well
that's
needed
on
the
fly
and
then
trigger
a
child
pipeline
based
on
that
configuration
which
will
make
that
so
much
easier,
so
much
simpler
and
help
make
the
configuration
for
your
get.
A
Let's
say
animals
very,
very
simple
and
then
lastly,
something
that
we've
been
working
on
for
some
time
and
are
continuing
to
work
on.
We
released
the
directed
acyclic
graph
in
12.2
and
have
been
really
seeing
improvements
to
it
ever
since,
and
will
continue
to
do
so.
The
directed
acyclic
graph
pipeline
view
that
we're
showing
here
that
is
a
little
bit
confusing
if
you're,
if
you're
not
familiar
with
it,
but
basically
what
the
dag
lets
you
do
is
run
a
pipeline
automatically
as
quickly
as
possible,
based
on
the
dependencies
that
are
defined
between
the
jobs.
A
So
if
you've
got
very,
very
complex
pipelines
or
if
you
just
want
to
let
get
lab,
handle
the
dependencies
for
you
instead
of
sequencing
things
out
in
stages,
which
is
the
traditional
way
of
doing
it,
you
can
just
in
your
gate,
lepsy.
I
ya'mo
define
the
relationships
between
the
jobs
and
say
this
job
needs
this
job.
This
job
needs
this
job
and
then
we
will
just
sort
it
out,
for
you
generate
one
of
these
directories,
the
graphs
which
you
can
see
on
the
screen
and
then
run
it
for
you
in
the
most
efficient
way
possible.
A
A
No,
you
can
just
use
the
tag
and
the
needs
keyword
and
we'll
do
that
for
you
and
it's
just
a
much
nicer
way
of
working,
simpler,
faster,
it's
a
win,
and
then
I
just
want
to
highlight
here,
amongst
all
of
the
things
that
we've
delivered
in
12.5,
12:06
and
12.7.
This
just
highlights
kind
of
our
user
focus.
We've.
A
It
is
our
priority
to
to
deliver
these
top
issues
and
and
make
the
product
better
by
working
with
our
customers,
and
that's
super
super
important
to
us
and
if,
if
you
are
interested
in
any
issues,
uploading
them
is
a
great
way
to
help
get
the
prioritized,
but
also
reaching
out
to
me
or
the
PM's,
for
the
area
is
another
great
way
to.
Let
us
know
that
something
is
important
to
you,
and,
and
we
can,
we
can
move
forward
on
it.
A
You
can
imagine
with
CI
and
some
other
areas
that
a
little
bit
more
sure
there's
a
ton
of
ton
of
things
going
on,
and
so
a
little
bit
of
a
nudge
is
always
welcome
and
appreciated,
and
then
that's
it
for
looking
back
looking
forward,
and-
and
this
is
none
of
this
is
complete
yet
so
it's
not
a
guarantee,
but
they
will
be
in
1208,
but
but
hopefully,
and
it
should
be
soon-
that's
all
buddy.
Some
of
the
highlights
that
I
want
to
touch
on
going
forward
are
the
one
that
I
already
touched
on
was
dynamic.
A
Child
pipeline
creation
via
artefact
concludes
we're
gonna
be
adding
also
accessibility
scanning
in
review.
Apps,
which
is
a
nice
way
that
we're
bridging
together
our
CI
pipes
and
pipelines,
and
our
review
apps
to
do
just
fully
automatic
accessibility
testing
for
you
and
be
able
to
give
you
those
results.
A
Adding
the
ability
to
trigger
a
pipeline
or
another
project
is
rebuilt
and
then
improving
the
expansiveness
of
the
code.
Any
report
on
the
package
side
we're
adding
the
nougat,
which
is
a
dotnet
focus
repository,
which
will
dovetail
nicely
with
the
improvements
we're
doing
for
Windows
users
overall,
but
especially
with
the
windows
shared
runners
on
the
release
side,
we're
adding
the
ability
to
collect
evidence
at
the
release,
end
date
and
then
beyond.
A
So
if
you're
doing
incremental
deployments,
we
will
help
enforce
that
those
only
move
forward
and
then
finally
group
deploy
tokens
which,
at
the
moment
we
have
project
level
deploy
tokens
group
deploy
tokens
will,
like
you,
set
up
configuration,
that's
a
little
bit
more
easy
to
manage.
If
you
have
a
lot
of
projects
in
a
single
group,
so
sort
of,
if
you're
doing
the
opposite
to
a
mono
repo,
where
you've
got
tons
of
them
projects
for
small
micro
services.
Summing
that
group
deploy
tokens
will
make
something
like
that
much
easier
to
manage.