►
From YouTube: Organization walkthrough - 2023-08-09
Description
High-level walkthrough of the Organization and Cells project. Find the slide deck here: https://docs.google.com/presentation/d/1uozzYikgKn6oY4QgToJwADabjAUabdt45kmU5az2-4g/edit#slide=id.g25bba3c5f29_0_0
Organization blueprint: https://docs.gitlab.com/ee/architecture/blueprints/organization/index.html
Cells blueprint: https://docs.gitlab.com/ee/architecture/blueprints/cells/index.html
A
To
give
you
a
high
level
overview
of
what
our
team
is
trying
to
do
so
this
is
us
already
introduced
us
and
I'm
gonna
get
started
on
a
high
level
overview
of
the
organization
goals
and
why
we're
building
this
in
the
first
place
and
Mike's
going
to
give
you
a
walk
down
or
walk
through
the
design
part
of
this
specific
entity,
we're
trying
to
build
all
right,
let's
get
started
so,
first
and
foremost,
what
is
an
organization?
Why
are
we
trying
to
build
this
in
the
first
place?
A
So
the
way
we
look
at
organizations
is
currently
that
it
is
a
kind
of
umbrella
for
one
or
multiple
top
level
groups
pretty
similar
to
what
is
happening
on
self-managed
instances
of
gitlab.
Today
we
see
them
as
isolated
from
each
other.
What
this
means
for
the
features
we
currently
have
in
the
product
we'll
discuss
a
bit
later
and
the
reason
why
we
need
organizations
is
because
they're
the
building
block
for
cells
I've
linked
to
a
lot
of
documentation
on
the
bottom
of
the
slides.
So
we
have
blueprints
available
for
both
the
organization
and
South.
A
A
And
the
high
level
goals
or
the
problems
we're
trying
to
solve
with
organizations
are
listed
here,
so
one
I've
already
mentioned
that
is
going
to
be
quite
beneficial,
is
that
it
enables
grouping
of
top
level
groups.
This
means
once
we
create
the
organization
gitlab.
This
will
also
include
the
top
level
groups
that
are
currently
part
of
of
our
organization
or
company
gitlab,
for
instance,
gitlab.org
or
gitlab.com.
A
We
also
want
to
have
more
isolation
and
we
need
these
clear
boundaries
between
organizations
to
move
them
onto
cells.
This
will
make
sense
once
I
walk
you
through
the
next
one
or
two
slides.
This
is
very
similar
to
how
staff
managed
instances
work.
A
We're
also
expecting
improved
performance
and
availability,
because
items
are
scoped
an
organization
that
means
there's
less
data
to
search
through.
You
don't
have
to
look
at
all
of
gitlab
anymore.
You
can
look
specifically
at
an
organization
because
things
will
be
linked
to
an
organization
ID
and
because
of
the
increased
isolation.
A
A
I've
mentioned
that
already
organizations
enable
us
to
have
a
place
where
you
can
control
user
profiles
from
an
organization
angle,
because
it
will
be
scoped
to
the
organization
and
basically,
they
bring
you
an
on-premise
like
experience
as
we
have
it
on
self-managed
to
SAS
or
gitlab.com,
and
the
organization
owner
in
that
context
will
have
access
to
features
that
are
currently
just
available
to
the
admin
that
is
able
to
access
the
admin
area
settings
on
self-managed
instances.
A
What
is
a
cell,
so
a
sellus
I
would
say
one
level
higher
than
the
organization.
It's
a
scaling
solution,
we're
looking
into
a
horizontal
scaling
solution.
In
that
case,
we've
already
worked
on
database
decompositions
to
keep
up
with
vertical
scaling,
but
this
only
reaches
that
far.
So
we
need
something
that
can
scale
with
the
size
of
our
company.
Basically
we're
expecting
sales
to
be
very
resilient
to
be
independent
from
each
other
and
they
can
contain
one
or
multiple
organizations.
A
Why
do
we
need
cells?
Well,
as
I
already
mentioned,
the
decomposition
work
that
our
team
and
other
teams
have
looked
into
in
the
past
can
only
deliver
quite
a
limited
amount
of
scalability.
A
So
there
is
a
limit
to
how
far
we
can
push
that
and
we
need
a
more
long-term
oriented
scalability
strategy
so
that
we
can
keep
up
with
the
growth
of
the
business
as
it's
currently
happening,
and
this
sales
architecture
creates
many
isolated,
gitlab
instances
that
include
all
the
required
services
so
that
they
can
essentially
Grow
With
US
alongside
the
growth
of
the
business
and
as
I
have
mentioned
already.
The
other
possible
benefits
are
improved
service
availability.
A
There's
a
lot
of
use
cases
we
can
expand
into
once
this
exists
and
the
way
you
can
imagine
it
is
drawn
out
here
is
that
there's
some
very
essential
data
that
we
have
distributed
across
shared
a
shared
layer.
We
call
it
the
cluster
layer
or
the
cluster-wide
database
that
feeds
into
isolated
cells
and
on
these
cells.
You
have
different
organizations
so
just
to
get
the
terminology
right
and
with
that
I'm
always
I'm
already
going
to
hand
over
to
Mike.
B
Sure
so,
in
general,
we've
taken
kind
of
an
MBC
approach,
really
targeted
at
meeting,
basically
the
minimum
that
we
need
for
an
MBC
to
unblock
cells
and
by
and
large,
we're
taking
a
lift
and
shift
approach
where
we
can
taking
inspiration
from,
in
some
cases,
the
admin
area
in
some
cases
groups,
but
in
general
we
kind
of
defaulted
to
existing
screens
where
we
could
and
leverage
as
much
as
we
could.
So
we
can
reuse
without
having
to
rebuild
too
much.
B
But
looking
at
organizations
the
object
themselves,
I'll
go
through
a
couple
of
screens
from
that.
So
this
first
one
here
is
the
organization
home
page
fairly.
Straightforward
just
has
quick
links
for
groups,
projects
and
users
and
then
shows
a
group
and
project
list
that
can
be
selected
between
frequently
visited
groups
and
frequently
visited
projects.
B
Okay,
excellent,
we
also
have
an
activity
page,
so
this
is
kind
of
a
overall
arching
activity,
page
of
the
entire
organization,
so
displays
activity
within
the
organization,
and
we
will
be
introducing
some
filters
by
contribution
type
down.
The
road
we'll
also
have
a
groups
and
projects
page.
B
This
is
kind
of
the
directory
of
the
organization,
so
listing
of
all
of
the
groups
and
projects
that
are
contained
within
the
organization,
and
then
we
also
have
the
ability
to
filter
by
the
ability
to
see
groups
or
projects
kind
of
combining
the
groups
and
projects
page
together.
But
in
this
first
implementation,
it'll
be
through
a
filter.
B
We'll
also
have
a
list
of
users,
so
it
displays
an
aggregated
list
of
users
within
the
organization.
These
are
sourced
from
the
groups
and
project
members
that
that
the
organization
contains,
and
also
the
possibility
of
directly
invited
users
as
well.
B
Also
settings
pretty
minimal
settings
here
again
going
for
that
what
it's
just
needed
for
the
NBC,
so
things
like
the
organization
name,
a
description,
an
avatar
and
then
maybe
the
ability
to
change
the
organization.
Url.
B
B
So
this
switcher
allows
you
the
user
to
navigate
between
organizations.
It
provides
users
with
a
path
to
get
to
the
actual
organization,
object
itself
defaults
on
the
home
page
there,
but
also,
maybe
most
importantly,
provides
context
to
the
user
of
what
organization
that
they're
in
since
users
are
now
going
to
be
in
this
world,
where
changing
organization
does
have
impacts
on
what
you
can
see.
It's
important
to
have
a
fairly
visible
upfront
kind
of
indication
of
what
organization
that
you're
currently
looking
at
to
serves.
That
purpose
as
well.
B
So
here
is
an
example
of
what
it
looks
like
if
you
were
to
click
on
it.
So
opening
up
it'll
be
a
drop
down.
It'll
show
your
current
organization
and
allow
you
to
switch
to
other
organizations
that
you
are
a
member
of
your
user
in
and
then
just
some
more
context
to
show
how
this
does
impact
some
of
the
other
screens
that
we
see
across
gitlab.
So
things
like
your
work
will
be
scoped
to
that
organization.
B
So
you
might
not
see
everything
from
every
organization
when
you're
in
a
particular
organization,
in
your
work
that
will
be
scoped
to
your
current
organization
and
that
pattern
kind
of
applies
to
several
of
or
really
all
of
the
screens
pages
that
we
have
in
GitHub.
B
And
then
there
are
a
few
other
things:
that'll
that'll
happen,
Beyond
just
that
switcher
the
breadcrumbs
will
be
affected.
The
organization
will
be
added
to
the
beginning
of
of
the
breadcrumb
there
and
then
in
the
global
search
as
well.
It'll
provide
another
secondary
path
to
get
to
again
here.
You're
trying
to
get
to
the
organization
object
the
home
page,
really.
A
A
The
paths
will
not
change,
because
we
have
heard
a
lot
of
concerns
from
users
and
the
impact
of
that
would
be
quite
severe
if
the
organization
would
change
every
single
group
and
project
path
that
currently
exists.
That's
why
we
keep
them
separate,
but
in
the
breadcrumbs
you
will
be
able
to
see
the
connection.
A
A
A
We
will
approach
the
teams
that
own
the
various
features
that
are
affected
by
this
and
work
together
with
them
to
find
Solutions.
We
have
already
looked
at
quite
a
long
list
of
features.
This
is
all
documented
in
the
sales
blueprint
most
of
them
will
be
scoped
to
the
organization,
as
Mike
has
already
mentioned.
In
the
design.
Walkthrough
things
like
to
Do's
issues,
merge
requests,
they
will
all
be
scoped
to
the
organization.
So
the
number
you
see
in
the
header,
on
the
left
hand,
side,
is
tailored
to
this
specific
Organization.
A
Now
it
threw
me
a
couple
of
slides
ahead
all
right
back
to
this.
The
same
is
the
case
for
the
user
profile.
So
you
will
see
the
contributions
of
the
user
to
a
specific
organization
and
can
then
switch
to
another
organization.
If
you
want
to
see
that
user's
contributions
there,
we
know
that
this
has
some
consequences
for
users
that
work
across
a
lot
of
organizations
I'm
going
to
get
to
that
in
a
minute.
A
Generally,
users
will
need
to
switch
when
they
work
between
different
organizations
and
there's
also
a
couple
of
features
we
still
discuss
at
the
moment
and
are
trying
to
develop
solution.
Proposals
for
amongst
them
are
forking
personal
namespaces.
A
We
looked
at
Snippets
as
well,
but
I
think
what
is
better
in
that
context
is
to
make
a
separate
walkthrough
for
all
the
features
we
have
looked
at
so
that
you
have
some
idea
what
the
impacts
are
specifically
for
that,
so
I
think
we'll
make
it
in
a
couple
of
shorter
videos
for
Snippets,
Explorer
and
so
on,
so
that
you
can
look
at
it
there.
Otherwise
this
would
become
a
bit
too
lengthy.
A
Why
do
we
think
it
is
okay
to
break
things
in
that
way?
It's
probably
a
question
that
arises.
As
you
hear
about
all
of
this.
A
There
was
some
initial
data
exploration
we
did
and
also
some
initial
user
research
that
our
designers
have
done,
and
we
have
seen
in
both
the
data
exploration
and
the
feedback
from
users
that
the
majority
of
users
is
actually
only
associated
with
a
single
organization,
and
they
don't
see
it
as
a
problem
to
have
to
switch
context
between
multiple
organizations.
If
they
do
so,
we
have
looked
on
a
data
from
Stars,
specifically
and
98
of
users
were
only
associated
with
a
single
organization.
So
in
that
case
we
have
modeled
how
many
top
level
groups
form.
A
One
organization
and
78
of
users
are
only
members
of
a
single
top
level
group.
So
that's
really
the
biggest
chunk
of
our
users.
A
There's
a
very
few
links
between
top
level
groups.
Only
0.5
percent
I
think
it
was
actually
less
than
0.5
percent
of
them
share
links
across
top
level
groups.
I,
don't
know
exactly
how
many
of
them
would
belong
to
the
same
organization.
There's
a
limit
to
how
far
we
can
push
this,
because
we
cannot
match
every
top
level
group
to
an
organization
that
we
know
so
those
are
estimations.
A
But
this
is
what
we
have
seen
from
those,
and
even
if
users
have
multiple
top
level
groups
that
can
be
matched
to
an
organization,
the
median
it's
distributed,
of
course,
but
the
median
number
was
around
three.
So
even
if
you
have
to
go
and
manage
across
multiple
top
level
groups,
it's
still
in
an
area
that
is
manageable.
So
it's
not
hundreds
though
we
do
have
users,
at
least
from
what
I
have
heard
on
self-managed,
that
have
hundreds
of
top
level
groups.
A
Another
aspect
that
is
going
to
be
impacted
is
global.
Discoverability.
This
matters
in
the
context
of
Open
Source
contributions.
We
have
discussed
this
with
the
contributor
success
team
already
currently
explore
and
search
go
across
everything
that's
on
gitlab.com,
but
those
will
be
scoped
to
the
organization
to
start
with.
A
We
don't
think
this
is
a
problem
initially,
as
this
only
becomes
a
bigger
problem,
as
more
organizations
start
to
exist
in
the
beginning,
there
will
just
be
one
default
organization,
so
to
speak,
so
you
will
be
able
to
search
across
everything
you
know,
and
only
as
people
start
moving
content
into
separate
organizations.
A
A
A
Last
but
not
least,
a
little
bit
of
an
Outlook
into
our
current
roadmap,
we're
very
busy
working
towards
the
organization
MVC
release.
What
the
MVC
exactly
should
contain
is
defined
in
the
organization
blueprint.
We
have
divided
that
into
three
experimental
phases:
prototype
experiment
and
beta
So.
Currently
we're
doing
everything
we
can
to
build
out
the
Prototype,
hopefully
by
the
end
of
October,
will
then
spend
another
couple
of
Milestones
to
add
more
functionality.
This
is
all
defined
in
the
blueprint
and
working
towards
releasing
the
MVC,
hopefully
by
q1
2025.
A
So
at
some
point
between
the
end
of
January
next
year
and
the
beginning
of
April,
we
were,
we
are
working
on
cells
in
parallel.
There's
a
lot
of
work
streams
that
we're
trying
to
work
through
to
add
functionality
to
cells.
Currently
we're
working
on
the
ability
to
create
a
group
on
a
cell
moving
to
the
ability
to
create
a
project
on
a
cell
in
the
current
quarter
and
also
looking
into
routing
I
think
there's
more
than
10
different
work
streams.
A
So
we
also
looking
into
how
we
can
divide
the
outstanding
work
for
the
next
quarters
and
we
will
need
help
from
other
teams
to
look
into
their
specific
feature
areas,
for
instance
the
ability
to
push
into
a
cell.
That,
probably,
is
something
the
source
code
team
needs
to
help
us
with
and
there's
more
of
these
sub
work
streams
that
we
will
approach
other
teams
and
then
start
solutioning
together
with
them
to
help
us
build
this
out.
A
A
If
you
have
questions,
you
can
always
raise
NMR
against
those
approach
me
or
approach
Mike
or
find
us
in
the
tenant
scale,
slack
Channel
and
we're
happy
to
answer
any
questions
and
are
looking
forward
to
Future
discussions
with
you.
So
with
that,
thank
you
and
we'll
share
more
details
in
upcoming
videos.