►
Description
Jean and Lauren discuss how we got to the current state of the monorepo structure of the www-gitlab-com repo and what the future holds for the repo. The abrupt ending to the call was unfortunately due to a power outage.
A
A
Hello
everybody.
So
this
is
a
conversation
with
lauren
barker
from
the
brandon
digital
design
team,
and
what
we're
going
to
be
talking
about
today
is
the
work
that
we're
doing
on
the
gitlab.com
repo
for
most
people.
You
know
that
would
either
be
the
handbook
or
the
marketing
site.
So
essentially,
if
you
go
to
about.gitlab.com
whatever
you
see
on
that
domain,
using
that
repo
and
over
the
last
few
months,
I
would
say,
probably
an
earnest
from
about
january
february
this
year,
we've
we've
made
a
lot
of
changes
to
that
repository.
A
The
there's
going
to
be
a
continued
amount
of
you
know.
Big
amount
of
changes
going
forward,
marketing
team
is
is
in
process
of
looking
at
the
new
tech
stack
and
and
redesign
and
all
of
those
things,
so
we're
going
to
talk
a
little
bit
about
what
has
changed.
Why
it's
changed
and
how
you
know
things
might
evolve
further
in
the
future.
So
I'll
start
by
by
quickly
summarizing
that
the
static
side,
error
team,
our
our
main
reason
for
existing
is
to
facilitate
a
easy
contribution.
A
A
lot
of
them
will
join
github,
not
never
having
used
git
or
terminal
even
before,
and
so
this
this
can
be
quite
rooting,
and
so
the
three
pillars
that
the
static
site
energy
really
focuses
on
is
around.
You
know
not
requiring
people
to
to
have
to
understand
it
as
well.
It's
not
needing
to
run
a
local
environment
and
also
not
to
have
to
understand
mark
them
now.
A
Are
this
all
kind
of
like
lands?
You
know
into
the
handbrake
project?
Is
the
handbook
is
aesthetic
site
as
part
of
the
overall
marketing?
You
know
website
on
about.gitlab.com,
and
we
we
have
team
members.
We
need
to
contribute
to
that
and
a
lot
of
a
lot
of
the
challenges
we
had
up
front
with
with
the
website
was
around
the
fact
that
a
people
didn't
necessarily
wish
understand
what
to
do,
but
also
we
had
slow
pipelines.
A
That
was
that
was
earning
it
and,
and
so,
as
the
as
the
team
that
was,
you
know,
primarily
formed
to
enable
easy
editing
of
of
content
in
the
handbook.
It
followed
us
to
also
take
care
of
the
technical
aspects
and
obviously
you're
the
marketing
website,
team,
lauren
and
brandon,
etc,
are
working
in
there.
Every
day
as
well-
and
so
we
partnered
with
them
early
on
in
this
in
this
journey
and
to
to
help
us
with
this
and
and
so
we've,
we
eventually
after
a
lot
of
kind
of
like
conversations.
A
What
can
we
do
to
make
things
faster
and
and
more
stable
yeah?
We
also
have
this
this.
This
problem
with
somebody
might
make
a
change
in
the
handbrake
that
breaks
the
site,
and
now
you
know
nobody
can
deploy
a
blog
post,
something
like
that,
and
so
the
the
site
became
very
big
and
interconnected,
and,
and
so
we
needed
to
be.
B
A
A
And,
and
so
after
a
lot
of
concern,
conversation
mainly
between
chad,
myself
and
we,
we
came
up
with
this
proposal
to
move
to
a
mono
repo
structure
where
we
would
have
a
single
repository
with
multiple
sites,
usually
coupled
as
far
as
possible,
separated
from
each
other
sharing
templates
and
assets.
So
and-
and
we
we
spend
a
couple
of
months
migrating
to
that
structure,
we're
there
right
now,
we've
got
a
marketing
website
and
a
handbook
website
in
the
in
the
repo
and
they're.
A
A
B
A
Exactly
yeah,
so
we
we
did
that
primarily
to
to
allow
us
so
so
part
of
part
of
this
moving
to
a
monorail
approach
that
there
was
two
principles
that
guided
that
the
decision,
the
first
one
was
a
principle
of
separation,
so
separating
the
code
right,
the
handbook
in
the
marketing
code,
purely
because
we
we
realized,
our
paths
were
diverging.
You
know,
marketing
needed
have
specific
needs
that
that
doesn't
necessarily
correlate
with
the
handbook's
needs,
as
well
as
just
clear
ownership
as
well.
A
You
know,
if
there's
a
if
there's
a
file
here
who
who
needs
to
own
it,
who
needs
to
work
on
it
if
there's
a
file
there
and
so
separating
the
two,
the
two
slides
was
important
from
from
that
point
of
view,
we
have
two
teams
working
on
it
and
a
lot
of
people.
Team
members
at
github
even
refers
to
the
about
the
comm
site
as
the
handbook
or
you
know,
they
don't
differentiate
between
the
fact
that
there's
the
handbook
is
actually
a
separate
site
from
from
the
marketing
side.
A
So
we've
been
doing
this
journey
to
create
separation,
which
will
assist
in
maintenance
and
and
accountability
and
correlation.
The
the
second
principle
was
isolation.
So,
as
I
mentioned
earlier,
you
know.
Sometimes
somebody
would
make
a
change
to
the
handbook
which
breaks
the
pipelines
and
all
of
a
sudden,
you
can't
deploy
a
blog.
A
A
A
The
fact
that
our
our
website
is
is
essentially
static,
files
in
in
a
gcp
bucket
and
front
by
a
cdn,
and
so
you
know
all
these
files
are
there
together
and
so
keeping
them
in
sync,
especially
two
different
sites,
two
different
deploy
processes,
it's
a
challenge,
and
so
we've
made
a
lot
of
progress,
mostly
behind
the
scenes
you
know
like.
If
you
look
at
the
site
now,
it's
looks
like
it's
one
site.
B
A
A
In
the
short
term,
we're
gonna
also
look
to
to
migrate
from
middlemen
to
frontman
as
our
static
site,
generator
from
the
handbook,
largely
for
performance
reasons,
and
to
really
achieve
that.
We
need
to
have
clean
separation
between
marketing
and
handbook
sites,
and
so
we
need
to
go
about
the
next
steps
of
you
know.
How
do
we
break
apart?
A
There's
there's
likely
going
to
be
big
deviation
in
the
show
to
me
anyway,
and
so
we
made
the
the
kind
of
like
high
level
decision
that,
yes,
it's
okay
for
us
to
to
break
apart
and
duplicate
code
that
needs
to
be
declared
before
the
various
sites,
because
it's
likely
gonna,
gonna,
separate
and
change
drastically.
Anyway,
we
want
what
we
want
to
do
from
the
home
flip
side.
Is
we
stay
as
closely
aligned
to
the
the
brand
guidelines
and
the
brand
styling
as
possible?
A
It
doesn't
have
to
evolve
with
the
evolution
of
the
marketing
site,
but
we,
you
know
after
the
fact,
we
definitely
want
to
make
sure
we
align
with
those
and
so
the
the
big
question
that
still
remains
around
this
is
what
do
we
do
for
these
data
files
that
that'll
share
so
the
yaml,
the
helper
code,
and
all
of
that
I
think,
is
fairly
manageable,
but
the
problem
really
comes
in
with
with
this
data
files.
You
know.
A
Is
that
we'll
have
a
data
repository
for
these
data
files
and
at
full
time,
you'll
pull
them
in
as
part
of
your
bulk
process.
Nowadays,
challenges
with
that
in
in
the
sense
of
if
you
change
the
structure
of
the
data
files,
you
know
in
one
repo
and
it's
not
you're,
not
updating
the
code
in
the
reapers
that
are
reading
it.
You're
having
these
conflicts,
all
you
need
to
introduce
versioning
or
those
things.
A
So,
there's
a
lot
to
consider
with
this
as
well:
there's
local
development
environments,
making
sure
that
you
have
all
of
these
these
things
linked
in
properly.
So
there's
no
small
task
to
to
create
true
separation,
to
the
point
where
we
can
move
the
handle
to
a
separate
repo
and
as
such,
I
don't.
I
don't
necessarily
see
us
being
able
to
achieve
this
in
the
next
one
or
two
quarters
at
best.
I
I
think
we
might
be
able
to
to
get
to
to
this
point
early
next
year.
A
What
we,
what
we
really
want
to
do
from
the
handbook
site,
is
get
our
site
on
github
pages,
because
it
it's
a
great
dog
fooding
opportunity
for
gitlab
pages,
and
it
will
help
us
also
understand
the
environment
of
static
sites
on
gitlab
pages
and
and
be
able
to
help
influence
the
direction
of
the
pages.
So
that
it
meets
the
needs
of
static
sites
and
it
contributes
to
the
user
journey
that
we
want
to
create
for
static
slide,
gym,
editing
and
creation
on
gitlab
and
so
yeah.
A
A
Pipeline
expert
yeah,
he
I
she
joker.
I
actually
encouraged
him
to
to
take
on
the
the
maintainer
training
for
the
the
cia
file
the
other
day
because
he
spent
so
much
time
in
in
there.
You
know
he's
he's
been
focused
a
lot
on
the
pipeline's
caching.
How
can
we
improve
the
repo
caching
and
stuff?
I
mean
he's
gone
deep
in
that
he's
been
pioneering
the
mono
repo
restructuring.
A
For
the
last
five
six
months
and
and
and
we
know
we've
that
we've
I
mean-
we've
made
some
ux
improvements
to
the
hand,
but
that
doesn't
really
reflect
on
the
marketing
side.
But
you
know
overall,
a
lot
of
cleanup
and
stuff
and
refactorings
that's
happened
has
been
to
the
overall
benefit
of
the
repository.
A
That
said,
you
know,
like
we've,
also
introduced
a
handbook
on
all
process
to
to
help.
You
know
you
know,
win
this
pipeline
failures
or
broken
masters
for
for
the
repo,
and
sometimes
it's
related
to
the
handbook.
Sometimes
it's
not-
and
you
know,
lauren
and
brandon
has
been
helping
us
out
with
that
as
well.
So
I
think
really
between
between
them,
the
the
marketing
website
team
and
the
static
side
team.
It's
really
been
like.