►
Description
Building and deploying applications can involve a lot of configuration data. After getting a feel for the GitLab’s advanced features for layering and converging this data are discussed.
Companion working example project: Complex Config Data Monorepo - https://gitlab.com/guided-explorations/config-data-top-scope/config-data-subscope/config-data-monorepo
If you find this helpful, please give the video a thumbs up and "star" the project :)
Join Darwin (DarwinJS) in visiting a bunch of GitLab features that enable complex configuration data management in GitLab.
Playlists:
- Guided Explorations (https://youtube.com/playlist?list=PL05JrBw4t0KruBVtI-Ynb3mCHQTkh2eBY)
- CI/CD Tips Tricks and Hacks (https://youtube.com/playlist?list=PL05JrBw4t0Kr92rF9z0PEuOtQnH89VD7n)
- DarwinTheorizes (https://youtube.com/playlist?list=PL05JrBw4t0KoH74CcAtP0Ze7JXjX7zT6g)
A
Hello:
everyone,
my
name
is
Darwin
Senoia
I'm,
a
senior
solutions
architect
for
gitlab.
Today,
I
want
to
talk
to
you
about
managing
the
complex
configuration
data
management
monster
with
git
lab
and,
if
you
think,
that's
a
mouthful
just
wait
till
we
get
into
the
details.
First
of
all,
we
want
to
talk
through
configuration
data
best
practices.
These
are
the
practices
that
have
evolved
in
our
industry
to
try
to
get
a
handle
on
this
problem.
Then
we'll
talked
about
config
data's,
wicked
problem.
Basically,
there's
no
limit
to
the
dimensions
that
you
might
need
to
accommodate.
A
Well
get
into
that
a
little
bit
and
help
you
understand
how
this
is
a
tough
problem,
no
matter
what
tooling
you
apply
to
it,
then
we'll
talk
about
providers
and
consumers.
What
are
some
of
the
subsystems
of
automation
that
use
this
data
and
might
also
store
this
data,
then
we'll
get
into
get
labs.
Config
data
features
specifically
with
two
major
breakdowns:
we'll
also
talk
about
get
lab,
config
data
convergence
features.
A
So
when
we
bring
that
configure
it
data
down
to
make
it
into
one
set
of
config
data
to
target
an
environment,
how
does
that
exactly
work?
We'll
also
talk
about
git
lab
development
patterns
for
continuous
deployment,
so
there's
several
different
ways
in
which
you
can
configure
get
lab
repositories
and
groups
to
accomplish
a
nice,
clean
separation
and
the
kind
of
controls
that
you
want
to
put
in
place.
A
Finally,
the
concept
of
git
Ops
is
bringing
a
new
idea
to
the
fore,
which
is
that
git
would
be
the
single
source
of
truth
for
both
code
and
config.
So
both
these
elements
as
much
as
possible
are
stored
inside
of
git.
So
these
are
some
of
the
best
practices
that
we
will
indeed
be
talking
about
as
we
go
through
this
information.
A
So
let's
talk
a
little
bit
about
how
configuration
management
data
presents
to
us.
In
this
example,
we
have
four
environments
across
the
top
and
we
have
three
different
data
values
down
the
left
side.
Each
of
these
environments
may
or
may
not
need
a
different
value
depending
on
what
that
environment
is
configured
to
do,
and
so
you
can
see
that
this
is
a
very
common
issue
in
a
very
common
problem.
One
of
the
challenges
is,
we
might
have
additional
dimensions
to
this
data.
A
So
in
this
case,
if
we
add
customer,
we
might
end
up
with
it
three
dimensions
of
the
same
data
layout.
There
are
the
possible
dimensions.
Datacenter,
geolocation
country,
location
and
regulated
versus
non
regulate
environments
are
just
a
few.
There
are
many
others
that
this
might
affect.
It's
also
important
to
know
that
it
affects
both
application
and
infrastructure
configuration.
So
some
of
this
data
may
be
bound
to
the
build
process
and
get
tied
right
up
inside
of
your
application.
Artifacts
other
parts
of
it
may
be
pushed
along
with
your
application
to
configure
it.
A
The
big
wicked
problem
here
with
configuration
management
data
is
that
there's
no
real
practical
limitation
to
how
many
dimensions
might
come
into
play
for
your
given
scenario.
In
this
example,
we've
added
two
more
dimensions:
data
center,
geolocation
and
customer
country.
Now
it's
always
important
to
design
to
be
as
simple
as
possible,
but
you
can
see
here
sometimes
we're
forced
into
a
more
complex
model.
A
Let's
just
give
a
quick
example
of
converging
data
for
something
like
a
payment
gateway
across
multiple
environments.
In
this
table
we
have
a
result:
column,
that's
showing,
depending
on
what's
going
on
with
our
environment,
we
might
have
different
rules.
So
in
our
development
environment
we
just
have
one
payment
gateway,
endpoint.
In
our
stage
environment,
we
start
to
break
it
out
by
additional
concerns
and,
finally,
in
our
pradhan
vironment,
we
have
to
break
it
out
by
all
three
of
these
intervening
concerns.
A
So
let's
talk
a
little
bit
about
the
configuration
data
providers
and
consumers,
so
there's
a
variety
of
products
in
about
five
categories
that
all
work
to
try
to
store
this
data,
for
you
manage
it
or
to
be
driven
by
it.
Let's
take
a
look
at
these
categories,
so,
of
course
we
have
continuous
integration,
compiling
building
and
testing
your
code.
We
also
have
configuration,
is
code
products
like
ansible
chef
and
puppet.
Our
configuration
is
code.
They
have
capability
to
store
this
data
and
also
capability
driven
by
such
data.
A
We
also
have
infrastructure
as
code
and
application
config
and
service
mesh,
so
we
have
things
like
console
key
value
pair
store
that
is
typically
used
to
configure
micro
services
applications
and
we
have
a
bunch
of
other
technologies
in
this
space
that
allow
us
to
have
dynamic
configuration
of
our
application.
We
may
need
to
push
this
data
into
such
environments,
or
these
environments
can
also
have
the
capability
to
store
it
themselves
and
finally,
continuous
deployment.
A
This
is
another
big
area
where
this
data
comes
into
play
because
we
have
to
have
runtime
assemble
a
lot
of
environment
information
in
order
to
successfully
deploy
an
application
into
a
given
environment,
as
we
mentioned
before.
Each
of
these
may
store
data.
You
may
have
it
as
one
of
your
primary
data
stores
and
have
to
push
it
out
to
other
data
stores,
or
it
may
be
able
to
receive
data
and
be
driven
by
it.
A
So,
regardless
of
whether
you
need
to
get
lab
to
drive
one
of
these
products
or
product
categories
integrate
with
one
of
these
or
to
replace
one
of
these,
it's
going
to
be
critical
to
understand
how
git
lab
itself
can
do
complex
configuration
data.
So,
let's
take
a
look
at
some
of
the
flexibility
and
constructs
that
we
can
use
to
manage
this
data
for
the
first
example
of
how
git
lab
can
help
you
manage
this
data.
A
We're
gonna
take
a
look
at
Group,
C
ICD
variables,
so
you
may
have
seen
C
ICD
variables
in
repositories,
but
you
may
or
may
not
have
noticed
you
can
also
set
them
in
groups.
So
in
this
structure,
we're
going
to
establish
some
hierarchical
groups,
dog-walking
app
is
the
top
of
the
hierarchy.
Payment
services
under
that
and
european
continent
is
under
that.
In
addition,
we'll
have
a
couple
repositories
that
are
disposition
toward
countries
and,
as
we
walk
through
the
top-level
variables,
are
able
to
be
overwritten
by
layers
that
are
closer
to
the
repository.
A
So
as
we
go
through
here.
Just
keep
that
in
mind.
Unfortunately,
our
variable
names
will
not
be
as
exciting
as
our
group
names
here,
because
it
would
simply
not
fit
on
one
screen.
So
if
we
have
a
value
called
s1
and
it's
set
to
a
at
the
top
level,
if
we
don't
have
no
other
intervening
overrides,
that
is
how
the
repositories
would
register
and
use
that
variable.
If
we
have
as
two
equals
to
a
at
the
top
level,
but
have
an
override
at
the
payment
service
level,
then
both
repositories
would
see
s
two
equals
B.
A
In
this
case.
We're
also
going
to
show
you,
though,
an
individual
repository
overriding,
so
our
overrides
can
really
exist
at
any
place
and
they
don't
have
to
be
specifically
at
every
layer
that
is
available.
If
we
had
s,
3
equals
to
a
in
the
top
level
again
and
set
it
at
B
in
the
payment
service
level
C
in
the
level
of
the
European
continent,
then
it
will
be
seen
that
way
in
both
of
our
repositories.
A
Finally,
we
don't
have
to
put
the
variables
at
the
top
level
and
then
override
them.
We
can
really
just
populate
them
anywhere
and
they'll
flow
down,
as
you
would
expect,
and
we
can
even
put
them
at
lower
levels
and
finally,
we
can
put
them
right
in
repositories
as
well.
Now,
in
this
case,
we
technically
have
a
four
layer
hierarchy,
because
the
repositories
themselves
can
also
contain
C
ICD
variables,
so
this
is
technically
a
four
layer
hierarchy.
A
Another
thing
to
keep
in
mind
is
that,
although
we
have
a
group
structure
here
that
just
has
three
groups
in
a
subgroup
structure,
we
can't
have
groups
of
structures
of
any
types.
In
addition,
we
don't
have
to
put
repositories
only
at
the
bottom.
Once
again,
you
probably
would
want
to
put
repositories
only
at
the
bottom,
if
you
can
make
it
work
that
way,
because
you
want
to
keep
it
as
simple
as
possible.
A
So
this
is
an
example
of
how
git
lab
can
use
group
variables
to
start
creating
some
very
interested
and
sophisticated
ways
of
dealing
with
this
data,
depending
on
the
Scopes
that
we
have
to
account
for
given
the
data,
so
I
am
in
a
guided
explorations
group
within
get
lab.
This
is
a
public
group
that
you
can
actually
go
out
and
observe
as
well.
A
You
will
not
have
maintainer
permissions,
so
you
will
not
be
able
to
see
some
of
the
things
we'll
look
at,
but
there
is
a
document
in
here
guiding
you
how
to
reproduce
this
example
in
your
own
group,
or
instance.
So
here
at
our
top-level
scope,
we're
going
to
go
into
this
group
and
within
settings
we
find
we
have
CI
CD
settings
and
within
that
we
have
variables.
So
here
are
three
variables
we're
setting
at
the
top-level
scope.
A
Our
final
scope
level
will
be
the
repository
level
and,
of
course,
you're
probably
familiar
with
doing
C
ICD
variables
in
your
repository
when
we
look
at
this
list,
we're
just
going
to
ignore
anything
that
doesn't
have
the
word
scope
in
the
variable
name,
because
we'll
be
focusing
on
the
other
ones
in
just
a
minute.
So
you
can
see
here
we
have
a
repo
scope
level.
We
have
overridden
the
sub
scope
level
for
one
particular
value
and
we've
overridden
the
top
scope
level
for
two
values
at
this
level.
A
So
this
shows
us
that
these
data
values
are
traversing
down
the
hierarchy.
We
can
also
look
here
and
see
where
our
inherited
variables
are
coming
from.
What
group
levels
are
coming
from
doesn't
show
us
the
values
that
those
levels
we'd
have
to
go
back
to
those
levels
to
check.
Now,
let's
look
at
a
completed
job
in
the
pipeline
to
see
how
these
variables
resolve
for
a
given
circumstance.
So
I'm
going
to
go
into
this
last
job
that
passed
and
we'll
take
a
look
at
show
group
variables.
A
A
So
that
is
the
concept
of
using
group
variables
or
group
CI
CD
variables
in
order
to
create
a
stack
of
variables
that
are
inherited
and
overridden.
As
we
get
closer
and
closer
to
the
repository
that
we
are
dealing
with
now,
I'm
going
to
talk
about
something
called
environment,
scoping
of
variables-
and
this
happens
within
a
repository.
So
within
a
repository
we
can
actually
create
a
scope
for
our
variables
a
lot
of
times.
It's
easy
to
miss
if
you
simply
gone
in
there
and
created
variables
that
apply
to
the
entire
repository.
A
But
there
is
a
scoping
parameter
over
on
the
right
side
when
you're
creating
these
variables
that
we'll
look
at
shortly.
That
scoping
parameter
allows
us
to
say
what
scopes
of
environments
that
we
will
target.
Now
in
the
same
repository,
we
are
going
to
say
that
we're
going
to
use
our
environments
mapped
to
branches
and
by
mapping
environments
to
branches.
A
We
are
able
to
get
the
most
of
the
controls
that
are
available
in
git
lab
to
control
deployments
to
environments,
because
we
can
have
merge
requests
over
our
actual
deployments
and
we'll
talk
a
little
bit
about
that
later
as
well.
But
within
this
repository,
we're
gonna
say
that
we
have
three
different
branches.
These
branches
are
what
are
going
to
deploy
to
our
various
environments.
A
Within
the
repository,
every
repository
has
an
all
environment
scope.
It's
the
default
one
and
any
variables
you
create
will
always
be
created
in
this
scope.
We're
going
to
create
a
couple
other
scopes
as
well
to
demonstrate
how
the
resolution
will
work.
So
here
we
have
one
scope:
expression
of
s,
star
notice,
that
these
are
actually
scope,
expressions,
not
just
named
environments,
and
so
the
s
star,
scope
expression
will
target
both
our
stage
one
and
stage
two
branch.
A
Then
we
have
a
specific
one
for
Stage
one
and
a
specific
one
for
production,
just
like
our
groups
that
our
variables
will
resolve
down
and
whatever's
closest
to
the
repository
will
have
a
higher
precedence,
because
it's
more
specific,
so
any
variable
we
set
at
the
top
of
this
as
it
goes
down.
If
it's
overridden
at
lower
levels,
then
that
override
level
is
what
we'll
take
as
far
as
the
values
go.
So
let's
say
Z
equals
one
at
our
top
level.
A
Then
if
we
have
no
intervening
overrides
at
any
other
level,
although
we've
branches
would
see
it
as
that
value.
If
we
have
Z
two
equals
one
at
our
top
level
and
an
override
at
the
scope
expression
s
star,
then
these
two
repositories
are
gonna,
see
it
as
set
as
to
our
progress,
will
set.
It
still
see
it
as
set
as
one
because
there's
no
override
for
it.
Z
three
equals
one,
then,
at
the
scope,
expression
level
we
override
and
again
in
the
stage
one
level
so
for
Stage
one.
A
This
will
be
set
to
three
and
at
stage
two
it'll
be
set
to
two.
In
this
example,
we're
gonna
say
that
we
override
z3
in
production
as
well
and
so
it'll
end
up
equaling
nine
for
our
production
branch.
Finally,
just
to
reassert
the
idea
that
we
do
not
need
to
create
the
variables
at
the
top
expression
are
at
this
two
hop
scope
all
the
time
and
then
override
them.
We
can
actually
create
them
arbitrarily
within
any
scope
and
they'll
flow
down.
Keep
in
mind
we're
talking
here
about
mapping
environments
to
branches.
A
You
can
actually
map
environments
to
any
data
value
that
you
can
source,
including
just
a
data
value
you
collect
during
the
actual
execution
or
in
a
variable
that
you
push
into
the
system
so
we're
doing
it
here
by
branch,
but
it
can
be
mapped
by
most
anything.
So,
let's
take
a
look
at
what
this
looks
like
inside
of
git
lab.
A
We
are
at
our
repository
level
here,
so
we're
going
to
go
into
our
CI
CD
variables
and
now
we're
going
to
pay
attention
to
all
the
variables
that
do
not
have
scope
in
their
name
and
these
values
have
a
variety
of
scope.
Differences
over
here
on
the
right.
So
you
can
see
all
the
ones
that
came
down
from
the
groups:
I'll
have
all
environments,
and
then
we
have
this
global,
visible
bar
that
is
set
to
visible
data
and
applies
to
all
environments.
A
So
we
should
see
that,
no
matter
what
branch
we
build,
we
have
this
multi
environment
variable
for
s,
star
environments,
that
is
set
to
a
specific
value,
and
then
we
have
this
password
value.
That's
repeated
three
times
because
it's
different
for
all
three
scopes,
and
so
you
can
see
how
that
would
be
valuable
for
data
or
authentication
details
that
are
different
per
scoop,
and
then
we
also
have
some
visible
environment
variables
down
here
that
are
different,
Prescott,
so
visible
environment
data
parameter
will
be
different
in
each
particular
branch.
A
Once
again,
we'll
take
a
look
at
how
this
built.
So
in
our
pipelines,
we
will
find
that
when
we
take
a
look
at
the
scoped
variables,
the
data
resolves
as
we
would
expect
according
to
what
is
in
the
various
scopes.
Just
a
note,
we
also
grabbed
a
variable
from
a
file.
We
did
this
inside
of
our
build
script
and
that
build
script
is
what
is
grabbing
that
data.
So
if
you
really
want
to
have
a
lot
of
data,
that's
actually
just
writing
a
repository.
A
Let's
just
take
a
look
also,
though,
at
a
built
artifact,
so
we've
emulated
kind
of
a
fake
artifact
here,
we'll
open
on
one
go
into
our
job,
one
plug
plug
in
one
and
over
here
we
can
browse
our
artifacts
and
this
would
be
a
properties
file
potentially
for
Java.
It's
not
properly
formatted,
because
it's
just
designed
to
show
you
how
that
data
would
flow
down.
So
that
is
an
example
of
a
built
artifact
using
the
same
data
that
we
have
been
talking
about.
A
So
that's
how
we
work
with
environment
scopes
within
get
lab
and
they
can
add
a
lot
of
flexibility
now
both
environment
scopes
as
well
as
group
C
ICD
variables,
are
two
different
approaches
to
kind
of
the
same
problem
set.
However,
there's
nothing
stopping
you
from
combining
them
together.
If
you
have
complicated
scenarios
that
require
even
more
flexibility,
keep
in
mind,
we
always
advise
you
design
everything
to
be
as
simple
as
possible,
but
of
course
you
can't
design
it
to
be
simpler
than
necessary.
A
So
it's
important
to
design
as
simple
as
possible,
but
we
want
to
show
you
the
full
flexibility
you
have.
So
you
know
what
tools
you
have
in
your
toolbox
in
order
to
attack
this
challenge,
I
want
to
go
through
some
scenarios
now
of
how
you
might
configure
gitlab
for
deployment,
because
if
you
use
multiple
repositories
or
multiple
branches
or
other
mechanisms,
then
these
variables
capabilities
also
are
in
play
and
you
can
use
them
in
combination
with
a
given
scenario.
A
So
in
this
scenario,
we're
gonna
talk
about
both
deploying
two
environments,
using
branches
which
was
kind
of
the
assumption
of
the
last
set
of
data
that
we
look
through.
So
here
we
have
a
typical
code,
collaboration
workflow,
where
features
come
in
on
branches
and
they
are
integrated
in
into
a
branch
where
the
validation,
human
moderation
of
the
code
and
review
of
the
code,
as
well
as
build
validation
and
potentially
the
deployment
to
a
review
environment
is
done,
and
so
this
is
kind
of
our
build
and
test
phase
and
then
within
get
lab.
A
We
also
have
the
ability
to
use
branches
to
deploy
to
environments,
and
so
this
is
an
example
of
deploying
two
successive
environments
for
the
same
applications.
So
as
it's
being
promoted
through
its
environments,
it
travels
from
branch
to
branch
using
merge,
requests
now
I'm
just
going
to
briefly
cover
some
information
we
covered
in
a
previous
webinar,
which
was
on
some
of
the
rich
change
controls
we
haven't
get
lab
I
want
to
just
briefly
touch
on
it,
because
it's
important,
if
you're
thinking
about
these
variables,
to
also
understand
where
your
change
controls
are
in
this
process.
A
I'm
just
going
to
cover
it
once
here,
but
at
the
end
we
have
a
link
to
a
webinar
that
tells
you
the
full
details
on
this
concept
of
rich
change.
Controls
for
building
workflows
that
you
can
trust
and
get
lab
one
of
the
change
controls
that
we
have
here.
Our
merger
quests,
it's
the
richest
one,
and
it
is
the
one
that
if
we
do
deployments
using
branches,
we
get
the
most
capability
to
control.
A
You
can
see
here
some
of
the
features
these
markers,
SB
and
PS
are
indicating
the
git
lab
Edition
that
is
required
to
have
that
feature.
S
is
for
starter,
P
is
for
premium,
and
then
we
also
have
the
protected
branches
capability
and
protected
branches
have
a
variety
of
features
that
depend
on
a
variety
of
git
lab
editions.
But
those
features
allow
us
to
say
that
a
branch
cannot
be
merged
unless
certain
requirements
are
met,
and
so
we
have
another
set
of
controls.
A
I
should
note
that
all
of
these
controls
support
custom
groups
in
one
way
or
another,
so
you
can
make
a
group
of
users
in
git
lab
that
is
only
group
for
users
and
then
use
those
groups
in
these
various
areas.
The
rich
change
controls,
webinar
talks
about
custom
groups
and
how
they're
made
as
well
here's
another
scenario
where
we
are
going
to
have
it
build
pipeline.
A
It
might
have
several
branches,
but
at
the
end
of
the
day,
our
multiple
environment,
targeting
happens
by
redeploying
the
deploy
phase,
and
typically
we
would
change
some
variables
so
that
we
can
deploy
to
different
environments.
We
might
even
be
able
to
deploy
different
versions
to
different
environments
through
the
same
mechanism.
This
mechanism
is
convenient.
It
does
not
have
as
many
controls
as
you
can
see.
You
only
have
the
one
gate
available
to
you.
A
A
Maybe
we
have
customer
tenants
and
those
customers
have
a
test
area,
a
staging
area
and
a
prod
area
that
they're
able
to
play
with
the
application
to
ensure
maybe
it
works
with
their
custom
integrations
or
whatever
else
this
scenario
might
be,
and
so
this
is
another
pattern
that
you
can
implement
and
get
lab.
So
the
variables
that
we
talked
about
can
work
over
top
of
these
in
any
configuration
that
makes
sense
for
you.
A
Couple
other
points
of
data
on
this
particular
table.
We
have
talked
about
configuration
data
as
build
data,
so
it's
used
for
us
to
build
our
actual
artifacts.
We've
also
used
talked
about
it
for
application
deployment
data,
so
we
might
be
configuring
the
environment
or
configuring,
the
application
externally
through
files,
but
there's
a
couple
other
places
that
it
can
be
used
and
get
lab.
A
One
is
for
CI
CD
flow
control,
so
we
have
a
couple
special
keywords
that
allow
us
to
make
jobs
within
a
CI,
CD,
workflow
turn
on
and
off,
based
on
the
value
of
variables.
We
also
many
of
you
separate
your
application
deployment
pipelines
from
your
infrastructure
as
code
deployment
pipelines
because
infrastructure
is
code,
gets
deployed
a
lot
less
frequently
than
your
application
redeployments,
and
so,
when
you
do
that,
of
course,
you
can
use
all
of
the
data
management
capabilities
for
these
other
two
scenarios.
A
Just
a
couple
items
for
reference:
I'm,
not
gonna,
plow
through
everything
on
this
screen,
but
I
did
want
to
point
out
that
gitlab,
at
as
it
is
now
does
not
have
true
secrets
management.
We
allow
you
to
mask
variables
and
then
only
maintain
errs
of
a
group
are
allowed
to
see
and
manipulate
variables.
So,
with
the
group
hierarchy
structure,
you
could
store
secrets
at
a
higher
level
that
most
people
don't
have
access
to,
but
there
are
still
ways
to
make.
Those
secrets
reveal
themselves
within
the
pipeline.
A
Very
soon
get
lab
will
be
announcing
hashey
core
vault
integration,
so
that
we
can
have
full
secrets
handling
with
encryption
at
rest,
encryption
on
the
wire,
as
well
as
encryption
right
up
to
the
point
of
use
and
that
that
can
be
roles
based
based
on
your
developers.
I
also
want
to
point
out
that
when
you
go
through
the
gate,
lab
CI
CD
panels,
you'll
see
something
called
protected
as
a
quality
of
variables,
and
you
might
think
that
hey,
if
I
click
this
it's
going
to
make
this
variable
read-only
at
this
level.
A
That
is
not
actually
what
protected
means.
What
it
means
is
that
when
we
have
protected
branches,
and/or
protected
environments,
those
variables
will
be
allowed
to
pass
through
into
those
environments.
So
don't
think
that
clicking
protected
is
going
to
give
you
read-only
capability.
So,
basically,
as
we
flow
down
the
hierarchy,
any
level
can
overwrite
any
variable.
A
Also
just
a
quick
note
on
variable
precedence.
This
is
documented
the
URL
on
the
screen,
but
there
are
other
ways
that
variables
can
make
their
way
into
our
pipelines,
and
this
screen
shows
you
what
variables
win
so
to
speak,
and
in
this
case
the
top
ones
will
always
override
any
of
the
other
out
of
their
items
lower
in
the
list.
You
can
look
that
up
for
more
details
if
you
need
it.
A
Finally,
we
wanted
to
talk
a
little
bit
about
the
various
features
of
git
lab
and
what
Edition
they
correlate
to
notice
here
that
all
the
features
we
talked
about,
except
for
the
change
controls
that
we
talked
about
on
the
one
slide
are
all
available
in
the
core
or
free
product.
A
couple
items
we
did
not
highlight
as
we
went
through
our
merge
request
labels
variable
there
is
a
variable
that
takes
all
the
merge,
request
labels
and
pushes
it
into
the
pipeline.
A
So
you
can
start
to
control
things
that
emerge
your
quest
level
by
adding
specific
tags.
Also,
we
have
an
API
for
setting
repository
and
group
variables
and
you
can
use
that
API
within
a
pipeline.
If
you
give
the
pipeline
the
proper
credentials,
it
can
write
its
variables
back
to
its
own
variable
locations.
This
allows
you
to
persist
things
like
version
number
that
might
need
to
be
incremented
each
time
but
remembered
across
pipeline
executions.
A
I
also
wanted
to
point
out
that
the
repository
that
we
use
to
demonstrate
for
you
is
something
called
a
guided
exploration,
and
what
this
means
is
that
you
can
follow
the
instructions
here
and
you
can
first
of
all
see
all
the
patterns
that
are
demonstrated
by
this
repository.
We
only
cover
the
ones
in
4.2,
but
there
are
other
patterns
that
are
that
are
demonstrated
throughout
here.
A
So
we
went
through
a
bunch
of
different
points
here,
as
we
went
through,
we
talked
about
configuration
data
best
practices
that
have
evolved
in
the
industry
talked
about
that
wicked
problem
really
doesn't
matter
what
tools
you
throw
at
it.
It
gets
difficult
and
challenging
and
complicated,
and
so
you
have
to
apply
some
good
engineering
and
then
organize
your
tools
around
that
engineering.
We
talked
about
the
providers
and
consumers
of
configuration.
A
Data
I
would
say
that
it's
important
that
you
decide
where
this
data
is
going
to
reside,
because
it
is
a
big
point
of
where
you
can
push
it
to
so.
Your
top-level
tool
is
a
great
place
to
put
that
data,
so
it
can
push
it
to
other
downstream
systems,
and
you
have
one
global
view
of
the
data.
We
talked
about
get
labs,
config
data
features
so
that
you
can
understand
the
Flex
of
you
have
to
accommodate
these
complex
scenarios.
A
We
also
talked
about
the
convergence
features
of
how
these
things
flow
down
both
from
groups
and
also
through
repository
scopes.
We
also
touched
on
the
git
lab
development
patterns
for
CD
and
also
mapping.
Config
data
features
to
get
lab
editions.
So
so,
just
in
summary,
the
the
real
big
summary
view
here
is
that
whether
you
need
to
get
lab
to
drive,
integrate
with
or
replace
tools
that
are
in
these
various
categories,
the
flexibility
that
we've
demonstrated
for
you
here
today
is
what's
going
to
help
you
get
your
hands
around.
A
Whether
get
lab
can
do
that
for
you
or
not.
I
really
enjoy
being
a
Solutions
Architect
at
git
lab
because
we
can
dive
in
and
help
customers
understand
how
to
reduce
pain,
points,
to
accelerate
their
processes
and
consolidate
their
tooling
costs.
So
if
you
want
to
try
to
figure
out
if
this
complex
configuration
data
management
challenges
that
you
have
can
be
handled
by
git
lab,
you
can
get
a
solutions
architect
to
help
you
out
by
calling
our
sales
department
or
contacting
them
at
the
URL.
That's
on
the
screen.
A
I
also
want
to
give
you
the
links
here
for
our
rich
gate,
lab
change,
controls
for
building
workflows.
You
can
trust
that
we
touched
on
in
this
presentation
and
also
a
link
to
the
guided
exploration
repository
that
backs
this
presentation.
I
hope
what
we've
covered
helps
you
understand
how
you
too,
can
get
control
over
that
complex
configuration
data
management
monster
because
git
lab
is
a
tool
made
for
developers
by
developers.
A
It
tends
to
emphasize
primitives
things
like
CI
C,
D
variables
and
then
build
upon
those
by
adding
them
to
groups
and
giving
them
scopes,
and
so
sometimes
it
can
be
challenging
to
dig
through
and
understand
how
you
might
assemble
the
solution
that
works
for
you.
So
I
really
hope
that
this
presentation
has
taken
a
bite
out
of
that
for
you
in
the
terms
of
getting
complex
configuration
data
configured
inside
of
get
labs.
So
you
can
do
your
builds
and
deployments
with
confidence
thanks
for
your
time,.