►
From YouTube: How To Build Production Grade DevOps Platform Usin... Alexander Matyushentsev & Leonardo Luz Almeida
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
How To Build Production Grade DevOps Platform Using Argoproj - Alexander Matyushentsev, Akuity & Leonardo Luz Almeida, Intuit
Argo is an established CNCF project that helps hundreds of engineers to use Kubernetes. The project covers many use cases, from GitOps-based continuous deployment to event-based workflow automation, and can be used to create a powerful DevOps platform. However, it requires integration with various other systems and can be done in several ways. So what is the best way? We, maintainers of a project, spoke with dozens of users and learned the best patterns that worked really well and managed to scale to support large enterprise needs. In this session, we will demonstrate a production-grade Argo-based DevOps platform for Kubernetes. We will walk you through every key decision incorporated into the solution and highlight the pros and cons of every decision made. You can expect to learn a lot of useful tricks and well as enjoy an impressive demo and have fun!
A
I
can
provide
my
desired
state
in
a
yaml
file
in
case
of
kubernetes,
and
then
we
can
collaborate
together
and
store
those
files
in
git
and
somehow
provide
this.
This
desired
state
of
my
infrastructure
to
kubernetes
the
thing
is
kubernetes
does
not
provide
out
of
a
box
a
way
for
extracting
this,
this
last
state
from
git
and
that's
exactly
where
hargo
City
comes
into
place
right,
Argo
City
is
has
exactly
this
responsibility
to
to
get
the
to
interface
with
with
your
git
provider,
and
it
will
provide
it
will
present
this.
A
This
latest
state
of
your
infrastructure
to
kubernetes
and
kubernetes
will
kick
off
the
the
reconciliation
Loop
to
to
to
bring
up
your
desired
State
into
the
live.
State.
Okay
and,
let's
say
I
convince
you
to
go
with
Argo
CD
and
what
is
the
first
decision
you
have
to
make
which
git
repo
to
use
right?
This
is
the
first
question
you
have
to
answer
and
we
basically
understand
that
our
there
are
two
two
different
approaches
you
can
take
here.
A
One
is
dumping
everything
in
one
single
repo,
meaning
you're,
going
to
be
using
the
same
repo,
where
you
have
all
your
source
code
to
to
to
store
your
your
manifest
files,
your
your
infrastructure
configurations
or
you
can
use
an
independent
repo,
which
is
totally
disconnected
from
your
source
code
and
to
to
to
store
this.
These
configuration
files
right,
maybe
intuitively
you
might
go
with
the
first
option.
A
This
is
what
I
did
when
I
first
installed
Lego
City
myself,
and
let
me
show
you
what
are
the
the
pros
and
cons
of
this
approach
so
basically
with
a
centralized
repo.
One
of
the
one
of
the
one
of
the
pros
right
is
that
things
are
placed
in
the
same
Ripple.
Obviously
right,
you
can
just
open
a
folder
and
see
what
is
the
current
configuration
of
your
production
environment.
This
is
really
is
in
the
same
repo,
where
you
have
all
your
source
code,
which
is
great.
A
So
we
understand
that
the
authorization
model
might
be
harder
to
to
to
to
to
define
basically
because
most
of
the
times,
the
role
of
the
the
the
the
member
of
your
team,
who
has
asked
who
has
access
to
to
commit
and
merge
code
in
in
your
master,
Branch
or
your
main
branch,
is
not
the
same.
It's
the
same
role
of
the
person
who
has
the
the
permission
to
deploy
and
change
things
in
production
right.
A
So
if
you're,
if
you're
opting
to
to
get
to
to
get
installed,
something
like
Argo
CD
is
probably
because
you
want
to
have
a
continuous
deployment
and
by
that
it
means
every
merge
to
the
main
branch
will
trigger
a
job
that
will
build
your
application
and
create
a
new
version.
But
then
you
have
to
update
the
configuration
files
again
and
which
will
trigger
the
job.
A
So
if
you
want
to
extract
a
report
to
who
changed,
which
which
resource
in
in
production
and
when
it's
going
to
be
a
little
bit
harder
for
for
extract
that,
if
you
have
a
mix,
a
mixed
report
right,
a
centralizer,
okay,
moving
forward,
what
let's
see
how
it
looks
like
if
we
go
with
an
independent
repo
right?
So
what
are
the?
What
are
the
advantages
in
this
case?
It's
it's
a
simpler
PCI
or
no
CI
at
all.
A
You
we
understand
that
you
don't
necessarily
need
the
CI,
so
you
can,
if
you,
if
you
have
a
total
independent
repo,
like
your
application,
underscore
deployment
and
you
dump
your
manifest
in
there.
You
can
just
configure
Ardo
CD
to
watch
this.
This
repo,
like
the
main
branch,
every
every
single
comment
that
it
get
that
gets
pushed
to
the
to
the
main
branch,
will
trigger
Argo
CD
sync
process
which
will
update
your
cluster.
So
you
don't
necessarily
need
a
CI
in
this
case
in
simple
places
right.
A
So
this
is
also
going
to
be
provide
you
a
much
easier
authorization
model
capabilities
because
now
you're
not
tied
to
the
same
repo,
where
you
have
your
source
code.
Now
you
have
the
entire
repository,
so
you
can
leverage.
Let's
say
you
use
GitHub,
you
can
leverage
already
available
GitHub
features
to
to
decide
who
can
do
what
who
can
merge
what
branch
protection
yeah.
There
are
many
features
to
help
you
with
that,
and
it
will
provide
you
a
cleaner
history.
A
One
disadvantage
is
that
in
this
case,
yeah
you're
gonna
have
to
deal
with
the
two
different
repositories.
It's
not
it's
not
going
to
be
centralized.
If
that's
an
issue,
we
don't,
we
don't
think
it
justifies
all
the
advantages
we
have
cool.
Let's
say:
I
convinced
you
to
go
with
an
independent
repo.
What
is
the
next
problem
right?
You
might
run
through.
You
need
to
decide
what
is
the
layout?
What
are
the
files
that
you're
going
to
be
dumping
in
this
deployment?
A
So
this
is
something
that
you
can
easily
easily
get
from
customize
and
then
it's
very
very
easy
to
just
configure
Argo
CD
to
watch
those
specific
folders,
or
maybe
you
have
that
in
specific
namespaces
and
deploy
in
sorry
specific
branches,
and
then
you
can
configure
Argo
City
to
deploy
in
specific
namespace
and
specific
clusters
right.
Okay,
let's
say
you're
good
with
this,
but
now
you
want
to
protect
your
application,
your
team
to
to
interfere
with
other
teams
right.
You
want
to
provide
some
sort
of
a
multi-tenancy.
How
can
argocd
help
you
with
that?
A
So
Argo
City
provides
this
this.
It's
a
different
crd
in
our
gocity
project,
called
project
where
you
can
Define
things
like
who
who
is
allowed
to
to
to
use
this
project
who
which
git
repos
are
allowed
to
be
to
be
read
from
this
project?
Define
our
backs
Define?
What
are
the
Target
clusters
that
can
be
configured
to
deploy
applications
assigned
to
this
project,
and
then
you
can
have
your
existing
application
and
assigned
to
those
projects
to
kind
of
protect
your
environment
in
a
good
way
right.
A
So
there's
one
there's
still
one
missing
piece
here:
I
mentioned
about
our
back
I
mentioned
about
users
having
permission,
but
for
that
to
be
possible.
I
need
to
somehow
have
some
authentication
in
place.
I
need
I
need
to
I
need
to
have
users
assigned
to
roles,
so
I
can
properly
configure
this
rpac,
and
this
is
exactly
how
Alex
is
going
to
join
this
conversation.
This
presentation,
providing
this
Hands-On
section
with
ulx
cool.
C
C
Into
details,
I
want
to
describe
my
requirements
for
that
algo
CD
and,
as
Leo
said,
if
we
want
to
provide
it
for
the
whole
organization,
it
has
to
be
multi-tenant
and
what
that
means
is
rbcd
has
to
be
able
to
serve
lots
of
teams,
and
teams
has
to
be
protected
from
each
other.
Basically,
I
don't
want
anyone
accidentally
deleting
someone
else's
production,
and
things
like
that
and
next
I
want
to
provide
a
good
experience
to
the
teams.
It's
usually
security
is
never
convenient
and
but
I
do
want
to
have
very
seamless,
onboarding
process.
C
So
every
team
can
understand
board
themselves
to
Argo
CG
plus
I
want
to
take
care
of
a
platform
team
I,
don't
want
them
to
work
too
hard
to
do
it
and
that's
why
I
want
to
have
this
process
as
self-service
as
possible.
Thank
you
and
with
that,
let's
talk
about
things
that
we
will
have
to
manage
and
then
later
on,
we
can
talk
about
how
we're
going
to
manage
those
things.
So
the
very
first
thing
that
we
would
have
to
configure
is
authentication
and
if
you
ever
installed,
Target
CG
in
your
mini
Cube
cluster.
C
C
The
system
is
called
system
accounts
because
it's
meant
for
API,
Integrations
and
usually
organizations
uses
it
to
automate
elbow
CD
settings
management,
and
we
really
do
not
want
to
you
to
use
accounts
to
provide
multi-tenancy
in
production
so,
and
there
are
a
ton
of
reasons
to
use
SSO
and
identity
provider.
If
you're
a
member
of
a
platform
team
you're
going
to
be
really
glad,
you
made
the
decision
to
use
identity
provider.
The
main
reason
is
you
just
boost.
C
You
save
yourself
yourself,
a
ton
of
time
by
not
by
pushing
away
this
work
of
managing
you
know
of
user
management.
Basically,
you
won't
not
be
responsible
for
storing
users.
You
will
not
have
to
resolve
tickets.
To
add
one
member
from
you
know,
move
member
from
one
group
to
another
group
and
basically
that's
why
Arbor
City
takes
a
single
sign-on
so
seriously
and
few
words
about
how
to
configure
it.
So
the
main
integration
point
for
Argo
CG
there's
any
identity
provider
is
oedc
protocol
and
basically
you
have
a
ton
of
choices.
C
Algor
CD
will
be
connected
with
your
SSO
provider
and
even
if
you
do
not
have
ODC,
you
still
can
connect
rbcd
to
your
provider
through
a
awesome
project
called
Dex,
which
is
bounded
into
algocd
and
I'm,
going
to
actually
use
Dex
in
the
demo
part.
So
we
will
see
how
easy
it
is
to
configure
single
thing
on
this
provider
like
GitHub,
so
once
we're
done
with
authentication.
The
next
question
is:
how
do
we
authorize
our
users?
How
do
we
link
the
oedc
group
that
SSO
provides
to
the
user
once
login
is
complete?
C
How
do
we
map
map
it
to
some
our
bug,
configuration
and
here
argocg
again
decided
not
to
reinvent
the
wheel,
so
we
are
not
building
any
custom
airbag
solution.
Instead,
Albus
CDL
leverages
an
awesome
project
called
has
been,
which
is
an
engine
that
lets.
You
manage
your
kind
of
Access
Control
configuration,
so
husband
allows
to
configure
a
bunch
of
access
models
such
as
a
bug
or
bug
ACL,
and
so
at
Argo
CG.
If
you
made
a
decision
to
use
our
back,
this
cannot
be
changed.
C
However,
you
can
use,
has
been
configuration
language
to
Define
our
back
rules,
and
this
snippet
here
has
the
search
the
same
purpose.
It's
really
easy
to
use
has
been
an
easy
used
to
configure
has
been
it's.
It's
not
yaml
this
time,
it's
just
a
little
a
CSS
like
a
file
that
lets
you
define
groups
and
policies,
assign
policies
to
groups-
and
my
point
here
is
that
it's
super
flexible.
Basically,
you
can
assume
that
you
will
be
able
to
achieve
a
very
complex
use.
C
Cases
related
to
your
bug,
using
casbin,
and
if
you
understand
that
that
project,
you
might
leverage
that
knowledge
in
some
other
systems,
because
it's
used
pretty
widely
in
some
other
systems,
and
so
now
we
have
authentication
and
authorization
we
get
to
make
them
work
together,
and
this
is
maybe
the
last
important
concept
that
we
have
to
learn
before
we
jump
into
the
demo.
That
concept
is
called
our
gocg
project
and
it's
pretty
much
the
core
of
Fargo
CD
multi-tenancy
functionality.
C
It
lets
you
take
your
configured
SSO
and
your
back
settings
and
kind
of
link
them
together,
make
them
work
together
and
what
you
can
do
using
project
is,
you
can
group
a
bunch
of
applications
and
what
that
means
is
every
application
belongs
to
one
and
only
one
project.
Next,
you
can
Define
boundaries
on
the
project
and
those
boundaries
will
be
enforced
on
every
application
that
belongs
to
a
project
and
you
can
limit
which
source
repositories
can
be
used
as
a
source
of
manifest
for
every
application.
C
You
can
decide
which
name
spaces
those
manifests
can
be
deployed
to
and
in
most
in
in
many
cases,
and
we
suggest
to
use
this
approach.
Users
use
project
to
represent
a
team.
Basically,
you
can
create
a
project
per
team,
Define,
a
set
of
infrastructure
that
team
managers
and
let
them
use
the
source
repository
that
they
use
to
manage
the
kubernetes
configuration,
and
so
once
you
have
this
boundaries
set
up.
All
you
have
to
do.
C
C
That
probably
represents
one
team
and
that
team
has
access
to
a
project
and
you
can
use
cast
bin
to
provide
fine
grain
access
to
the
users
of
the
team
within
a
project
and
so
having
those
three
things
we
pretty
much
can
solve
the
requirements
that
we've
described
before
we
can
get
the
multi-tenant
lgd
instance.
The
question
is:
how
are
we
going
to
manage
it
and
I
think
this
is
the
whole
purpose
of
that
presentation.
C
It
took
us
some
time
to
get
here,
but
so
main
point
is
to
convince
convince
you
that
you
do
not
want
to
use
tickets
to
to
manage
all
of
that
like
to
manage
our
back
SSO
and
then
projects
and
some
other
things
that,
as
you
will
see
in
the
future
in
shortly,
so
you
kind
of
give
a
little
bit
more
color
to
the
problem.
So,
of
course
you
can
you
can
set
up
a
jira
project.
You
can
tell
to
your.
C
You
know
your
users
that
every
time
they
need
to
get
access
to
Argo,
CD
they're
supposed
to
create
a
ticket,
and
then
someone
from
the
platform
team
will
respond
to
the
ticket
and
make
changes,
but
in
real
life,
maybe
maybe
like
six
months
later,
you
will
realize
that
our
qcd
is
a
critical
piece
of
infrastructure
that
touches
very
sensitive,
manages
sensitive
configurations.
So
that's
why
each
and
every
change
in
argue
CD
must
be
stored
in
some
audit
system.
You
want
to
have
some
approval
process
you
want
to.
C
You
want
to
take
care
of
the
settings
that
you
as
a
platform
team
apply
to
algocg,
and
those
changes
also
has
to
be
stored
in
in
some
form
of
auditing
system,
and,
if
you
take
into
account
those
requirements,
then
it's
it's
kind
of
too
it's
already
frustrating
enough
to
try
to
do
better
and
luckily,
for
us
there
is
a
better
process
that
we
call
githubs,
and
so
the
biggest
question
is:
can
we
use
githubs
to
manage
algocd
configuration
and
answer?
Is
we
definitely
can
and
the
reason
is
Argo
CG
has
no
database
behind
it.
C
So
they
would
like
this
approach
as
well,
and
that
makes
everyone
happy
so
now
it's
time
to
see
it
in
action.
Finally,
this
barcode
is
for
you,
if
you
want
to
do
the
demo
after
the
talk,
if
you
want
to
play
with
it,
just
take
a
screenshot,
maybe-
and
it
will
lead
you
to
this
URL-
that
I'm
going
to
open
right
now
and
the
URL
is
a
git
Repository.
C
The
name
of
this
repo
is
control
plane
and
let
me
describe
like
why
I
chose
this
name.
So
the
reason
is
this:
repository
is
going
to
have
a
bunch
of
kubernetes
manifests
that
describe
everything
that
platform
team
manages.
So
if
you
look
at
the
content
of
it,
you
will
see
folders
like
cargo
CD
and
by
the
name.
You
can
guess
it's
going
to
manage,
Argo
CG
configuration
and
next
it
has
clusters,
and
so
it
will.
C
The
Clusters
folder
is
going
to
have
everything
that
platform
team
manages
for
end
users
in
the
Target,
managed
clusters
and
I
will
describe
shortly
why
it
is
important.
So
next
we
can
switch
to
the
readme
file
and
readme
is
pretty
much
a
step-by-step
instructions
of
it's
a
script
of
the
demo.
I
already
finished
the
preparation
part
I
installed
a
kubernetes
I
just
use
kts
cluster
I
installed
arborcg
into
this
cluster
and
then
I
configured
Argo
CD
to
manage
Itself
by
running
this
skip
teacher,
apply
command
that
simply
in
inserted
this
yaml
file.
C
It
applied
the
CML
file
into
the
Argo
CG
namespace,
and
so
let's
take
a
look
at
this
file.
Let's
see
what
it
has
so
and
here
it's
the
just
argocd
application
that
still
tells
our
gocg
to
watch
this
same
repository,
look
into
the
Argo
CD
folder
and
push
everything
from
that
folder
into
the
Argosy
genome
space
and
that's
pretty
much
everything
we
need
to
get
this
self-managed
setup.
So
now,
rgcg
is
configured
to
manage
itself
and
from
the
beginning,
I
kind
of
took
advantage
of
it
and
I
created
couple
more
yaml
files.
C
Here
one
is
Argo
CD
CM,
which
is
a
good
CG.
Config
map
and
I
did
configure
SSO
using
Dex
and
I
connected
it
to
GitHub,
and
so
it
really
it's
so
easy.
So,
there's
nothing
to
learn
about
it.
You
need
to
create
a
GitHub
of
zero
application
of
two
application
and
configure
a
couple
of
Secrets
here
and
that's
it.
C
Ergocg
is
going
to
know
how
to
talk
to
GitHub
and
Dex
is
already
bundled
in
Darker
CD,
so
you
don't
even
have
to
configure
decks
itself
next
I
needed
to
create
myself,
SSO
powered
administrator
and
I
to
do
so.
I
created
another
config
map
that
defines
our
back
rules
and
here
I
give
admin
permissions
to
Argo
itself,
because
I
have
access
to
that
account.
I
can't
use
it
for
for
demos
all
right.
Sorry
about
that.
C
Now,
it's
time
to
see
it
in
action,
so
this
is
Argo
Ergo
account
and
I
want
to
go
ahead
and
prove
you
that
it,
the
SSO
works.
So
if
I
click
login
yeah
SSO
worked
so
we
were
able
to
log
in
and
because
this
user
is
admin,
it
can
see
everything.
So
in
case
you
don't
know,
this
is
how
Argo
CD
user
interface
looks
like.
It
is
showing
me
an
application
that
manages
Argo
CD
itself.
If
I
click
on
it,
you
can
see
that
it
does
manage.
C
Instead
of
creating
a
ticket,
I
want
to
use
githubs
and
I'm
just
going
to
do
it
right
now,
so
I'm
going
to
make
a
change
in
the
git
Repository
and
here
I'm
kind
of
providing
you
a
convention
that
worked
for
even
a
big
company.
So
you
can
just
have
a
project
folder
in
your
under
your
Argo
CG
directory,
and
you
can
have
a
convention
to
have
a
project
per
team,
and
so
the
onboarding
process
is
to
just
the
copy.
You
know
copy
like
a
sample
file
and
provide
team.
C
C
How
to
make
a
mistake,
so
the
I
uncommented
it
created
PR
I,
will
show
you
the
content
of
this
file
shortly
when
I
switch
back
to
my
admin,
shoes
and
I'm,
trying
to
review
this
pull
request,
and
so
now
I'm,
acting
as
a
argosity
administrator
and
instead
of
reading
the
description
and
the
ticket
and
trying
to
understand
what
the
user
wants.
I
kind
of
I
have
already
a
work
done
for
me.
C
I
just
need
to
validate
that
it's
meaningful
and
and
maybe
make
sure
that
the
person
who
created
it
follows
the
convention,
and
so
here
I
have
a
project
which
name
matches
to
the
team
name.
It
allows
this
team
to
manage
whatever
repo
they
want
use
whatever
repo
they
want
to
manage
the
manifests
and
it
allows
the
team
to
deploy
applications
from
the
triple
into
any
m
space.
That
starts
with
a
prefix
that
matches
to
a
team
name,
which
is
another
powerful
convention
that
might
be
useful
for
you.
C
This
way
you
don't
have
to
you
know,
manage
each
and
every
change.
You
kind
of
give
a
little
bit
of
flexibility
here
and
it's
still
lets
you
separate
teams
from
each
other.
So
let's
say
I
like
this
pull
request,
oh
and
by
the
way
here,
I'm
also
I'm,
explaining
to
admin
that
hey
the
members
of
the
team
are
going
to
be
part
of
this
group
and
for
the
sake
of
them,
I
just
choose
email
to
be
a
group,
so
it
will
only
write
list
me
all
right.
C
So
if
I
like
everything
here,
all
I
need
to
do.
I
just
need
to
merge
this
pull
request
and
approve
and
merge
it.
So
now
we
have
audit
of
this
change
next,
if
I
switch
to
algor
CG
I
have
to
click
this
refresh
button.
Just
to
save
us
like
three
minutes
of
time,
because
I'll
go
CD
check
it
every
three
minutes,
and
so,
if
I
switch
back
to.
C
Argo
CG,
as
a
user,
you
can
see
now
that
I
have
a
project
available
for
me
for
pretty
much
our
board
and
boarding
is
done
now.
I
am
as
a
developer,
ready
to
use
ergocd
I
can
create
application.
So
I
can
have
this
pre-previewed
to
save
time,
but
I
do
want
to
show
you
that
I'm
using
the
right
repository
and
I
am
going
to
deploy
into
namespace.
That
starts
with
my
team
name,
and
let's
pretend
it's
my
Dev
environment,
so
I'm
going
to
give
it.
You
know
a
suffix
scope.
B
C
So
I
because
arbuck
is
working,
I
can
create
this
application
and
let's
go
ahead
and
deploy
it
and
that's
intentional:
it's
not
the
demo
fail.
It's
failed
because
we
still
have
a
lot
of
other
things
to
do
like
it's
not
enough
to
just
configure
a
our
back.
We
also
need
to
get
some
cluster
level
resources
like
namespace,
for
example.
So
I
chose
this
namespace
GMA
Dev,
but
no
one
created
it
for
me
and
you
might
also
you
might.
C
You
might
use
tickets
to
create
namespaces,
but
it's
going
to
be
the
same
pain
as
the
projects
plus.
This
problem
is
like
extremely
it's
very
similar
to
the
problem
of
managing
Karbach,
so
I
want
to
convince
you
to
use
githubs
to
manage
cluster
level
resources
as
well,
and
the
reason
is
Argo
has
a
great
support
for
it
for
the
use
case,
the
only
problem,
the
only
difference
of
managing
cluster
level
resources
is
that
those
resources
are
not
part
of
Fargo
CD
namespace.
C
So
you
would
have
to
create
a
separate
set
of
applications
for
each
and
every
cluster,
and
that's
a
lot
of
I
mean
manual.
Work
for
administrators
and
Argo.
Cg
has
an
answer.
That's
so
a
little
bit
reduce
the
Spain
answer
is
called
application
set.
So
application
set
is
a
admin
tool
that
helps
you
to
automate
application
creation,
and
this
is
the
application
set
that
I
already
had
in
in
this
repository.
C
I
just
need
to
push
it
and
comment
it
and
push
and
application
set
is
configured
to
watch
clusters
folder
in
my
repository
and
create
an
application
for
every
subfolder.
Assuming
that
subfolder
is
the
name
of
a
cluster
registered
in
Arbor
City,
and
so
what
it
will
do
for
us,
it
will
automate
propagation
of
every
manifest
in
the
cluster
subfolder
into
appropriate
cluster
and
I.
Can
let
my
users
end
users
make
changes
in
that
folder.
C
C
Let's
refresh
application
again
so
Argo
CG
detected
the
application
set
application
set
created
its
application
that
manages
a
cluster
and
you
know
manage
resources
in
the
cluster.
Now,
if
I
switch
back
to
my
admin,
end
user
account
I
can
make
a
change
and
finish
the
onboarding
I'm
currently
in
the
cluster
folder.
That
represents
cluster,
where
algocg
is
running,
which
I'm
using
for
demo
and
I
have
a
snippet
of
like
namespaces
for
for
my
team,
so
here
I'm
introducing
three
namespaces
Dev
stage
and
product
environments.
C
Let's
go
ahead
and
because
we
shot
on
time
and
I
can,
let's
not.
Let's
not
do
a
pull
request,
let's
just
merge
it
to
a
main
branch,
but
it's
better
idea
to
do
it
in
production.
Now,
if
we
refresh
this
application,
we
can
see
that
ergocg
detected,
that
premium
spaces
should
be
created,
jumping
back
to
the
user
UI
and
we
can
finally
synchronize
and
deploy
our
application
and
that's
pretty
much.
This
is
the
real
life
workflow
that
you
can
use
to
run
the
whole
organization,
so
it
can
it
scales
really.
D
C
Know
that,
right
now
there
is
nothing
like
that
for
projects.
I
know
at
least
one
company
that
uses
API
to
generate
the
projects.
I,
guess
that's
the
best
answer
we
have
right
now,
so
the
company
has
another
source
of
true
for
projects,
and
there
is
literally
a
Jenkins
pay
plan
that
every
so
not
drink
is
my
plan.
There
is
a
kind
of
controller
that
creates,
which
is
the
database
and
creates
create
the
rbcg
project
in
for
every
database.
Entry
yep.
E
B
C
The
right
answer,
so
sync
waves
is
a
simple
way
to
kind
of
orchestrate
deployment
process.
A
little
bit
is
if
you
apply
a
certain
annotation
on
your
resource,
which
is
something
like
Argo
approach.
Dot,
IO,
sync
wave
and
the
value
of
this
annotation
is
a
number
and
so
by
default,
assumed
that
all
resources
assigned
to
wave
zero,
so
it
synchronizes
everything.
At
the
same
time,
if
you
want
to
think
something
before
everything
else,
you
can
apply
that
annotation
and
put
-1
as
a
value
and
rpcg
will
make
sure
to
sync
those
things.
C
F
B
C
I
think
it
really
depend
on
use
cases.
It's
just.
We
learn
it
from
like
experience.
Workflow
users
usually
do
you
know
they
need
so
completely
different
set
of
problems.
Usually
it's
like
ml
data
processing
and
that's
why
that's
for?
For
that
reason,
mostly
what
happened
with
us
is
we
had
a
separate
team
managing
workflows
and
separate
separate
team
managing
CG,
so
I
guess
yeah.