►
From YouTube: Never Hire a Butler to do a Robot's Job
Description
Jenkins has been the backbone of free CI, but GitLab's free modern Born-for-DevOps, Born-for-Cloud pedigree enabled Production Grade CI and CD that leaves Jenkins in the dust. Oh, did I mention it's free? Join Darwin (DarwinJS) in some perspectives on how to ensure you understand how GitLab runners are can be the foundation for production-grade CI implementations.
Playlists:
- GitLab Reference Architecture, Performance Testing, Scaling and HA (https://youtube.com/playlist?list=PL05JrBw4t0KqgVugqCld2fUvrBulanchq)
- GitLab CI/CD Tips Tricks and Hacks (https://youtube.com/playlist?list=PL05JrBw4t0Kr92rF9z0PEuOtQnH89VD7n)
- GitLab and Windows (https://youtube.com/playlist?list=PL05JrBw4t0KqOJeQ1y5wSBxArdTEtmnxb)
- GitLab and PowerShell (https://youtube.com/playlist?list=PL05JrBw4t0KrklJ2kDTl2qXNaGSlzKeoW)
- DarwinTheorizes (https://youtube.com/playlist?list=PL05JrBw4t0KoH74CcAtP0Ze7JXjX7zT6g)
A
Hello,
everyone,
it's
my
pleasure
to
share
with
you
today,
never
hire
a
butler
to
do
a
robots
job.
My
name
is
Darwin
Senoia
and
I'm,
a
senior
Solutions
Architect
at
get
lab.
The
experiences
that
I'll
be
relating
to
you
and
the
information
in
this
presentation
are
actually,
from
my
time
before
joining
get
lab.
I
managed
a
stack
of
gitlab
as
an
internal
service
to
a
company
that
had
about
4,000
developers
and
upwards
of
100
different,
soft
or
sass
stacks
that
they
were
putting
in
the
cloud.
A
Basically,
you
really
want
to
talk
about
how
the
fact
that
production
applications
should
be
backed
by
a
modern
self-service
production
grade,
continuous
integration
and
we'll
talk
about
the
reasons
why
that's
important
and
critical
as
we
go
through
we'll
talk
about
a
SAS
application
portfolio
now
to
me
that
I
worked
with,
and
so
some
of
the
challenges
in
the
diversity
that
created
the
approach
to
doing
cloud
and
then
to
doing
CI
for
cloud.
We'll.
A
Also
talk
about
the
required
SCM
and
CI
solution,
anatomy
to
service
an
application
portfolio
that
is,
production
ready
on
the
cloud
and
we'll
talk
about
product,
managed,
automation,
forerunner
provisioning.
So
one
of
the
key
things
that
we
did
in
this
scenario
was
to
make
the
automation
that
built
runners
for
individual
teams
into
sort
of
a
product
managed
out
of
the
fact,
so
we
traded
it
like
software
that
we're
presenting
to
our
customers
we'll
also
talk
about
the
nuts
and
bolts
of
robots
over
butlers.
A
So
what
are
some
of
the
reasons
why
it's
better
to
use
robots
than
Butler's
for
mass
automation
and
then
finally,
we'll
also
talk
about
the
cyborg
Butler
or
the
upgrades
to
Jenkins
that
have
been
occurring
lately
and
we'll
kind
of
position?
Those
with
regard
to
the
rest
of
the
information
that
we'll
cover
in
the
presentation
and
then
finally,
at
the
end,
I,
have
a
surprise
for
you,
some
information
about
how
you
can
get
started
with
Jenkins
and
get
lab
migrating
from
Jenkins
to
get
lab.
A
So
let's
talk
a
little
bit
about
this
environment,
so
we
have
a
multi-tenant
sass
development
environment.
In
this
case,
as
I
mentioned
already,
it
was
over
4,000
developers
and
hundreds
of
products.
It
was
a
company
that
was
grown
by
acquisition,
which
meant
that
we
had
almost
every
computing
language
in
the
book
and
many
many
technologies
in
those
stacks
that
were
acquired.
It
was
also
multi-platform
with
regard
to
anything
that
went
on
instances
so
roughly
about
50/50
for
any
of
the
computing
that
was
targeted
at
instances.
A
A
The
security
was
also
very
stringent,
so
security
and
production
had
to
be
able
to
divide
an
Amazon
account
into
multiple
verticals
in
order
to
allow
multiple
products
to
be
in
that
account
and,
of
course,
the
products
as
well
as
the
customer
data
have
to
be
kept
separate.
We
can't
have
that
kind
of
tight
security
and
production,
but
have
loose
security
and
development
so
that
security
model
had
to
be
brought
all
the
way
back
into
development,
which
meant
we
had
some
pretty
stringent
requirements
on
a
per
team
basis.
A
In
terms
of
security,
it
was
also
multi-tenancy
SAS.
It
was
being
built
so
that
customers
who
came
and
used
the
software
didn't
have
to
have
resources
deployed
for
every
customer.
Of
course,
Jenkins
is
very
common
because
it's
common
everywhere
right
and
so
Jenkins
has
a
long
and
strong
heritage
of
being
one
of
the
first
DevOps
products
to
really
start
scaling
out
in
the
open
source
community,
and
then
the
entire
release
cycle
for
each
product
was
upgraded
to
a
cloud
and
DevOps
deployment
type
of
perspective
and
then,
finally
to
living
adoption
was
voluntary.
A
So
each
of
these
stacks
had
its
own
kind
of
profit
loss
center
and
what
tools
they
used
was
really
up
to
them
and
they
had
to
make
sure
it
made
sense
to
adopt
certain
tooling
and
to
ensure
the
timing
of
that.
Adoption
was
right
for
their
team
and
didn't
impact
customer
feature
velocity,
so
a
very
complicated
environment.
Really
not
unlike
how
gitlab
comm
service
is
the
open
market,
all
kinds
of
languages,
all
kinds
of
different
priorities.
A
Now,
in
this
scenario,
when
we
did
the
tooling
so
I've
worked
on
a
development
tooling
team
I
was
one
of
the
team
leads
on
that
team.
We
wanted
to
teach
treat
CI
as
a
production
grade
environment
and
really
is
important,
because
downtime
affects
developer
productivity
and
when
you're
in
a
massive
company,
that's
all
developers,
that's
just
about
everyone,
also
hot
fixing
production
or
doing
anything
that
requires
some
sort
of
fast
action
and
production
requires
that
the
CI
tooling
be
available.
A
A
That's
a
single
point
of
failure,
so
we
really
wanted
to
have
production
grade
SCM
and
CI,
just
like
we
presented
to
our
customers
for
our
actual
end
applications,
so
that's
kind
of
the
portfolio
and
what
it
looked
like
and
why
we
had
to
really
focus
on
making
something
production
grade.
Near-Vacuum
production
grade
systems
for
customers,
then
the
tooling
that
services,
those
stacks
should
be
production
grade
as
well.
Let's
take
a
little
bit
look
at
what
that
means,
then,
for
how
we
would
design
source
control
management
and
continuous
integration.
A
So
we
want
to
design
the
actual
source
code
management
and
the
CI
automation
as
a
product,
and
we
want
to
develop
it
as
close
to
12
factor
model,
as
we
could
one
of
the
things
that
we
did
was
we
built
the
it
ease
right
in.
So
we
wanted
to
make
sure
that
we
had
security
handled
that
we
had
automation
handled,
we
had
maintainability
and
we
also
took
dev
with
a
dev
integration
environment.
We
also
took
feature
requests
and
bug
fixes
against
this
automation.
A
A
We
also
needed
scalability,
and
for
that
we
used
an
AWS
ASG.
We
wanted
multiple
multi
platform
capability,
because
we
had
that
multi
platform
aspect
to
the
software
in
the
company.
In
addition,
we
wanted
maintainability
built-in,
so
this
is
things
like
making
patching
and
upgrading
the
runner
really
easy
a
lot
of
times.
We
build
enablement,
automation
and
you
deploy
it
and
while
you're
up
and
running
in
no
time,
but
in
nine
months,
you're
behind
and
patching
on
everything
that
makes
up
that
automation
stack.
A
A
We
also
had
to
make
sure
that
that
security
was
taken
care
of,
and
we
handled
this
with
an
iamb
role
that
was
assigned
as
the
instance
profile
for
the
runner.
So
then,
the
iam
role
for
that
runner
made
sure
that
the
all
the
development
activities
that
happened
in
CI
had
the
exact
same
permissions
as
a
developer
and
no
more
permissions
than
a
developer
for
that
team.
A
Also,
a
good
part
of
doing
product
kind
of
approach
to
this
was
having
good
documentation,
so
things
that
couldn't
be
handled
an
automation
needed
to
be
documented.
Very
well,
but
not
over
overly
verbose
enough
to
get
started
cleanly
and
easily.
We
also
used
dependency
isolation.
Now,
of
course,
with
instances
in
containers
built
right
in
to
get
lab.
We
used
the
full-on
docker
executor
so
that
we
could
get
that
dependency
isolation.
A
We
also
wanted
to
make
sure
it
was
cost
managed
well,
and
we
were
eventually
able
to
take
this
solution
and
leverage
spot
instances
so
that
anyone
using
it
was
saving
a
lot
of
money
and
getting
access
to
much
more
capable
compute.
And
finally,
we
wanted
to
make
sure
that
that
continuous
integration
we're
providing
through
this
automation
was
production
grade,
and
these
are
the
ways
that
we
made
try
to
make
it
production
grade
and
managed
as
a
product.
A
First
of
all,
we
had
a
tool
that
was
similar
to
terraform.
I'm
gonna
represent
it
here
as
terraform.
It
was
an
internal
tool,
but
if
you
were
doing
this
yourself,
you
could
easily
use
terraform,
basically
that
linked
together
some
cloud
formation
templates
that
did
the
brunt
of
the
work
for
all
of
this.
That
template
established
an
auto
scaling
group
for
the
runner.
So,
even
though
we
were
only
going
to
put
one
instance
in
there,
we
wanted
to
make
sure
that
that
auto
scaling
group
would
be
able
to
reestablish
that
instance.
A
A
It
turns
out
that
we
were
able
to
turn
these
into
containers,
and
now
our
developers
could
just
source
those
containers
in
their
get
lab
CI
file
and
be
able
to
get
to
those
same
exact
development
services,
but
they
were
using
a
container
and
a
job
instead
of
an
entire
Jenkins
server.
I
mentioned
the
maintainability
built
in
and
that
came
down
to
making
sure
that
people
could
have
the
latest
on
Amazon
Linux
to
AMI
or
peg
it
if
they
had
version
sensitivity
for
a
time
period.
Also
the
latest
Runner
version.
A
They
could
also
peg
this
if
they
found
that
they
had
any
sensitivities
and
then
runner
tokens.
So
they
could
rerun
the
automation
to
repoint
the
automation,
a
different
set
of
Runner
tokens
if
they
had
a
new
set
or
had
regenerated
some
or
needed
to
add
some
to
a
set
of
runners.
So
that's
kind
of
how
the
automation
looked.
It
was
then
very
easy
for
development
teams
to
set
up
their
own
instances
using
this
automation.
A
Now,
let's
take
a
little
look
at
the
nuts
and
bolts
of
robots
over
Butler's.
Now,
as
we
go
through
here,
we're
going
to
be
comparing
to
get
lab
CI
get
lab.
Ci
is
what
I
call
born
for
devops
born
for
cloud
CI,
and
there
are
other
systems
that
are
also
born
in
the
era
of
the
cloud
and
they
have
some
similar
characteristics
in
some
cases,
as
we
go
through
here,
though,
realize
that
you
know
this
is
based
on
actually
having
provided
Jenkins
services
on
to
the
same
team.
A
So
we
have
many
development
teams
using
Jenkins
and
we
had
shared
build
services
deployed
on
it.
Now,
when
we
did
that
shared
build
services,
we
were
directly
exposed
to
some
of
the
challenges,
so
keeping
that
patched
making
sure
that
the
right,
tooling
was
available,
also
managing
the
users
making
sure
that
Jenkins
engine
was
up
to
the
right
version
and
MIT
and
that
always
a
pernicious
and
a
crazy
problem
of
keeping
the
Jenkins
plugins
updated,
yet
happy
and
not
breaking
anyone's
builds.
So
we
had
to
exposure
to
all
of
these
shared
management
tasks.
A
We
also
built
automation
to
build
a
Jenkins
server,
so
we
had
also
gone
to
that
point
of
building
a
toolkit
to
deploy
Jenkins,
and
then
we
also
leveraged
get
labs
excellent,
Jenkins
integration,
because
changing
CI
is
hard.
It's
a
really
fundamental
aspect
of
how
teams
work.
So
by
using
the
git
lab
Jenkins
plugins,
we
were
able
to
have
teams
on
board
with
their
source
code,
point
everything
back
to
Jenkins
and
have
things
running
smoothly
and
then
slowly
as
they
had
time
and
we're
digging
for
higher
value,
they
were
able
to
implement,
get
lab
CI.
A
This
also
lets
them
implement
it
in
parallel,
so
they
can
make
sure
they're
getting
the
exact
same,
builds
out
of
gate
lab,
see
I
before
they
decommission
their
Jenkins
builds
well.
So
let's
talk
just
for
a
minute
about
tenancy
and
service
management
automation.
This
is
one
of
the
really
cool,
little
secrets
in
git
lab.
That
makes
things
a
lot
easier
for
you.
So
in
our
case,
we
allowed
teams
to
come
and
self
provision.
So
I
would
have
a
team
asked
me:
how
can
we
get
started
with
gitlab?
A
Can
you
set
us
up
on
there
and
I
would
actually
say?
No.
Actually,
you
can
set
up
yourself
go
to
this
documentation.
Page
it'll
explain
how
you
get
on
to
the
git
lab
server
with
SSO
set
up
your
first
group.
Add
your
users
start
adding
repositories,
and
you
can
basically
run
it
just
like,
as
if
you're
on
git
lab
comm,
so
to
compare
that
to
what
happens
with
Jenkins.
Typically,
we
create
a
master
if
you're
doing
a
more
advanced
implementation.
A
You'll
have
build
agents
that
are
tethered
to
that
master,
but
it
doesn't
take
very
long
for
teams
who
are
trying
to
share
this
instance
to
run
into
problems
with
conflicting
plugins
or
someone
wants
to
upgrade
the
version
of
Jenkins
for
security
reasons
and
it
breaks
someone
else's
build,
and
so
very
quickly
teams
tend
to
fragment
out
and
start
creating
their
own
masters
because
they
want
to
be
in
control
of
the
code.
That's
on
that
server
when
it
gets
upgraded,
making
sure
they
have
time
to
fix
things
if
it
breaks
anything.
A
So
really
Jenkins
is
not
a
multi-tenant,
each
master
could
be
thought
of
as
a
tenant,
and
so,
if
you
found
where
you
start
fragmenting
into
multiple
masters
because
of
various
concerns,
then
you're
experiencing
the
fact
that
Jenkins
is
not
single
tenant.
It
also
has
no
service
management
automation.
So
there
is
no
capability
to
very
easily
deploy
this
framework.
If
you
deploy
Jenkins
master,
it's
a
lot
of
extra
steps
to
build,
do
build
build
agents
that
are
independent
and
are
scaling
on
their
own
and
even
more
work.
A
In
our
case,
we
scaled
up
to
2,500
users
with
3,700
repositories,
400
groups
and
around
250
scaled
runners,
so
you
can
think
of
that
as
250
Ekans
masters.
Now,
interestingly,
I
had
a
team
of
four,
including
myself,
and
we
probably
I
estimated,
had
about
one
and
a
half
full-time
people
working
on
get
lab
at
any
given
time,
and
this
scalability
kept
ramping
up
without
us,
even
knowing,
because
it
didn't
really
change
our
admin
overhead
when
more
users
and
more
repositories
and
more
groups
were
added.
A
Now
we
had
deployed
the
the
the
gate,
lab
instance
as
a
scaleable
container
based
implementation,
so
that
helped
a
lot
as
far
as
just
operational
scalability,
but
in
terms
of
administrative
scalability.
We
didn't
have
a
lot
of
admin
activities
to
keep
up
with
to
have
these
teams
leverage
the
system,
let's
get
down
to
a
little
bit
of
nitty-gritty,
comparing
some
of
the
individual
items.
So
we'll
talk
a
little
bit
here
about
clean
code
and
clean
builds,
so
in
the
in
the
world
of
build
isolation.
A
A
Jenkins
gets
a
little
bit
of
a
sideways
thumb
here,
because
implementing
containers
is
more
work
than
just
simplicity,
simply
setting
up
Jenkins
with
git
lab
runner.
We
find
that
when
we
set
it
up,
there's
a
certain
amount
of
work,
but
it
doesn't
matter
if
you're
going
to
use
containers
or
not
it's
roughly
the
same
amount
of
work
to
get
it
running
per
build
worker
isolation.
This
is
where
these
build
workers
can
have
different
code
and
they're
isolated
from
one
another.
Jenkins
does
not
do
as
good
of
job
in
this
area
as
get
lab.
A
Ci
also
CI
engine
isolation.
So
this
is
the
ability
for
us
to
make
sure
that
the
CI
engine
is
isolated
from
the
rest
of
the
system,
so
in
get
lab,
runners
can
be
running
a
version
of
git
lab
runner.
That
is
different
than
the
instance.
In
our
case,
we
sometimes
had
people
running
two
or
three
newer
versions,
because
we
didn't
run
the
newest
version
of
get
lab
on
our
instance
and
they'd
be
running
a
runner.
A
That's
a
couple
versions
ahead
and
of
course,
we
had
two
three
and
four
and
five
Asians
behind
and
it
all
worked
very
well
see
I,
plugins
and
extensions
isolation.
Now
in
gitlab,
our
extensions
are
all
created
by
gitlab
they're
in
your
repository,
you
can
also
create
web
hooks.
These
methods
of
extension
are
all
built
by
git,
lab
and
tested
every
time,
there's
a
release,
so
we
don't
run
into
the
situation
where
plugins,
which
aren't
being
updated
actively
all
of
a
sudden
stop
working.
A
The
other
level
of
isolation
that
happens
here
is
when
you
build
a
job.
Every
job
can
be
its
own
container.
You
can
build
a
container
for
it
or
use
a
public
container,
and
then
you
have
some
CI
job
code
to
go
with
that.
Well,
that
isolation
also
prevents
any
conflicts.
You
can
be
running
maven
in
one
container
node
in
another
container
and
have
them
all
part
of
the
same
exact
pipeline
and
then
the
master
worker
engine
version
coupling
in
Jenkins.
These
have
to
be
the
same.
Of
course,
in
get
lab.
A
Now,
let's
talk
a
little
bit
about
mutability,
scalability
and
high
availability,
so
we
talked
about
the
idiot
in
and
a
lot
of
these,
it
ease
built-in
come
from
the
heritage
of
git
lab
CI
itself,
so
build
workers
being
able
to
be
destroyed.
Easily
get
lab
is
very
good
at
this.
It
is
it
runners
are
considered
a
mutable
item.
A
You
don't
tend
to
consistently
kill
them
all
the
time,
but
it's
not
a
problem
and
if
you're
using
containers,
of
course,
those
ever
at
the
end
of
every
job,
they're
thrown
away
and
new
ones
are
used
with
containers.
We
have
the
same
situation
on
the
case
of
Jenkins
once
again,
containers
and
individual
build
workers
are
harder
to
setup,
so
we're
not
giving
it
to
the
full
thumbs
up,
but
it
does
support
these
capabilities
and
then
master
scalability
with
git
lab
CI.
A
The
master
is
actually
your
get
lab
instance,
so
all
the
stuff
that
a
Jenkins
master
does
is
done
by
the
get
lab
instance.
This
includes
storing
all
data
you
might
want
to
keep
such
as
Bill.
If
you
have
other
information
in
there,
that
is
needs
to
be
kept
like
artifacts.
All
of
that
goes
back
to
your
gitlab
instance
and
then
because
we
only
do
build
as
code
with
gitlab.
Your
build
pipelines
are
not
defined
in
the
the
build
agent
itself.
A
It
is
code
in
your
repo
with
your
actual
software
code
and
therefore
is
never
lost,
because
it's
always
in
the
repository
master,
high
availability,
so
Jenkins
masters
can
only
be
a
single
instance.
Well,
we'll
talk
a
little
bit
about
Jenkins
X,
but
as
far
as
the
traditional
Jenkins
to
your
masters,
can
there
can
be
only
one
and
it's
the
same
as
far
as
scalability
goes.
There
is
a
way
to
set
up
pseudo
h-a,
and
we
did
do
this
at
in
the
organization
where
we're
doing
this
get
lab
deployment.
A
We
did
it
through
having
an
ASG
that
would
back
it's
the
kid
lab
ours
I'm
sorry,
the
Jenkins
instance
would
back
itself
up
and
then,
when
the
ASG,
if
it
terminated
the
Jenkins
instance,
when
that
new
instance
was
established,
it
would
check
for
a
backup
and
restore
it
if
it
was
there,
so
you
can
make
it
work.
You
can
kind
of
wedge
it
into
that
mold.
But,
of
course,
this
is
just
the
business
as
usual.
Get
lab
CI
state
data
storage,
I
already
actually
mentioned
this,
but
all
of
your
get
lab
build
data.
A
A
Let's
talk
a
little
bit
about
secure
ability,
get
lab,
has
a
very
well-defined
minimal,
modern,
secure,
API,
so
built
for
cloud
built
for
devops
means.
The
approach
to
api
is
is
taken
seriously.
The
security
in
the
api
is
taken
very
seriously,
which
is
not
necessarily
the
case
with
jenkins
heritage
or
any
of
the
plugins
which
might
be
made
by
people
of
varying
skills
as
far
as
their
secure
coding
capabilities,
also
the
patch
ability
of
the
operating
system
that
underlies
the
entire
system
without
disturbing
the
runner
on
get
loud.
A
This
is
very,
very
simple
and
easy
here,
you're
using
the
docker
executor.
Of
course,
your
complete
isolated
from
whatever's
going
on
on
that
build
runner,
but
even
when
you're
doing
shell
runners
get
lab
has
a
very
high
level
of
compatibility
with
any
operating
system.
Patching
minimal
disruption
for
master
upgrades,
so
get
lab
itself
can
be
upgraded
with
zero
downtime,
and
that
is
where
your
master
is
so
that
zero
downtime
upgrade
capability
transfers
right
to
all
of
your
CI,
secure,
plug-in
extensibility.
So
how
secure
are
plugins
when
you
build
them
get
lab.
Ci
is
very
secure.
A
It
has
no
web
UI,
which
is
another
concern.
Having
a
GUI
attack
surface
every
Jenkins
instance
has
its
own
GUI
that
sometimes
people
are
putting
out
on
the
Internet,
even
if
they
aren't
even
internally
there's
that
GUI
exposed
and
then
every
instance
becomes
a
security
management
concern.
Gitlab
CI
is
only
needs
port
443
back
to
the
git
lab
instance.
It
doesn't
expose
other
ports,
it
doesn't
need
anything
to
be
able
to
be
posted
to
it
from
the
git
lab
instance
size.
A
So
it's
very
secure
and
then
normally
you're
running
this
behind
closed
doors,
because
it
doesn't
make
sense
to
expose
it.
You
don't
need
to
get
to
any
kind
of
GUI
for
it
and
all,
obviously
anything
you
do
to
secure
the
gate.
Lab
instance
UI,
which
would
be
very
important,
automatically
translates
into
CI
access
control
and
service
management
automation.
So
this
is
a
bit
about
multi-tenancy,
isolating,
build
worker
permissions
fairly
straightforward
and
get
lab
by
using
the
right
security
profile
for
the
runner.
A
When
we
were
trying
to
manage
our
central
Jenkins
services
in
order
to
allow
multiple
developers
to
access
those
Jenkins
servers,
we
had
a
lot
of
challenges
with
trying
to
keep
it
separate
and
definitely
they
couldn't
come
up
and
self
provision
themselves
onto
those
servers
as
far
as
general-purpose
automation.
This
is
an
area
where
Jenkins
strength
can
be
a
weakness,
so
Jenkins
can
do
a
lot
of
different
things,
and
part
of
this
is
its
long
heritage
in
the
DevOps
space
that
can
be
really
powerful.
A
If
you
got
you
know
a
small
team
and
you
got
some
Jenkins
ninjas
on
there.
The
challenge,
though,
is
that
it's
hard
to
get
it
to
be
very
bespoke
or
very
opinionated
towards
CI,
and
so
gitlab
is
definitely
more
CI.
Cd
opinionated
you're,
not
going
to
be
able
to
you
know,
do
all
kinds
of
wacky
automation
that
have
nothing
to
do
with
CI
a
CD
definitely
keeps
you
inside
the
guardrails
of
CI
CD.
A
As
far
as
modern
development
practices
support,
so
full
CI
system
mutability
the
idea
that
people
quickly
log
into
CI
systems
and
starts
no
flaking
them,
even
if
they're
say
a
build
agent
for
your
one,
build
agent
for
Windows
people,
start
logging
in
and
add
and
stuff
manually
on
the
get
lab
side
that
mutability
is
supported
from
day
one
and
so
you're
encouraged.
Not
to
do
that.
Build
agents
should
be
completely
automated
as
far
as
the
deployment
and
the
build
of
them
build
as
code,
it's
enabled
in
Jenkins
with
Jenkins
files.
A
However,
it
doesn't
disable
the
old
way,
so
it's
very
easy
for
teams
to
continue
to
store
their
build
information
inside
of
the
Jenkins
server
itself.
As
far
as
environment
customization,
pets
are
really
common
amongst
Jenkins
lots
of
variability
and
the
build
runners
as
well
as
the
masters.
If
you
have
multiple
masters
and
really
get
labs
more
like
a
nanobot
army,
so
no
variability
just
lots
of
replicants
of
the
exact
same
configuration
so
for
production
grade.
Ci
takes
a
lot
of
work
to
get
Jenkins
to
behave
like
its
production,
CI,
scalable,
mutable
h.a
worth
get
lab.
A
This
is
just
the
name
of
the
everyday
game,
so
that's
a
little
bit
about
the
nuts
and
bolts
of
robots
over
Butler's
and
some
of
the
things
that
are
important
to
take
into
consideration
when
trying
to
create
production
grade
CI.
Let's
talk
a
little
bit
about
some
of
the
changes
in
gitlab
and
I'm
gonna.
Basically,
you
know
show
you
here
that
mixed
architectural
heritage
gives
mixed
implementation
benefits.
A
A
We
also
have
the
challenge
with
masters
and
pseudo
h.a,
so
we
still
have
that
challenge
of
it
not
really
being
able
to
help
you
out
in
terms
of
making
it
more
production
grade
and
then
there's
an
entire
company
that
has
an
offering
to
help
compatibility
test
and
manage
a
set
of
plugins
that'll,
be
guaranteed
to
be
compatible
and
well
maintained
from
release
to
release
of
jenkins,
so
that
you
can
upgrade
your
jenkins
for
security
reasons
and
for
getting
new
capabilities
and
be
confident.
Plug-Ins
are
gonna,
keep
working
and
I
think
that's
a
great
thing.
A
However,
the
fact
that
that
is
a
offering
that
is
really
really
highlighted
and
very
very
promoted
shows
you
that
this
is
a
real
problem
for
open
source
jenkins.
So
it's
one
of
the
critical
challenges
of
keeping
jenkins
running
now
jenkins
acts
great
that
the
platform's
moving
forward
and
people
are
making
some
efforts
to
modernize
it
and
bring
it
into
the
the
DevOps
and
cloud
era.
However,
there's
some
things
that
are
concerning
one
is
its
kubernetes
only
and
some
of
you
are
all
out
for
kubernetes
and
that's
great.
A
Some
of
you
may
not
feel
like
it's
time
for
you
yet
for
kubernetes,
or
maybe
there's
some
challenging
concerns
about
whether
or
not
your
applications
should
even
become
kubernetes.
So
that
is
a
challenge
you
have
to
take
on
kubernetes
operations,
even
if
you're
not
doing
it.
For
any
other
reason,
it's
still
the
Jenkins
2o
engine
under
the
covers.
We
still
have
the
shared
plugins
issues,
so
we
still
have
one
database
of
plug-in
code.
The
pipelines
are
still
in
groovy.
They
have
not
been
modernized
to
yea
Mille
in
order
to
take
advantage
of
the
syntax
benefits.
A
It
also
has
a
very
opinionated
get
flow,
so
its
trunk
based
all
development
is
the
main
way
that
Jenkins
acts
deals
with
code.
So,
if
you're
not
doing
that,
you
have
to
start
thinking
about
doing
that
or
potentially
trying
to
do
some
workarounds.
The
default
of
the
scalable
master
is
to
be
without
a
GUI,
so
the
scalable
master,
although
its
multi-node,
does
not
have
a
GUI.
A
So
if
you
feel
like
you
need
that
GUI,
because
developers
are
used
to
it
as
soon
as
you
set
up
that
node,
you
have
a
single
node
for
that
purpose,
so
the
UI
is
still
not
fully
h.a,
also
overall,
there's
a
lack
of
reasonable
roles
based
access
controls
and
they
aren't
integrated
with
your
source
code
management.
So,
in
the
case
of
gitlab,
you
set
up
your
rules
based
access
controls
on
your
source
code.
They
flow
right
through
to
your
CI.
A
A
So
that's
a
little
bit
about
the
new
state
and
we'll
see.
Obviously
Jenkins
X
is
a
moving
target
and
the
open
source
community
is
forever
resourceful
and
innovative.
So
they're,
you
know
a
lot
of
lot
of
cool
things
still
to
happen
there,
but
that's
kind
of
the
state
of
the
nation
as
it
is.
Let's
talk
a
little
bit
about
migrating
from
Jenkins
to
get
lab.
What
are
some
of
the
resources
available
to
you
and
some
of
the
approaches
to
help
you
with
this?
A
First
of
all,
we
have
excellent
integration
into
get
lab
and
the
reason
why
this
is
a
plus
point
is,
as
I
mentioned
before,
you
can
move
your
source
code
in
there
start
pointing
it
back
to
your
Jenkins
jobs
and
keep
that
CI
investment
you
have
and
then,
as
teams
are
able
to
step
up
to
the
bar,
have
extra
time
they
can
start
working
towards
getting
get
lab,
CI
implemented.
This
also
lets
them
do
parallel
implementation,
so
they
can
make
sure
they're
getting
the
results.
A
We
also
have
a
guide
for
migrating
from
git
lab
to
Jenkins,
and
this
guide
handles
information,
not
just
technical
information,
but
also
information
about
helping
your
team's
prepare.
Helping
them
to.
You
know,
get
ready
and
kind
of
some
of
the
differences
between
the
two
platforms
and
how
teams
can
have
advanced
information
and
advanced
exposure
to
that
information
and,
finally,
something
very
interesting.
We
have
a
gitlab,
CI
Jenkins
wrapper
under
development,
and
this
is
allows
you
to
do
Jenkins
file
execution
in
get
lab
CI
with
the
community
container
Jenkins
files
Jenkins
file
runner.
A
So
this
community
container
treats
Jenkins
as
sort
of
a
function
in
a
pipeline
and
so
because
git
lab
CI
uses
containers
as
one
of
the
executives
that
we
can
support.
This
can
be
used
directly,
so
we're
working
on
integrating
this
completely
and
what
this
will,
let
you
do
is
get
to
get
lab,
scaleable
runners
right
away.
If
you
have
a
big
investment
say
we
have
some
customers
who
have
a
large
investment
in,
say,
Jenkins
files
that
are
working
well,
but
the
Jenkins
infrastructure
itself
is
not
working.
A
Well
so
they'd
like
to
be
moore's
cattle,
scalable
mutable
and
have
the
benefits
of
the
entire
CI
a
ecosystem
that
gitlab
provides.
So
this
will
allow
you
to
be
able
to
run
those
Jenkins
files
until
such
time
as
they
get
retired
or
you
can
modernize
that
CI
to
get
lab
CI
native,
so
I
hope
that
we've
been
able
to
give
you
some
things
to
think
about
mainly
that
production
applications
really
require
a
modern
self-service.
Production-Grade
continuous
integration
get
labs
inherent
DevOps
and
cloud
readiness
enables
these
kind
of
production
grades.
Ci
implementations.
A
It
also
enables
a
scale-up
of
CI
services
with
low
admin
overhead.
So
you
don't
have
to
keep
scaling
the
teams.
You
can
keep
adding
people
to
all
kinds
of
administrative
interfaces
on
the
product
so
that
the
teams
don't
have
mixed
permissions
between
each
other.
Also
get
lab
enables
incremental
evolution
from
Jenkins
towards
modern
CI
through
the
the
various
things
that
we
just
talked
about
in
the
previous
slide,
and
the
real
question
to
ask
yourself
is:
is
your
CI
production
rade
or
is
it
the
weak
link
so
something
to
think
about?
Hopefully,
we've
all
progressed
past.
A
So
I
just
want
to
wrap
up
by
saying.
I
really
enjoy
my
job
at
get
lab
as
a
Solutions
Architect.
We
get
to
take
time
with
customers
to
understand
if
our
tooling
and
technology
will
help
them,
accelerate
their
development
or
save
money,
consolidating
tools
or
get
off
of
technologies
that
really
aren't
doing
the
job
for
them.
So
if
you
find
that
you
need
help
figuring
out,
your
Jenkins
migration
scenario
feel
free
to
contact
our
sales
department
and
they
can
put
you
in
touch
with
a
Solutions
Architect
to
help
you
out
with
these
challenges.