►
From YouTube: How to set up GitLab groups and projects to run multiple Agile teams with microservices
Description
Trustful Finance Demo: https://gitlab.com/trustful-finance-demo
A
So
what
you
see
on
the
screen
right
now
is
an
example
application
or
a
company
and
I've
called
that
trustful
finance
and
it's
a
financial
services
company
and
it
offers
three
particular
products.
It
gives
you
a
checking
and
savings
bank
account.
It
gives
you
a
credit
card
and
you
can
take
out
loans
against
trustful
finance.
So,
basically,
as
a
customer
of
trustful
finance,
you
can
access
these
three
products
or
services
in
three
different
ways.
A
You
can
access
it
via
website
to
be
an
iPhone
app
and
via
an
Android
app,
and
so,
as
you
would
expect,
when
you
log
into
the
website
or
through
one
of
your
phone
apps,
you
would
be
able
to
access
your
account
or
you'll,
be
able
to
do
some
of
these
transactions
and
features
and
services.
So
it
probably
wouldn't
surprise
you
that
there's
a
back-end
to
do
some
type
of
logic
and
then
there's
another,
maybe
another
service.
A
So
this
is
where
the
micro
services
comes
into
play,
where
maybe
there's
a
separate
micro
service
to
handle
user
management
type
of
information
user
accounts.
So
in
a
real
world
application,
this
layer,
you
might
have.
You
know
you
know
five,
six,
maybe
even
tens
or
hundreds
of
micro
services
on
this
layer,
depending
on
the
size
and
scale
of
that
particular
company
or
offering,
and
each
of
these
services
themselves
might
be,
have
a
person,
persistence,
layer,
a
database
layer,
but
for
the
purpose
of
today's
demo,
or
just
this.
A
This
video
just
imagine
that
there's
two
micro
services
and
then
there's
a
three
additional
user
facing
customer
if
they
channels
into
this
system
and
so
right
away.
You
can
already
imagine
that
each
of
these
boxes
represents
one
code
repository
and
get
lemon.
That's
exactly
the
model
we're
going
to
to
go
with,
and
so
I'm
going
to
take
this
particular
tab
here
and
I'm
gonna.
You
know
slide
it
in
actually
so
that
you
can
actually
see
this
diagram
as
we
go
through
the
demo
here.
A
So
what
we're
gonna
do
today
is
go
through
three
particular
scenarios
of
how
you
can
set
up
your
agile
teams
and
so
I'm
gonna
click
over
here
to
this
demo
and
I'm
gonna
share
this
demo
in
the
link
in
the
in
the
YouTube
video
description.
But
what
I've
set
up
is
a
is
a
group
called
trustful
finance
demo
and
I've
set
up
three
sub
groups
representing
three
different
scenarios,
so
I'll
go
through
each
in
turn,
and
so
the
first
one
I'm
going
to
go
through
is
what
I
call
by
system
setup
your
teams
by
system.
A
So
this
is
maybe
a
more
traditional
route
of
how
you
can
divide
up
the
work
in
your
particular
organization,
and
so
what
you
have
here
so
I'm
going
to
sort
by
name.
So
it's
a
little
bit
easier
to
see.
Is
that
suppose
you
have
one
particular
team
to
handle
your
website.
Another
team
to
put
hand
alone
app
your
Android
app
another
team
dedicated
to
your
finance
logic
and
user
accounts.
A
So
in
this
sort
of
scenario
it's
not
product
driven
or
even
really
feature
driven
its
component
driven
system
driven,
so
you
might
have
a
finance
person
or
business
manager.
Saying
I
need
to
have
this
add
new.
This
feature
and
I'm
gonna
ask
this
team
to,
and
this
team
to
you
know,
set
up
the
logic
set
up
the
persistence
and
so
on
and
so
forth.
A
So
it's
it's
not
a
really
product
driven
organization,
maybe
an
Operations
driven
organization,
but
the
engineering
teams,
the
development
teams
are
classified
within
each
particular
piece
and
so
how
we've
set
it
up
is
that
we've
gotten
to
get
lab
and
within
this
group
we've
created
a
project
for
each
of
these
subsystems
and
this
project.
The
website
project,
the
service
user
accounts
project
and
so
forth,
each
system
would
have
both
issues
and
merge
requests.
A
What's
what's
important
here
is
that
each
of
these
systems
represents
a
code
repository
or
is
a
code
repository,
but
it
also
has
issues
capability.
So
what
you
would
do
is
that,
for
example,
if
you
were
the
team
responsible
for
the
finance
logic
piece,
you
would
go
into
here
and
then
you
would
create
merge,
requests
that
would
update
your
code
repository
and
you
might
even
have
issues
to
manage
that
work,
and
you
can
even
do
that
in
an
agile
way.
A
But-
and
you
can
have
sprints
and
milestones,
are
what
we
call
milestones
in
your
lab,
which
represents
sprints,
and
you
could
do
that,
and
that
would
be
fine
so
that
that's
sort
of
a
traditional
old-school
way
of
breaking
down
the
work
and
organizing
your
teams
and
I
would
even
venture
to
say
that's
not
very,
not
very
product
driven
approach.
It's
not
very
you
know
a
best
practice.
A
better
way
to
do
things
is
to
divvy
up
your
system
by
product
area,
so
this
is
a
best
practice.
A
This
is
how
you
would
divide
up
your
teams
in
your
repositories
in
a
way
so
that
it's
actually
driving
your
business
value,
so
we're
gonna
go
in
the
ground
up
and
explain
how
this
works
in
what's
interesting
is
I've
separated
the
byproduct
subgroup
here
into
two
additional
sub
groups.
So
imagine
these
three
hybrid,
byproduct
and
by
system
are
three.
You
know
different
scenarios
I'm
just
grouping
in
here
for
the
purpose
of
the
demo,
but
this
is
a
totally
different.
A
You
know
Gil
Lab
instance
or
a
group
or
what
have
you
but
there's
one
subgroup
here
that
is
specifically
called
code
and
within
that
code,
subgroup,
I've,
created
five
projects
and
each
project
represents
one
code
repository
and
the
reason
I
did.
That
is
that
you
can
imagine
each
of
these
as
as
a
as
a
micro
service
right.
A
You
know
these
would
be
you
know,
services
or
back-end
services
or
micro
services,
whatever
you
call
them,
and
these
are
you
know
your
your
front
end
customer
facing
applications,
so
you
can
actually
think
of
these
as
micro
services
as
well.
As
you
know,
your
five
micro
services
here
in
this
picture,
but
what's
important,
is
that
each
of
these
projects
would
have
their
own
set
of
merger
quests,
because
each
is
a
code
repository
or
in
Gilad
can
contain
at
most
one
code
repository.
A
So
all
your
merge
requests
for
the
web
piece
of
code
would
be
one
code
repository
now
say.
For
example,
your
website
was
required
three
code
repositories.
Then
you
would
break
this
project
into
three
projects,
or
maybe
your
your
mobile
app
had
some
shared
code
or
you're
using
xamarin
or
some.
You
know
some
cross-platform,
you
know
technology
and
you
need
additional
repositories,
and
so
you
could
do
that
you
just
so
what's.
A
What's
key
is
one
repository
one
project
you
know
which
is
equivalent
to
one
repository
and
get
lab
one
project
per
code
per
code,
repo
that
you
need
from
a
git
perspective
and
so
once
you've
set
that
up.
That's
your
basis
for
merge,
request
and
code
commits.
Then
you
can
actually
go
up
and
build
your
teams
separately.
So
that's
why
I
have
a
separate
grouping
called
teams
and
I've
created
separate
projects.
A
This
could
be,
you
know,
contributing
to
to
your
revenue
and
your
cost,
and
so
this
could
be
a
cost
center
in
itself
in
your
business.
So
this
is
super
hyper
aligned
with
your
business
and-
and
that
is
the
best
practice
today,
where
we
want
to
have
teams
delivering
business
value
and
full-stack
teams.
So,
what's
interesting
is
that
the
credit
card
team
has
all
these
capable
engineers
and
designers
and
product
managers
and
business
owners,
and
they
would
be
contributing
code
potentially
to
all
of
these
repositories
right.
A
So
the
credit
card
team,
if
there's
a
new
credit
card,
feature
that
required
you
to
maybe
set
up
a
new
user
account
and
do
some
finance
logic,
and
then
they
wanted
to
roll
out
the
feature
to
all
channels,
the
website
and
both
mobile
channels.
They
would
need
to
do
that
one
feature
and
make
changes
to
all
five
code
repositories
and
that's
okay
and
that's
encouraged
and
five.
A
You
could
have
potentially
five
merger
quests
associated
one
particular
issue
in
the
credit-card
team,
and
so
these
would
be
four
different
teams
running
four
parallel
sets
of
Sprint's
and
you
can
roll
them
up
if
you
want.
But
you
know
it's
a
little
bit
beyond
the
scope
of
this
video,
but
in
particular
I
will
show
you
how,
for
example,
this
particular
team
I've
created
a
bunch
of
issues.
So
the
checking
savings
team
has
a
bunch
of
issues
that
they
want
to
work
on
and
they
have
their
own
sprints.
A
And
so
what
we
call
milestones,
so
we
have
a
list
of
Sprint's.
Oh
and
I've
just
created
one,
and
so
this
particular
sprint
starts
yesterday.
Today's
Jan
29
for
me
and
started
yesterday.
It's
gonna
last
for
two
weeks
and
I've
created
that
sprint
and
I've
even
created
an
agile
board
to
represent
that.
So
you
can
see
here,
I'm
gonna
drag
this
out
a
little
bit
and
make
it
a
little
bit
easier
to
see,
but
you
can
see
an
agile
board
here
where
you
have
your.
A
So
you
can
see
how
you
would
run
this
particular.
Let
me
shrink
this
again.
You
would
run
this
particular
the
checking
savings
team's
Sprint's
all
by
itself.
It
would
touch
all
these
repositories
and
then
the
user
accounts
team
would
have
its
own
sprints
and
so
on
and
so
forth.
So
what's
what's
critical
there
is
that
there's
a
separation
between
code
repositories
and
work
right,
so
code
repositories
is
really
important
because
it's
we
believe
that
Gil
lab
of
best
practices-
everybody
can
contribute.
So
you
don't
want
teams
necessarily
owning
quote/unquote,
a
particular
piece
of
code.
A
It's
the
same
thing
with
the
five
different
code
repositories,
but
your
teams
are
spread
out,
such
as
with
website
and
services
and
mobile,
and
why
this
is
relevant
is
this
is
probably
your
organization
right,
so
so
what
I
just
talked
about
by
product
is
sort
of
a
best
practice.
What
you
want
to
do,
if
you're,
maybe
a
brand
new
startup
or
maybe
a
small
company
but
say
you're
like
this
example,
is
you
were
in
the
finance
Basin,
and
so
you
you've
probably
been
around
for
a
while
and
most
maybe
finance
offerings,
or
maybe
the
older.
A
You
know
financial
services
companies,
they
didn't
have
mobile
apps
in
the
in
them
in
the
past
and
they
they
just
had
a
website
offering-
and
you
know
the
same
team
would
work
on
the
website
and
the
backend
services.
So
maybe
they
had
this
code
repo.
Maybe
you
know
over
time
they
broke
out
their
their
logic
and
the
applications
into
micro
services,
which
is
great
and
they
broke
it
out,
but
their
team
is
not
gonna
change
right
and
then
then,
maybe
they
hired
new
teams
to
do
just
mobile,
because
mobile
is
a
very
specific
skill
set.
A
You
know
iOS
programming
and
your
programming,
it's
a
very
specific
skill
set,
and
so
they
didn't
have
you
know
the
folks
to
do
it
and
they
hired
specific
folks
or
maybe
it's
a
hired
contractors,
consult
consultants
to
do
that
specifically.
So
this
actually
might
be
more
realistic
in
your
particular
case
or
in
the
industry,
where
there's
a
team
that
has
always
managed
and
created
the
the
website
piece
and
the
back-end
services
and
then
there's
a
dedicated
team
just
to
create
the
iPhone
app
the
Android
app
and
they
don't
even
do
any
of
the
backend
logic.
A
A
You
know,
merger
quest
and
these
two
pieces,
and
maybe
again
it's
a
quote:
unquote:
full
stack
team,
full
stack
or
maybe
not
full
stack,
but
cross-platform
cross
mobile
platform
team
because
they're
using
you
know
a
cross-platform
technology,
or
maybe
they
have
a
dedicated
Android
engineer
and
a
dedicated
iOS
engineer,
but
but
when
to
ship
features
it
has
to
be
in
parity,
so
they
belong
on
the
same
team.
But
what's
it
what's
interesting
is
again
that's
decoupling,
so
this
team
could
still
check
in
code.
For
these
you
know
separate
repositories.
A
So
maybe
it's
a
small
piece
of
code,
a
very
small
attributed
needed
to
add
to
an
API
to
one
of
these
services,
and
they
could
do
so
and
so
again
it's
that
that
model,
where
you
don't
you're
not
holding
on
to
the
code
and
that
code
is
up
to
contributions,
are
welcome.
But
the
team
dynamic
is
such
that
it's
mostly
they
work
on
the
mobile
pieces
here,
so
so
that
that's
the
separation-
and
this
probably
makes
a
little
bit
more
sense.