►
From YouTube: 2023-01-18 - Delivery:Orchestration demo - APAC/EMEA
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
That's
something
so
welcome
everyone.
This
is
the
18th
of
January
2023,
and
this
is
the
orchestration
demo
just
before
you
jumped
in
game
that
night,
we
just
chat
so
I
just
jumped
back
to
that
conversation
which
was
like
yeah
so
release
environments.
But
what
were
your
thoughts.
B
I
think
that's
that's
really
great
idea,
and
we
really
really
need
the
to
test
like
the
different
versions
and
test
you
know
like
different
setup
for
for
for
customers
and
upgrades
and
etc,
etc.
But
I
have
a
little
like.
B
B
Create
environments
installations,
not
environments,
because
we
discussed
with
graham
that
environments
is
very
confusing
name.
So,
like
installations
is
better
like
I
feel
like
there,
there
might
be
some
kind
of
universal
way
to
do
those
installations,
because
now
we're
we're
creating
like
a
two
separate
path
right
so
like
the
past
for
creating
those
installations
and
testing
those
installations,
then
path
to
testing
deployments,
then
path
to
testing
clusters
and
etc,
etc.
B
C
So
I
definitely
I
think
what
you're
like
I
do
see
what
you're
saying
so
I
guess
it's
it's
kind
of
a
bit
tricky
here
in
a
way,
if
we're
talking
about
like
let's
talk
about
like
gitlab
installations
themselves,
there's
actually
it's
actually
kind
of
interesting-
and
this
has
only
happened
within
the
last
six
months
or
so
in
that
we
we
kind
of
now
actually
have
kind
of
some
pretty
good,
tooling
and
some
pretty
good
communal,
tooling,
around
spinning
up
GitHub
installations.
C
It's
repeatable
and
kind
of
everyone
focuses
on
the
one
tooling
and
that's
called
GT
the
gitlab
environment
toolkit
and
that's
what
they
get
that
dedicated
team
is
using
that's
what
quality
use
and
that's
what
other
people
kind
of
use
the
release.
Environments
work.
What
I've
done
so
far
is
like,
obviously,
the
Bare
Bones,
it's
a
bare
minimum.
It
spins
up
some
small,
like
basically
some
containers
in
a
namespace
by
the
helm
chart
to
do
an
installation.
C
The
tricky
part
there
as
well
and
I
guess
when
you
say
deployed
so
you're,
probably
talking
about
gitlab.com
in
in
that
case
the
tricky
part
there
is.
It
is
different
to
everything
else
we
do
and
it
is
unique
because
it
kind
of,
and
that
grew
up
organically
the
architecture
is
unique.
The
deployments
are,
the
deployment
mechanism
is
unique.
C
It's
not
as
unfortunately,
and
we
could
probably
do
I
mean
the
team
should
well
whether
the
team
should
do
the
work
in
the
future
is
debatable,
but
it's
it
is
different,
and
so,
while
I
I
think
what
I
would
like
to
do,
I
think
one.
One
thing
we
definitely
can
do
is
what
I
was
hoping
with
at
least
some
of
the
release.
Environments.
C
Work
is
there's
parts
of
gitlab.com
that
we
can't
really
change
or
control
at
the
moment
now,
with
the
kind
of
new
realignment
of
teams
and
that's
basically
around
the
cluster
level
and
the
infrastructure
level,
that's
owned
by
foundations
now
and
what
have
you?
What
we
do
have
ownership
of
is
obviously
the
gitlab
com
repository
and
the
actual
deployment
of
gitlab
into
the
kubernetes
cluster
and
also
giddly
nodes.
C
We
can't
forget
them
what
I
was
hoping
is
not
straight
away,
but
I
think
in
a
few
months,
depending
on
how
the
release
environment's
work
goes
and
what
we
end
up
doing
with
that
and
how
we
kind
of
find
that
and
work
that
out,
I
think
a
lot
of
what
we
do.
There
should
actually
go
into
gitlab.com
or
almost
replace
the
gitlab.com.
So
what
I'm
saying
is
we
would
still
have
like
Auto
deploying
everything
is
the
same,
but
the
actual
case
workloads
gitlab.com.
C
What
that
pipeline
currently
looks,
like
should
probably
almost
be
the
same
as
the
pipeline
for
the
release
environment
stuff
like
they
should
actually
be
the
same,
like
there'll,
be
two
separate
git
repositories,
but
arguably
they
will
be
doing
the
same
thing.
They
will
work
the
same
way.
That
will
be
the
same
way
and
that's.
C
Yeah
yeah
yeah,
and
so
what
we
want
to
hope
there
is
like,
even
though
release
environments
at
the
moment
is
like
one
of
the
big
things
I'm
doing
with
the
release
environment.
Stuff
is
trying
to
avoid
hard
coding
things
trying
to
make
it
a
bit
more
Dynamic
and
things
like
that
to
enable
that,
because
that's
one
of
the
big
problems,
we
have
to
get
lab
Camry.
But
if
you
wanted
to
add
like
a
new
cluster,
if
you
wanted
to
add
and
knew
anything
at
the
moment,
the
gitlab
com
stuff,
it's
actually
very
difficult.
C
You
actually
got
to
modify
a
whole
bunch
of
stuff
in,
like
our
common
repo
there's
a
whole
bunch
of
stuff,
which
is
a
whole
lot
of
technical
debt.
We
have
which
we've
just
never
addressed,
and
what
have
you
and
we
should
address,
and
we've
got
many
issues
in
epics
open
to
address
that,
but
the
release
environments
work
it's
kind
of
an
opportunity
to
say
well,
this
is
a
totally
separate
thing.
Can
we
build
something
which
is
essentially
doing
the
same
thing?
C
It's
deploying
gitlab.com
inside
of
kubernetes
namespace
and
some
cluster
somewhere,
but
actually
kind
of
doing
it
from
the
ground
up,
and
you
know
it
turns
out.
What
we
actually
need
to
do
is
pretty
simplistic.
A
lot
of
the
tricky
parts
to
it
is
is
once
again
it's
that
installation
management.
It's
then
it's.
C
How
do
we
call
these
environments
and,
if
we
add
an
environment,
what's
the
overhead,
especially
for
things
like
release
tools
which
is
going
to
be
running
in
the
stable
branches
to
actually
kind
of
like,
like
it's
not
going
to
just
be
a
pipeline
trigger
I,
think
release
tools
is
going
to
have
to
do
some
some
more
stuff
there,
but
nothing
too
crazy,
but
it's
definitely
going
to
have
to
use
like
the
file
API.
The
commit
API
I
think
to
actually
populate
some
files,
and
actually
you
know,
set
it
off
that
way.
C
So
we're
building
all
this
stuff,
so
I
think
overall
we're
kind
of
going
in
that
direction
for
gitlab.com
and
the
release
environment,
stuff,
and
the
other
thing
that
should
give
us,
hopefully
with
building
stuff
a
bit
more
Dynamic
and
stuff,
is
that
we
can
like
if
we
need
to
spin
up
an
experiment
like
the
rails.
Three
stuff,
for
example,
becomes
much
easier
if
we
need
to
spin
up
testing
bar
like
a
test.
If
we
want
to
test
something
else
new,
it
becomes
a
lot
easier.
C
If
we
want
to
start
doing
review
sites,
we
can
probably
do
that
a
lot
easier,
because
none
of
our
stuff
is
actually
hard-coded.
It's
just
the
case
of
like
you
know
it
becomes
a
lot
easier
to
do
that
kind
of
stuff
because
it
is
all
Dynamic
and
it
all
revolves
around
some,
like
some.
You
know
we're
defining
actual,
whereas
at
the
moment
the
gitlab
com,
repo,
has
no
real,
solid
interface
to
it,
which
I
know
sounds
weird.
You
know
by
the
release,
environment's
work
we've
been
doing
stuff,
like
you
know,
defining
an
environment.
C
Schema
we've
been
validating
that
schema,
so
you
actually
give
a
file
that
represents
an
environment,
and
currently
it's
just
the
pipeline
with
Helm.
That,
actually,
you
know,
is
the
I
guess
the
orchestrator
that
actually
creates
that
environment.
That
does
the
work,
but
it
can
be
anything
it's
irrelevant.
The
point
is
we're
splitting
off
the
interface
of
us
defining
what
we
want
to
deploy
versus
the
actual
implementation
of
that
we're
not
going
to
see
the
benefits
of
that
straight
away,
probably
not
for
a
while,
but
I
think
that's
something.
That's
also
very
important.
C
If
we
have
this
kind
of
unified
model
that
we
can
say,
this
is
what
I
want
to
do
and
then
we're
able
to
people
who
actually
do
the
deployments
and
Implement
that,
whether
it's
us,
whether
it's
another
team
or
whatever,
we
can
still
Define
the
interface.
We
will
give
you
this
file
this
this
model
that
defines
what
we
want
deployed
and
where
and
then
you
we
expect
that
to
happen,
and
you
give
that
result
so
I
do
think
we
will
slowly
try
and
unify
that
I
think
100.
C
We
want
to
unify
at
least
the
the
release
environments.
The
the
gitlab
comma
stuff,
now,
if
reliable
reliability
is
talking
about
using
more
parts
of
debt,
the
gitlab
and
environment
toolkit
all
together.
So
that's
joining
like
the
the
kind
of
unique
parts
we
have
of
gitlab.com,
but
bringing
that
back
to
the
standard.
Tooling
that
that
you
know
that's
part
of
get,
then
we
would
probably
align
with
that
as
well
and
we'd
all
kind
of
like
align
around
that
in
some
way.
C
I
assume
so
I
think
there's
even
further
opportunities
there,
I
I,
don't
know
the
status
of
that.
Yet
that's
really
up
to
what
reliability
you
want
to
do,
but
I
do
I.
I
do
think
you
know
you're
right
and
it's
not
it's
worth
pointing
out
as
well.
The
qual
I
mean
there's
more
than
just
a
couple
of
ways:
we've
described
here
of
deploying
gitlab
within
gitlab.
That's
GDK,
there's
gck!
C
There's
you
know:
quality
have
got
their
own
mechanism,
I
think
the
goal
is
forget
to
try
and
be
kind
of
the
uniform
that
you,
the
unified
way
of
doing
that
underneath
so,
as
I
said,
I
I
do
want
release
environments
to
support
that,
even
if
it's
just
becomes
like
a
you
know
the
model
on
top
and
underneath
it's
actually
running
get
that.
That
seems
fine
to
me.
C
It's
probably
something
we'll
do
for
for
testing
Omnibus
installations,
but
that's
how
I
kind
of
see
see
it
is
I
think
we
should
continue
to
work
on
gitlab.com
to
get
it
more
usable
while
we
can,
but
hopefully,
as
we
kind
of
actually
get
release
environments
working
and
up
and
running,
we
can
start
to
see
what
works
and
and
doesn't
work
out
of
that.
C
And
then
hopefully
you
know
that
can
cross
pollinate
and
eventually
somehow
I
think
we
would
kind
of
make
it
one
repost
somewhere
and
we'd,
actually
just
kind
of
like
pull
from
like
just
the
code.
That's
making
this
or
whatever
it
is.
That
makes
the
actual
implementation
happen,
be
something
that's
shared
and
just
pulled
into
each
of
those
two
two
places.
B
C
B
C
Do
so
so
get
is
quite
as
I
said,
it's
pretty
pretty
and
pretty
important.
Now
sales
teams
use
it
a
lot
with
customers.
My
understanding
is
and
stuff.
So
it's
pretty,
like
you
know
it's
it's
I.
It's
got
some
level
of
like
not
only
maturity
but
also
like
mind
share
within
the
company.
C
The
gitlab
operator
was
done
as
a
joint
effort
with
red
hat,
because
they're
obviously
they're
massive
into
their
operator
space
after
they're,
quite
core
OS
I,
I
I
lack
operators
as
well
I
think
it's
a
great
installation
mechanism
and
idea
it
just
hasn't
taken
off
yet
because
I
just
don't
think
the
industry
see
like
that,
not
as
many
people
as
air
into
operators,
yet
I
think
we
will
see
adoption
grow
for
it.
Well,
I
think
what
we
need
to
do.
Oh
I,
think
what
the
company
needs
to
do.
C
First,
is
they
have
to
take
that
out
of
beta
I?
Think
they
still
got
the
operator
in
beta
or
something
but
I
think
once
that
happens,
and
that's
one
of
those
we
in
delivery
should
be
aware
of
this,
because
this
is
one
of
those
other
things
they
might
just
spring
on
us
one
month
to
decide
it's
out
of
beta
and
then
all
of
a
sudden
they
ask
us
questions
about.
What
are
we
are
we
releasing?
This?
Are
we
supporting
this?
C
Are
we
tagging
this
or
what
have
you
so
I
think
the
the
release
environments
project?
What
I
want
to
be
is
kind
of
like
a
layer
on
top
of
those
installation
mechanisms
and
just
be
like
I
Define,
what
the
environment
I
want.
We
have
some
way
of
implementing
that
and
then
you
know
in
your
model,
you
say:
I
want
an
environment
running
these
versions,
but
I
would
like
it
to
be
installed.
B
One
one
question:
are
you
thinking
about
implementing
some
sort
of
environment
definition,
file
that
you're
like
in
in
yamu
format
or
whatever,
and
you
check
in
in
the
git
reports.
C
So
we
already
have
one
it's
very
simple,
because
we
haven't
got
much,
but
we
already
have
one
already
in
there
and
we
validate
it
with
Json
schema.
So
we
just
find
a
schema
that
has
to
all
the
files
have
to
meet
and
any
file
you
try
and
put
in
gets
validated
and
rejected
if
it
doesn't
meet
the
schema.
It's
worth
noting
for
those
sorry
I'm,
just
gonna
segue
one
little
bit
more
so
dares
talk
about,
resurrecting
the
service
catalog
as
well.
We
used
to
have
a
service
catalog.
C
We
even
used
to
have
a
web
app
I
can't
remember
the
person
who
was
working
on
it.
They
left
a
few
years
ago,
shortly
after
I
joined
actually
and
that
that
just
got
pushed
by
the
way
so
I
like
not
really
used
much
I,
actually
want
to
bring
that
back
and
they're
going
to
be
using
Json
scheme,
but
once
again,
they're
going
to
be
defining
a
model
for
the
service
like
a
service
and
a
service.
C
Catalog
they've
got
a
schema
that
they
wanted
to
adhere
to
they're,
going
to
validate
that
I've
been
chatting
on
the
issue
about
how
we're
going
to
kind
of
make
that
a
bit
more
discoverable
and
some
other
improvements.
We
can
do
so.
I
think
that
the
environment
model,
or
maybe
it's
not
an
environment
model.
It's
an
installation
model
that
whatever
we
decide,
will
tie
into
that
I
think
and
then
also
there's
a
metrics
catalog,
which
they're
starting
to
Define
and
Define
a
schema
for
as
well.
C
So
we're
going
to
have
all
of
these
schemas
and
models
and
I
would
like
to
whatever
we
end
up
doing
for
a
lease
environment,
I'd
like
to
propose
hey,
we've
got
a
model
for
like
an
installation
or
you
know
of
of
gitlab.
Maybe
we
can.
You
know,
contribute
that
to
that
as
well
and
I
think
one
thing
we
we
also
see
is
a
model
for
clusters
like
we
need
to.
We
need
a
some
unified
model
of
what
is
the
infrastructure
right
that
we
can
deploy
to.
A
Could
we
actually
get
like
a
practical
kind
of
like
what,
where
are
we
with
release
environments
right
now?
What
I
want
to
make
sure
we
kind
of
are
thinking
about
is
but
like
from
the
kind
of
Epic
status
and
due
date,
we
currently
have
like
I
think
we
should
probably
adjust
those
decide.
What
what
makes
sense
in
terms
of
like
is
there
a
First
iteration
and
then
how
does
that
actually
line
up
for
next
quarter?
A
C
So
we're
very
close
to
actually
having
something
running
if
I
can
find
the
right.
C
Here
we
go
so
this
so
I
attempted
to
actually
deploy
an
environment
for
the
first
time
yesterday
it
didn't
work.
I,
have
this
Mr
open
that
either
I
think
Vladimir
or
scarbeck
can
review
and
approve,
and
once
that's
merged,
and
we
should
in
theory,
hopefully
actually
have
a
running
environment
we
can.
We
can
actually
see-
and
hopefully,
if
it
doesn't
break,
this
is
still
but
a
small
piece
in
the
whole
picture.
This
is
actually
showing.
Okay,
I
can
define
an
environment
and
it
actually
works.
So
if
we
look
at.
C
So
we
have
this
environment
15,
6
stable,
which
is
just
our.
This
is
what
I'm
just
using
to
say:
hey?
Can
you
try
and
test
this
to
to
build
this
environment?
This
is
the
versions
We
want
to
run.
This
is
the
cost
that
we
want
to
install
it
to
at
the
moment.
We
only
have
one
cluster
for
this
particular
support
mechanism.
Likewise,
we
have
an
install
type
of
Helm,
but
that's
the
only
thing
we
support
at
the
moment.
C
So
this
is
the
environment
that
I'm
trying
to
get
up
and
running
the
CI
CD
failed
on
it.
The
installation
process
failed
on
it
last
time,
because,
interestingly,
something
I
didn't
know
about
the
gitlab
helm,
chart
tries
to
do
an
upgrade
check
and
tries
to
make
sure
you're
following
the
supported
upgrade
path,
but
it
completely
has
no,
it
doesn't
work
for
us
because
we
run
RCS
we're
going
to
run
Shaw
tag.
C
Things
like
like
we're
just
not
going
to
be
running
tagged
knowing
like
releases
so
I
think
it
falls
over
when
you're,
not
just.
You
know,
following
the
standard
kind
of
sembo
image
tags
that
you're
passing
in
right,
like
the
version
of
gitlab
you're
running
is
not
just
it's
not
like
15.6.1,
it
might
be.
You
know
some
other
race,
random
version.
So
that's
why
I'm,
basically
turning
this
off
so
I'm,
going
to
turn
all
the
upgrade
checks
off
in
this
environment
and
then,
hopefully,
we'll
actually
have
a
working
environment.
C
This
should
be
mostly
up
to
date,
but
I
will
double
check.
It
is
so
that
would
mean
this
kind
of
task
here.
Make
it
a
bit
bigger.
This
kind
of
task
here
will
be
done
so,
basically,
once
we
can
get
here
and
we're
like.
Yes,
we
can
deploy
an
environment.
We
can
make
that
environment
work.
This
will
might
mostly
be
done.
So
this
is
all
like
infrastructure
and
getting
something
to
work
part.
Then
we
actually
need
to
deploy
stable
branches
to
the
last
three
minor
releases.
Then
we
start
need
to
look
at
test
Suites.
C
Then
we
need
to
start
look
at
well.
Have
we
actually
got
CNG
images
being
built
from
stable
branches,
and
then
we
have
to
actually
start
figuring
out
how
release
tools
is
going
to
interface
into
this
right,
which
is
probably
finding
the
environment
file
in
the
git,
repo,
updating
the
values
and
actually
doing
a
new
commit
or
a
merge
request,
or
something
with
that
and
and
actually
doing
it,
the
the
kind
of
get
Ops
way.
Hopefully,.
D
This
is
not
necessary,
especially
if
we
want
to
go
commit
by
commit.
This
is
something
I
was
trying
to
figure
out
so
a
list
for
CNG.
It
looks
like
it's
entirely
possible
to
just
Downstream
trigger
in
this
case,
because
it's
another
environment
to
trigger
a
pipeline
that
will
produce
artifacts
and
artifacts,
and
you
can
even
provide
the
expected
image
name
that
you
want
out
of
it.
So.
C
D
C
Oh,
that's
really
good
to
hear
so
that
part
which
I
was
I,
wasn't
worried
about,
but
I
was
not
sure
how
difficult
would
be.
It
should
be
relatively
straightforward
then
so,
interestingly,
things
like
that
could
probably
be
done
in
parallel.
So
what
I
mean
by
that
is,
we
could
probably
have
stable
branches
starting
to
trigger
into
distribution
already,
even
if
we're
not
deploying
them
to
release
environments.
Yet
right,
like
someone,
could
actually
sit
down
and
be
like
right
now,
I've
got
to
add
the
job.
C
C
C
Most
of
these
other
tasks
can
hopefully
fall
into
place.
We
have
a
lot
of
tasks
that
are
just
like
making
release
tools.
Sorry,
release
environments,
repo
better,
like,
let's
add
renovate,
let's
use
deployment
tracking
in
gitlab.
C
We,
you
know
we
need
to
tweak
permissions.
We
need
to
do
a
Security
review.
I
just
realized
if
I
deploy
this
environment.
Now
it's
going
to
have
the
default
gitlab
password
and
like
I,
need
to
make
sure
it's
going
to
just
put
this
new
gitlab
installation
straight
out
on
the
internet.
So
we
need
to
have
a
task
where
we're
like.
How
do
we
lock
down
all
these
gitlab
installations?
C
Make
sure
you
know
that
we
don't
allow
public
sign
up
the
root
password
is
checked
like
there's
a
lot
of
little
technical
pieces
that
need
to
be
done,
but
that
can
kind
of
be
done
in
the
alongside,
like
the
let's
now
get
this
into
the
stable
Branch
pipeline
does
ever.
Does
that
make
sense
to
to
everyone
like
improving
the
the
like
environments
themselves?
Is
is
kind
of
a
separate
kind
of
effort
to
the
well.
Now
we
need
to
get
them
into
the
stable
branches
and
deploying
to
them.
A
C
C
C
Oh,
maybe
it's
not
important.
No!
No
yes,
hang
on
I
should
have
probably
maybe
I
haven't
been
as
diligent
enough
with
my
bookkeeping.
This
should
be
in
progress
if
it's
not
yeah
it's
in
progress,
so
this
is
kind
of
wrapping
up
and
getting
something
working.
C
C
B
A
That
working
okay-
let's
go,
let's
close
that,
then,
if
that's
the
kind
of
answer
but
yeah,
we
should
make
sure
we
have
the
issues
and
actually
what
we've
found
on
the
maintenance
policy
is.
If
we
have
things
that
we
are
going
to
have
to
depend
on
quality,
for
let's
get
those
created
as
soon
as
possible,
because
then
we
can
hopefully
get
some
time
planned
in
for
q1,
because
they
are
very,
very
time
constrained.
Right
now,.
C
So
yeah
this
is,
this
is
actually
like.
The
release
tools.
Work
is
was
blocked
by
the
CNG
stuff,
but
it
sounds
like
I
can
probably
I'm,
not
sure
if
it's
really
blocked
by
CNG
I
mean
it's
blocking
the
sense
that
we
can't
have
release
tools
actually
trying
to
deploy
environments
if
the
images
aren't
ready.
But
you.
C
So
I
think,
overall
now
there
shouldn't
be
too
many
blockers.
It's
it's
really
and
I.
I'll
I'll
redo
this
issue
for
the
QA
test
Suite.
So
that's
the
other
part
because
I
think
correct
me.
C
If
I'm
wrong,
the
pla,
no
actually
I
do
know
this
I'm,
pretty
sure
we
want
to
do
the
QA
running
inside
the
stable
Branch,
like
sorry
in
the
pipeline
in
the
gitlab
OR
gitlab
repo,
so
I'm
going
to
have
the
downstream
pipeline
to
distribution,
the
interface
Downstream
pipeline,
what
have
you
to
release
environments
and
then
the
downstream
Downstream
trigger
into
QA,
but
it's
in
the
the
branch
that
runs
on
the
stable
pipeline
so
that
way,
when
you
merge
in
in
gitlab
or
gitlab,
you
imagine
that
you
get
a
pipeline
saying
you
know
this
pipeline
is
now
running
on
that
and
if
that
goes
red
like
and
and
so
that
will
give
you
the
like
green
or
red
to
the
developer,
if
they're
merged,
you
know
failed
to
deploy,
failed
QA
or
you
know
some
other
thing,
but.
A
C
The
idea
is
the
stable.
The
pipelines
on
the
stable
Branch
are
kind
of
like
our
coordinated
pipelines
and
auto
deploy.
That
was
my
understanding
and
I.
Think
me
and
Myra
discussed
this
somewhere.
Probably
in
this
I
think
we
yeah
I
think
this
is
I,
don't
know.
Maybe
it
was
in
somewhere
I
think
maybe
it
was
in
the
actual
issue
for
the
policy
maintenance
extension.
D
A
Which,
at
the
moment,
what
we're
up
to
there
is
Quality
so
not
from
quality,
is
reviewing
the
sort
of
the
interim
proposals,
but
actually,
depending
on
what
He
suggests
from
that
that
will
probably
feed
in
here,
because
the
sort
of
interim
ones
are.
Do
we
use
the
package
and
test
job
the
problem
if
we
do
use
that,
is
it's
quite
flaky,
so
it's
a
sort
of
a
whatever
quality.
You
want
to
do
about
that
flakiness,
for
example,
so
that
probably
does
fit
into
this
stuff.
C
Yeah
and
I
think
the
thing
is
we
can
kind
of
great
thing
is
like
you
can
put
two
jobs
you
can
set
jobs
allowed
to
fail,
so
we
could
run
packaging
QA
and
also
be
like
okay,
let's
deploy
the
release
environment
like
especially
as
we're
still
kind
of
like
getting
the
environment
stable
and
kind
of
figuring,
the
the
you
know
the
bugs
out
of
them.
We
probably
are
going
to
have
a
lot
of
these
jobs
set
to
yeah,
maybe
not.
A
C
D
Yeah,
there's
also
limitation
in
package
and
QA
that
is
related
to
component
version.
So
every
component
that
is
in
manager,
the
versioning
will
be
tagged
in
that
same
release.
But
with
the
work
you're
doing
in
release
environment,
it
will
be
highly
possible
to
replicate
the
same
behavior
on
the
stable
branches
of
components
as
well,
so
that
whatever
let's
say
you
could
get
rails
is
a
component
like
any
other
one.
D
So
whatever
components
get
a
commit
on
a
stable
Branch,
it
can
self
update
by
his
own
Shah,
on
release
environment
and
trigger
a
full
QA
run
on
that
environment
and
then
the
end
result
is
if
I
want
to
tag
a
stable
release
of
gitlab
I
can
check
the
stable
branches
of
all
All.
The
known,
supported,
components
and
say
are
all
those
things
green.
C
That's
a
very
good
point.
Actually
I
didn't
even
think
about
that,
but
that's
very
perceptive.
We
we
could.
We
should
totally
support
we'd,
be
able
to
support
that
in
the
future.
Anyone
should
be
able
to
interface
in
and
basically
say,
I've
got
a
new
version
of
my
component
only
like
update
the
Shah,
the
version
or
whatever
is
of
their
component
and
still
kind
of,
like
you
know,
deploy
to
that
environment.
Get
some
useful
result
out
of
that
that,
yes,
things
are
still
working.
A
But
the
due
date
on
this
epic
and
actually
so
Graham
I,
know
you've
added
the
at-risk
label.
Is
that
at
risk
of
not
hitting
January
27th
so
yeah?
Okay,
great
so.
C
My
kind
of
my
kind
of
the
way
I
structured,
that
after
the
feedback
from
the
you
know
the
video
about
how
we
want
to
do
project
management
was
I
set
the
due
date
that
due
date
to
like
you
know
when
we
defined,
was
acceptable,
and
we
would.
It
was
a
no
chaos.
I
was
like
end
of
the
quarter
and
then
I
was
like
well
theoretically,
looking
at
the
amount
of
work,
this
is
not
going
to
happen
done
by
the
end
of
the
quarter.
Therefore,
at
risk
you
know,
yeah.
D
A
Going
to
hit
the
27th,
but
we
also
know
we
want
to
keep
going
on
it
sure
you
have
an
idea
at
the
moment
of
knowing
what
you
currently
know
like
what
would
be
a
sort
of
a
sort
of
a
realistic
date
that
we
might
like
it
doesn't
have
to
be
locked
in
stone,
but
just
as
a
we
are
aiming
at
for
now,.
C
I
think
with
every,
if
we're
talking
about
the
whole
epic,
so
that
includes
all
of
the
getting
the
kind
of
making
the
the
release
environments
themselves.
We
need
to
make
them
kind
of
stable
and
secure,
and
things
like
that,
yeah
and
also
combined
with
the
it
sounds
like
we
want
to.
C
We
want
to
kind
of
scope
this
epic
to
be
on
the
stable
branches
of
maybe
just
the
gitlab
repository
to
start
with
at
least
then
I
still
think
we're
probably
looking
at
two
months
that
that's
kind
of
been
a
bit
pessimistic,
I'd
like
to
be
more
optimistic
and
we
may
get
there
ahead
of
time,
but
just
thinking
about
probably
more
of
the
complexity
of
the
stable
Branch
stuff
than
anything.
Okay,.
A
Let
me
let
me
bump
this
to
the
end
of
March.
Remove
the
at-risk
label.
I
know
when
you
do
your
status
update.
You
can
just
kind
of
mentioned.
We've
reviewed
that
and
the
other
question
which
I
think
we
probably
don't
want
to
go
ahead,
is
with
the
based
on
your
availability
agreement.
The
fact
that
we
only
have
you
around
and
other
things
going
on,
there's
a
question
of
like
do.
We
want
to
pause
this
until
we
have
more
more
time.
A
C
Think
so
at
this
stage
you
know
yeah.
A
Okay-
and
that
makes
sense,
what
do
we
want
to
do
about
handling
so
I
mean
the
sort
of
the
the
challenge
of
bringing
together
the
this
epic,
with
the
maintenance
policy
extension
epic,
as
how
do
we
want
to
handle
all
of
the
things
that
we
don't
have
covered
by
these
release
environments?
So,
for
example,
a
patch
release
may
have
all
kinds
of
different
bits
and
pieces
in
there.
A
Do
we
like
well,
we
will
need
to
get
to
a
point
as
soon
as
we
can,
where
we
can
actually
say.
Maintenance
policy
is
extended,
and
you
know
the
release.
Managers
have
a
a
sort
of
like
relatively
straightforward
time
to
be
able
to
produce
three
patch
releases.
A
C
C
So
I
guess
the
I
guess
there's
two
parts
here.
So
the
actual,
really
the
the
release
environments,
part
to
the
release
environment
stuff
by
Design,
is
the
release.
Environment
is
repo
and
what
it
does
is
pretty
simple.
You
just
give
it
some
versions
of
some
containers
to
run,
and
it
will
put
it
in
an
environment
for
you
so
that
once
that's
working
it's
up
to
us
to
Define.
You
know
when
we're
going
to
stick
files
in
with
version
numbers,
what
those
version
numbers
are-
and
you
know
running
QA
against
them.
C
C
C
C
We
can
do
the
latest
release
because
we've
got
like
release.gitlab.net
and
stuff,
but
you
know
anything
older
than
that.
We've
got
nothing
so
I,
guess,
realistically,
what
we
want
to
say
is
I'm
not
exactly
up
to
date
with
what
Myra
is
doing
as
this
interim
solution.
I
guess
the
packaging
QA
job,
but
it
sounds
like
for
giddly.
The
packaging
QA
job
is
actually
useless.
If
that's,
if
what
a
Leo
is
saying
is
correct,.
D
Not
exactly
so
I
think
the
the
key
Point
here
is
that,
even
today,
with
a
single
patch
release,
we
are
not
testing
this
thing.
That
Amy
is
talking
about
the
okay.
The
only
way
we
test
it
is
by
after
the
package
is
produced
after
so
it's
already
checked.
D
We
created
a
broken
release
and
if,
in
the
New
World,
we
will
know
if
we
broke
the
current
stable,
current
Milestones
say,
but
we
will
just
infer
that
this
eventually
broke
even
the
other
one,
but
we
will
not
be
able
to
actually
figure
this
out
because
package
nqa
refers
to
the
content
of
them
of
the
branch
of
the
Rails
Branch
itself.
D
That
being
said,
as
an
interim
solution
which
we
need
to
validate
but
I'm
quite
sure
it
will
work,
we
can
say
that
when
you
component
developer
merge
something
into
the
stable
Branch
you
can
even
open.
You
should
open
merge
records
on
the
stable
branch
on
the
rails.
That
is
bumping
the
version
five.
The
version.
C
C
D
D
That's
I
can
say
for
sure
I'm
also
assuming
that
package
nqa
will
actually
refer
to
the
content
of
those
version
of
file
and
build
the
packages
accordingly
and
that's,
and
so
this
will
give
us
a
package
and
QA
that
will
also
take
care
of,
say,
digitally
backwards.
D
And
when
we
target
this
will
everything
will
be
overwritten
and
we
would
just
end
up
with
the
shiny
names
as
expected.
So
this
will
be
it's
a
way
that
we
can
test
something
and
but
then,
in
the
end
we
will
still
overwrite
everything
and
produce
the
expected
package
version.
C
So
here's
a
question
then
I
I'm,
I'm,
sensitive
to
time,
so
hopefully
I
won't
derail
things
too
much
just
with
me
trying
to
learn
and
understand,
but
I
thought
the
developers
so
when
they
did
a
fix
in
their
own,
stable
Branch.
So
let's
say
it's
giddly
right,
so
they've
got
their
giddly
step
Branch
they
merged
their
little
their
fix
on
what
have
you
I
thought
they
always
had
to
go
into
the
gitlab
organ
bump,
the
version
file
anyway
or
if
they
do,
we
do
it
for
them.
As
part
of
that,
like
tagging
process.
D
So
when
they
were
doing
the
the
manual
version,
so
let's
say
Pages
up
until
two
months
ago,
they
were,
they
would
have
to
figure
out.
What
was
the
version
released
in
all
right?
Go
back
version,
yeah
yeah
go
from
that
pick.
The
fix
then
go
back
and
bump
the
version.
So
it's
all
manual.
C
Yeah,
okay,
that's
interesting,
so
I
I
see
I,
see
the
question
a
bit
more
completely
now
yeah,
so
okay.
So
what
we
that
that's,
fine
and
I
think
that
actually
might
segue
like
the
stipulation
that
you
fix
it
in
your
stable
Branch,
but
then
you
also
go
into
the
gitlab
org
and
bump.
The
version
file
is
not
neces
like
it's
a
little
bit
more
work
for
them.
It's
not
necessarily
bad
for
the
interim
solution
and
I
actually
think
it
may
not
be
bad
as
a
starting
point
for
the
release
environments.
C
At
the
moment,
the
release
environments
could
really
just
be
deployed
like
take
what
is
in
those
version
files
and
deploy
that
into
the
release
environment.
So
it's
not
the
like
as
a
first
step
like.
Ideally,
we
want
all
the
components
themselves
doing
it,
but
that's
a
lot
of
work
to
kind
of
like
go
into
all
these
different
components.
Have
this
trigger
part
like
it
becomes?
The
complexity
is
a
little
bit
more
in
terms
of
permissions
and
things.
C
What
I'm
saying
is
if
we,
if
we're
like
okay,
the
interim
step,
is
packaging
QA,
but
it
does
mean
also
developers
have
to
make
sure
they
bump
the
the
Char
on
the
branch
preemptively.
They
can't
just
wait
for
the
tag
job.
It
is
a
bit
annoying,
but
at
least
it
sounds
like
it'll
make
the
packaging
QA
job
work,
and
at
least
it
also
means
the
first
iteration
of
release
environments.
We
can
just
take
everything
from
the
version
files
and
just
do
one
trigger
into
it
and
say
Here's
all
of
the
new
component
versions.
C
We
want
to
deploy.
Just
do
that
then
over
time,
once
we're
confident
in
that
we
would
actually
be
like
okay.
So
you
know
the
giddly.
The
giddly
project
can
just
trigger
the
release
environments
deployed
from
their
own
repository
right.
They
no
longer
need
to
bump
the
version
file
like
we
can
improve
that
over
time
and
then
offer
that
to
other
components
and
push
it
out.
But
I
think
at
the
moment
for
Simplicity.
C
C
D
Yeah
I
would
also
consider
the
you
mentioned
it's
a
little
annoyance,
not
even
that
much,
because
if
you
think
about
what
happens
today,
they
have
no
control
over
it,
so
they.
B
D
That
they
are
in
control
because
they
say
this
is
ready.
Maintainers
can
you
merge
this,
then
it's
merged?
And
then
it's
up
to
me
because
we
are
giving
them
a
real
environment
that
they
don't
have
today
right.
So
it's
up
to
say,
I
now
that
I
fix
something
I
want
this
to
see.
I
want
to
see
this
live
in
the
environment,
so
I'm
gonna.
So
it's
kind
of
every.
C
C
I
think
that's
very
important
right
because
there's
nothing
worse
than
them
coming
back
to
an
MR
from
a
month
old
and
being
like.
Oh
no,
it
doesn't
it's
broken
or
it's
like
merge
conflict.
Now
you
gotta
like
we
should
push
that
for
like
if
they're
ready,
like
yeah,
do
the
Mr
Bump
them
imagine
solve
all
the
problems,
see
the
pipelines,
green
and
then
you're
right.
You
can
walk
away
because
we're
confident
now
it's
on
there.
It's
confident
the
tests
are
green.
A
Okay,
yeah,
that
makes
sense
okay,
so
we
have
there's
probably
a
couple
of
pieces,
so
I'll
make
sure
Mario
watches
this
recording.
A
She
is
currently
working
with
quality,
to
figure
out
like
what
what
we
can
actually
do
with
this
packaging
test
drop
and
and
whether
that's
the
way
that
quality
want
to
actually
handle
this,
but
regardless
like
if
we
make
sure
we
include
in
that
that
the
developers
will
need
to
bump
versions
and
then
that
will
trigger
the
whatever
the
test
the
quality
want
to
trigger
and
that
will
eventually
land
on
our
environments.
C
I
think
we
just
want
to
coming
back
to
the
original
question.
I
think
we
want
to
just
have
confidence.
We
have
something
and
I,
as
I
said,
I
I,
think
for
for
a
while,
we'll
probably
have
packaging
Kuwait
and,
like
release
environments,
trigger
probably
living
side
by
side
in
the
same
stage
like
doing
both
kind
of
thing
right
like
just
for
extra
coverage.
C
We
just
need
something
around
that
space
to
say:
we've
defined
some
testing
structure
for
this
that
we're
confident
that
we're
taking
the
components
of
the
versions
that
you
know
we
people
are
expecting
or
have
told
us
to
test,
and
we've
done
some
level
of
testing
of
that
yeah,
and
you
know
we're
confident
there
that
you
know.
Therefore,
if
we
were
to
chop
a
release,
we've
everything
has
been
tested,
and
you
know
we.
We
wouldn't
expect
issues
yeah.
A
Yep,
okay,
great
so
on
our
kind
of
collaboration
check-in
for
our
retro.
Are
you
personally
getting
enough
collaboration
to
complete
your
tasks
so
that
can
be
from
within
our
team
or
or
outside.
C
A
That
makes
sense
great,
and
is
there
anything
else
we
can
do
to
improve
on
collaboration.
A
I'd
say
probably
just
the
one
we've
talked
about
it
already
a
little
bit
but
Gabe,
just
to
sort
of
have
a
little
think
in
advance
about
other
things
that
we
can
kind
of
see
coming
up,
that
we
may
need
other
teams
for
because,
especially
at
this
time
of
year
like
if
we
could
give
them
the
heads
up
that
oh
distribution
at
some
point
in
the
next
three
months,
we
all
probably
need
some
help
for
this,
then
yeah
we
can
hopefully
get
involved
in
people's
okay,
our
planning.
A
Okay,
awesome
well
have
a
great
rest
of
your
Wednesday
thanks
for
joining
thanks
for
the
discussions.