►
From YouTube: 2022-09-14 Delivery:Orchestration team 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
Do
the
admit
afterwards?
Okay,
it's
you
guys.
B
Okay,
this
is
the
delivery
orchestration
demo
meeting
for
september,
4th
emea
apac
time
so
on
the
agenda
first
up,
I
would
just
like
to
review
the
epic
for
basically,
the
pages
managed
versioning
hold
on
I'm
just
gonna
open
this
up
and
I'll
share.
My
screen.
B
B
Perfect
perfect,
so
this
is
basically
the
epic
which
more
or
less
is
going
to
align
with
our
okrs
forget
forget
lab
pages
to
basically
move
them
to
manage
versioning,
which
means
you
know
they're,
giving
giving
over
kind
of.
I
guess
you
could
say,
control
to
the
versioning
scheme
and
everything
related
to
that
to
us
in
delivery,
and
then
we
basically
use
release
tools
and
extend
that
to
support
these
pretty
standard
operations
that
release
tools
does
to
extend
to
gitlab
pages,
just
like
it
does
for
gitaly
and
a
bunch
of
other
components
as
well.
B
So
basically
it
kind
of
kept
trying
to
capture
here
that
apparently
the
pager
service,
they
use
their
own
versioning
scheme.
It
is
semver,
but
it
is
basically
a
completely
different
versioning
scheme.
That's
based
different
to
what
we
use
for,
obviously
to
get
my
product
looking
at
the
steps
they
have
to
do
for
a
release.
They
have
to
manually
tag.
They
have
to
manually,
create
a
branch
if
they
need
to
for
say
back
ports
and
stuff.
B
They
run
a
make
command
in
their
repository
in
their
repository
to
generate
the
change
log,
and
then
they
have
to
manually
change
the
gitlab
page's
version
in
gitlab
org.
Whenever
the
new
release
is
done
to
kind
of
keep,
you
know
once
they
do
the
tag,
then
they
also
have
to
go
and
bump
that
in
the
gitlab
main
repo.
B
So
basically
in
this
epic,
we
want
to
move
them
over
into
what
we
have
defined
now
as
managed
versioning.
I'm
by
no
means
an
expert
on
all
of
this.
Obviously
this
will
be
the
first
component.
I've
kind
of
helped
migrate
to
this
kind
of
setup,
so
I'm
very
interested
in
feedback
from
yourself,
alessio
and
amy
on.
Is
this
the
right
exit
criteria?
Is
this
the
right
breakdown
of
work
and
things
like
that?
What
I've
broken
the
issues
into
and
this
this
might
be
the
part
where
I'm
not
entirely
sure
I
have
one.
B
That's
basically
modifying
the
chat.
Ups
tag
command
to
support
pages,
so
it'll
actually
do
pages
as
well
and
essentially
tag
it,
and
then
I've
done
another
issue
here
to
make
the
release
process
automatically
update
gitlab
page's
version
in
the
gitlab
org
thing
as
part
of
like
so
basically
the
at
the
end.
You
know
like
actually
updating
the
the
version
file
in
the
gitlab
repo
and
then.
B
Hang
on,
I
think,
that's
right
and
then
the
final
command,
so
final
part,
is
enabling
deployments
environments
feature
so
at
the
moment
for
components
that
we
do
this
for
when
they
auto
deploy.
We
actually
have
a
job,
which
I
think
I
found
in
deployer.
I
think,
or
was
it
release
tools?
I
can't
remember
it
was
somewhere.
I
was
looking
at
it.
This
track
deployment
job.
It
is
in
release.
B
Okay,
right,
okay,
fair
enough,
the
end
result
is
when
we
do
auto
deploys.
We
go
back
and
actually
on
the
in
the
code
for
the
in
the
repository
for
the
component.
We,
you
know,
if
you
go
into
the
environments
page
there,
we
actually
update.
So
what
particular
put
a
deployment
object
in
there
and
the
big
key
piece
for
that
is
it
links
to
for
them
and
for
everyone
publicly
can
see.
B
You
know
what,
in
each
environment
what
deployment
is
running
and
it
has
the
link
to
the
actual
like
sha
right
like
so
this
git
commit
is
currently
running
in
staging
this
git
commit
is
currently
running
in
production,
but
it
turns
out.
This
is
actually
important
because
some
of
the
work
that
needs
to
be
done
for.
B
I
believe
this
is
based
off
the
fact
that
we
use
that
environments
feature
as
the
ledger,
for
what
version
is
been
currently
run
right,
because
we
want
to
say
right:
we're
going
to
tag
right
now
or,
let's
say
we're
going
to
create
an
rc,
what
is
running
in
production
and
so
that's
the
source
of
truth,
which
is
actually
really
good
and
really
powerful.
It
is
a
little
bit
tricky,
obviously,
because
we
have
like
deploy
and
release
tools
kind
of
doing
it,
but
it
is
very
powerful
because
it
does
show
right
away.
B
You
go
to
the
component,
you
go
to
the
deployment
screen
and
you
can
see
right
there
we
get.
We
have
get
a
very
good
user
experience
out
of
it.
So
yeah
is
that
kind
of
like
the
is
that
the
big
things
am
I
missing
anything
I
feel
like
this
one
could
could
be
fleshed
out.
I
just
don't
know
enough
about
the
code
base
to
say
you
know.
Is
this
enough
to
get
us
started
or
do
I
need
to
break
down
more.
C
C
Some,
let's
see,
I
don't
think
that
the
modifying
the
the
gitlab
file
in
itself
is
something
that
we
should
be
doing
as
a
separate
thing.
So
probably
the
the
breakdown.
C
If
we
want
to
make
this
in
iteration
and
more
than
one
merge
request,
probably
we
should
find
a
another
way
to
break
it
down,
because
basically,
what
I'm
trying
to
think
here
is
that,
if
there
is
a
way
when
we
can
set
up
some
kind
of
preparation
for
this
and
and
then
merge
it
in
steps
and
see,
let's
see
if
we
can
generate
change
logs
and
then
later
on,
we
see
what
happens
with
other
things
up
to
the
point
where
we
actually
bump
this.
C
B
C
B
C
Yeah
we
were
discussing
this,
but
this
is
what
what
what
I
meant
when
I
say
in
in
one
of
the
other
code,
where
we
were
talking
about
what?
What
are
the
real
dependency
for
for
the
steps
right?
Because
in
order
to
have
this,
it
has
to
be
there.
But
there's
also
another
dependency
which
I
need
to
double
check
in
code.
But
I'm
quite
sure
it's
there,
which
is
the
metadata
tracking.
So
gitlab.
B
C
Is
tracked
on
metadata,
so
it's
already
there,
so
it
should
be
fine,
it's
even
worth
checking
and
that's
an
important
thing
that
want
to
say
metadata,
because
this
is
one
of
those
things
that
we
re
implemented
several
times
in
the
code
base
and
then
I'm
not
sure
which
versions
are
we
using,
but
basically
in
many
features
we
start
from
the
product
version,
which
means
give
me
the
last
deployment
in
terms
of
gitlab
metadata,
and
so
it
will
be
the
4
15.3.
C
timestamp
okay.
So
there
are
processes
where
we
start
with
that
value.
If
the
tagging
starts
with
that
value,
then
it
will
be
able
to
get
the
proper
pages
version
with
that,
because
from
the
product
versions
we
infer
the
metadata
file
from
the
method
of
the
file,
we
can
grab
component
versions
and
being
already
tracked
there.
It
kind
of
gave
us
a
global
ledger
for
everything.
In
a
package.
C
As
I
said,
the
re
public
release
classes
are
kind
of
a
special
thing
because
they
are
they
don't
use
the
same
code
base
the
same
code
path
as
they
how
to
deploy
things.
So
it's
entirely
possible
because
it's
older
that
that
one
is
actually
going
in
every
single
component
and
checking
his
own
deployment
with
the
component
deployment
api,
which
I'm
quite
sure
because
of
the
problem
of
the
picking
tool
to
deploy.
Because
we
know
that
if
we
pick
intro
to
deploy,
we
will
need
to
do
manual
step
before
tagging.
B
A
We
could
we
don't
have
to
order
necessarily
this
epic.
We
can
just.
I
think,
if
we
have
one
step,
that
we
definitely
need
to
get
done
before
the
others.
We
can
just
make
sure
that
one,
whoever
ends
up
being
the
dri
for
this,
can
make
sure
that
goes
on
the
board
and
gets
handled,
and
the
dri
basically
can
control
the
flow
of
issues.
So
yeah.
A
B
Yeah
yeah
true,
okay
yeah,
so
I
think
I
think
you're
right
alessio.
I
I
was
also
looking
at
this.
I
was
like
it
sounds
like
they
also
depend
on
each
other.
How
we
actually
do
this
without
like
just
dumping
it
into
one
issue
and
trying
to
do
it
in
one
implementation.
So
I
agree,
I'm
happy
to
rewrite
or
like
rework
these,
so
it
sounds
like
we
probably
actually
what
we
want
is
yeah,
so
we
probably
want
to
do
this
first
right.
B
We
want
to
just
enable
deployments-
environments,
gitlab
pages
already
just
getting
that
out
because
getting
the
api
like
sorry
getting
it
to
start,
calling
that
api
setting
that
value
it
sounds
like
this
is
kind
of.
Maybe
we
is
that
we're
saying
is
one
of
the
later
things
that
needs
to
be
kind
of
done.
A
C
C
C
B
C
C
That's
the
point
right,
especially
because
we
already
have
the
whole
implementation,
because
basically,
this
is
the
same
implementation
for
that
we
have
for
easily
exactly
minor
details
to
iron
out,
but
this
is
kind
of
the
the
the
step
are
well
known
that
that's
the
thing
right,
so
we
know
the
steps
that
it
should
be.
The
the
implementation
should
be
take
care
of
it's
already
written
in
code.
C
C
B
C
Sorry,
I
think
we
may
also
need
to
have
guard
around
the
minimum
version.
That
is
the
support
thing.
Yeah.
C
Gonna,
do
yeah
we're
gonna,
do
a
patch
release
security
release
and
then
we
know
that
only
the
current
milestone
will
be
managed.
Correct.
B
B
Or
actually,
okay,
so
question
then,
rather
than
having
to
put
guard
rails
in
the
code
around
this,
do
we
do
something
like
go
back
for
the
past
three
releases
and
create
literally
manually
just
go?
I
go
branch
create
good
tag
like
because
you
can
keep
the
old
tags
in
the
new.
Like
you
know,
tags
are
tags.
You
can
have
as
many
as
you
want.
Yeah.
C
B
B
C
What
is
supposed
to
be
there
so,
but
probably
the
only
thing
we
need
to
double
check
is,
if
we'll
create
it
from
master
or
if
we
will
create
it
from
the
content
of
the
version
file
say
it
reads:
the
easily
version
5,
because
these
things
change
over
time
say
it
reads
the
gita
version
file.
It
will
just
create
the
right
branch
when
we
tag
the
patch.
If
not,
we
can
just
create
the
stable
branches
manually
and
then
it
will
tag.
B
C
I
do
have
so
let
me
do
a
step
back,
there's
a.
I
would
like
to
talk
about
point
number
two,
because
it
kind
of
fits
in
into
this
shop.
So
I
don't
know
if
maybe
we
can
get
back
to
the
point
number
one
if
we
think
there
are
other
things
to
discuss,
but
what
I
would
like
to
okay.
Thank
you.
Amy
for
writing,
and
I
haven't
read
the
thing
so.
C
Are
describing
what
they
want
to
do
with
versioning,
so
if
they
are
okay
with
aligning
so
basically
with
embracing
the
the
managed
versioning
and
the
conversation
there
goes
a
bit
of
not
in
the
same
direction
of
what
we
are
doing,
because
on
one
side
it
seems
kind
of
proposing
we
can
implement
things
ourselves,
on
the
other
hand,
is
more
like
there
is
the
question
about
the
patch
release,
which
is,
I
will
describe
what
happens
with
italy.
C
C
We
just
said:
there's
nothing
in
change.
Look
so
you
know
it's
the
same
as
before,
but
overall
it
gives
a
a
shared
understanding,
and
this
is
githlab1234
whatever
okay.
So
there's
one
discussion
in
that
issue
about
patch
releases,
we
would
like
to
detach
from
patch
releases,
which
is
yeah,
not
what
we
want.
I
mean
it's
either
managed
or
is
not
managed,
so
you
take
the
full
package
or
not
yeah
so,
and
this
kind
of
open.
My
question
was:
are
we
sure
they
are
in
line
with
what
we're
going
to
do?
Amy?
C
You
pointed
to
the
message
which
I'm
not
sure
if
that
message
triggers
this
conversation
or
this
conversation
triggered
the
message
yeah.
This
is
overall
question.
The
overall
point
here
is
that
there
is
socializing
effort
that
should
happen
as
part
of
this
ocr
to
make
sure
that
developers
maintainers,
mostly
maintainers
of
those
components,
are
understand.
They
understand
what
we
are
trying
to
do.
They
they
like
what
we
are
trying
to
do,
because
we
will
want
to
force
them
on
this
thing
right
so
and
because
this
will
also
imply
changes
on
their
workflow.
C
C
C
In
our
say,
integration
levels,
which
is
the
the
automatic
the
automatic
versions
update
yeah
yeah,
which
is
another
step
right.
So
if
they
don't
get
that
one,
they
don't
want
that
one
whatever.
A
Before
we
hang
on
before
you
before
you
go
on
on
on
that,
so
I
think
we,
I
think
we
we.
What
we
should
do
is
make
sure
that
we
we
we're
able
to
kind
of
show
them
people
like,
I
think,
for
all
of
these
changes
for
every
component
and
every
step
we
can
just
make
sure
well
part
of
our
work,
I
think,
is
we
make
sure
that
we
have
a
really
clear
like
here
is
what
changes?
Here's,
what
you
lose!
Here's
what
you
gain
like.
A
I
think
we
have
a
similar
thing,
we're
going
to
have
to
do
for
the
castle
to
deploy,
because
we
know
to
also
lose
stuff.
So
perhaps
that's
like
a
piece
that
we
also
just
factor
in
here
is
make
sure
that
we
have
a
and
maybe
that's
part
of
our
coming
back
to
one
right.
We
can
do
that
towards
the
end,
but
make
sure
in
that
epic.
A
B
All
right,
I
was
going
to
say
very
quick
note.
We
should
not
only
should
we
put
that
in
that
epic,
when
we
do
the
handbook
page
for
these
definitions,
we
should
add
that
in
as
well.
So
what
I
really
want
is
for
these
kind
of
discussions
to
be
like
we
want
to
put
you
on
managed,
versioning,
here's,
the
handbook
page.
It's
got
the
definition
that
shows
you
those
benefits,
what
you
can
and
can't
do
so
that
way,
because
that
way,
it
makes
it
easy
to
have
this
conversation.
B
C
So
there
is
a
question
for
us,
which
is:
how
do
we
want
them
to
handle
the
file
say
we
just
give
them
this,
so
the
first
iteration
will
be.
We
give
you
managed
versioning.
So
the
only
point
in
time
where
we
change
the
version
file
is
when
we
tag
so
that
we
align
with
the
tag
right.
So
that
being
said,
how
do
we
tell
developers
to
bump
the
version
file?
Will
they
bump
with
the
sha,
because
something
that
we
have
done
for
gitly,
which
is
because
that
has
a
different
need?
C
C
C
So
we
that's
so
this
gives
them
control
over
releasing
the
jam
file
so
that
they
can
bump
the
the
the
dependency.
This
is
not
true
for
for
pages,
so
pages.
Don't
need
anything
like
this,
so
yeah.
We
if
we
think
it's
a
good
way
of
putting
this,
we
can
say
them.
If
you
think
something
is
ready,
you
can
just
bump
the
version
file
with
sha,
which
is
fine
as
long
as
we
prerequisite
again
make
sure
that
pages
can
build
from
a
shell.
B
So,
just
to
clarify
so
I'm
clear
on
the
process
when
we
go
in
and
create
new
branches
and
so
creating
new
branches.
I
guess
for
the
monthly
release
is
easy
right.
It's
just
whatever
is
passing
on
master
like
we
just
literally
go
to
the
front,
say:
okay,
that's
it!
So
it's
really
like
patch
releases
and
stuff.
B
B
C
C
So
there
was
this
thing
that
didn't
want
to
create
a
dependency
between
the
two
repositories
yeah,
so.
C
Is
that
say,
we're
gonna
run?
We
just
have
an
order
of
operations
so
because
we
know
that
we
need
a
geesely
release
before
we
can
do
a
gitlab
release,
because
we
first
started
italy,
and
then
we
update
the
version
file
in
there.
So
that's
the
order.
So
when
gizelle
is.
B
C
Is
not
checking
the
status
of
the
say,
stable
branches
on
on
gitlab
park
itself,
it's
just.
C
The
way
we
run
operation,
those
things
are,
they
have
the
same
value,
but
let's
say
for
any
reason:
you
roll
back.
Okay,
it
never
happened,
but
if
you
roll
back
yeah
sure
like
easily
right
before
creating
the
rc42,
that's
the
point
the
point
in
time.
When
we
create
the
stable
branches,
then
those
values
would
not
be
the
same,
because
the
the
the
rollback
will
take
priority.
C
So
what
will
happen
there
is
that
you
will
generate
the
gitly
stable
branch
from
the
road
back
version,
which
will
so
we
take
the
sha
of
the
package,
create
stable
branch
for
there
tag
or
c42.
And
then,
when
you
go
into
the
gitlab
stage,
you
are
not
checking
this
again.
You
are
assuming
that
something
before
created
the
rc42
for
you,
and
so
you
you,
you
see.
This
is
rc42.
C
That's
that's
the
the
point
where
the
two
process
diverts
a
bit.
B
Okay,
so
so
now
I'm
wondering
once
again
thinking
about
the
terminology
and
everything
whether
we
say
for
patch
releases
for
non-master
releases,
part
of
getting
managed
versioning
is
we
have
to
add
that
part
that
keeps
those
in
sync
like
you,
don't
get
that
option
you
you
can
only
ever
get
it.
You
can
only
ever
manually
bump
on
master.
Does
that
make
sense.
B
B
Yeah,
maybe
I'm
maybe
I'm
not,
so
I
guess
what
I'm
saying
is
so
if
I
understand
you
correctly
so
let's
say
we
we
do
the
managed
branching.
You
know
managed
versioning
work
for
pages,
so
now
they've
got
stable
branches,
they're,
getting
us
to
tag
their
stuff
and
and
we're
also
updating
the
gitlab
org
version
file
for
them
in
the
gitlab
or
repo.
So
we're
doing
all
that
now,
but
then
we're
saying
that
they
want
so
the
pages
developers
also
want
to
bump
that
file
themselves.
Sometime.
C
C
Okay,
yeah,
I
understand.
Let
me
try
to
re-ask
you
a
question
see
if
I
understood
what
you're
asking
so,
but
so
when
we,
when
we
talk
about
tagging,
so
managed
versions
and
tagging
we
are
not.
So
we
just
take
a
snapshot
of
something
and
re-label
everything
and
tag
everything
and
create
packages.
C
So
in
in
all
the
conversation
around
this
there's,
there's
no
say
input
from
developers,
because
developers
will
not
be
part
of
this.
We
will
just
take
care
of
what
was
deployed
and
propagate
for
that.
That's
for
the
monthly
patches
are
different.
Patches
are
stable
branches.
There
fine
tag,
so
there's
no,
there's
no
checking
anything.
It's
just
gotcha!
It's
a
monthly
is
a
we.
We
need
to
generate
stable
branches
from
something.
If
not,
we
already
have
stable
branches.
So
it's
tagged
and
published
what
what
where?
Where
do
we
have?
C
That's
the
thing
right
so-
and
this
is
was
part
of
my
conv,
my
question
earlier,
which
is
today
they
if
they
want
to
update
pages.
B
C
B
I
get
what
you're
saying
so
at
the
moment
they
can
like
for
auto,
deploying
they
create
a
release
and
then
say,
update
the
master,
the
version
file
and
get
blood.org
with
that
release
number.
But
we're
going
to
be-
and
I
see
the
I
see
the
com-
well
not
confusion,
but
I
do
see
what
we
have
to
be
careful
of
is
we
are
taking
we're,
saying
we're
going
to
you,
don't
have
to
release
anymore,
we
release
for
you,
but
then
they're
going
to
be
confused
because
they're
like
well
to
update
auto,
deploy.
B
B
I
think
you're
right
so
we
either
have
to
they
have
to
build
for,
like
that,
becomes
an
a
requirement
for
this
process.
Is
they
can
they
can
build
their
packages
successfully
for
auto,
deploy
from
char
like
that
has
to
become
a
hard
requirement
or-
and
I'm
not
even
sure,
if
I
like
this
idea,
they
can
just
tag
with
an
arbitrarily
name.
B
So
really
I'm
okay,
if
we
just
say
yeah,
no
you've
got
to
do
the
work,
have
a
small
or
big
to
actually
be
able
to
release
from
shah,
and
I
think
it
makes
sense
too
because
in
my
mind,
of
continued
auto
deploy
is
designed
as
a
continuous
delivery
process
and
so
the
point
of
continuous
delivery
process.
Is
you
shouldn't
be
manually?
B
Doing
this
release
thing?
You
should
be
trusting
the
auto
release
process,
so
I
think
you're.
I
I
think
we
have
to
put
as
part
of
managed
versioning
requirement
is
that
your
product
must
be
able
to
be
built
from
a
show
just
so
that
way
we
remove
that
part
and
then
that
way,
auto
deploys
just
function
like
that.
We
take
away
releases
from
you
and
you
get
into
auto,
deploy
with
just
building
by
shire,
and
that
just
happens
automatically.
B
If
they
want
they
might
start,
and
in
this
case
they
might
start
with
the
doing
the
show
themselves,
so
they
were
like
okay,
we
want
to
take
this
shot
from
us
and
not
maybe
not
the
well
yeah.
I
don't
know
they
might
not
just
want
to
immediately
jump
into
the
the
what
we
call
giddily
updater
right,
which
we're
going.
B
Remain
but
they're
automatically
like
looking
at
pipeline
and
just
bumping
bumping
bumping.
They
might
want
to
still
do
that
manually,
but
it
still
has
to
be
a
shower
and
we
just
say
that's
the
shower
and
then
that
will
still
work
fine,
because
the
shower
will
go
out
and
order
deploy
out
and
then
we
can,
you
know,
tag
still
based
off
the
delivery,
sorry,
the
deployments
and
environments
of
what's
running
and
what
environment
and
everything
will
work
but
yeah.
Now
that
is
a
good
point
that
we
do
need
to
be
clear
about
that
as
well.
B
C
C
B
B
C
C
C
So
if
we
can
build
from
the
sha
something
we
need
to
verify,
then
they
can
start
putting
shot
right
today,
so
yeah
yeah,
exactly
eventually,
if
we're
gonna
make
monthly
release,
and
all
of
this
is
not
ready,
they
will
still
have
a
the
package
will
still
be
working.
That's
the
important
part
right,
because
we
propagate
the
version
files,
so
they
will
just
if,
if
ever
we
are
going
to
make
a
batch
release
or
security
release
for
pages
in
that
milestone,
gonna
be
tricky
because
say
what
what
pages
was
in
there?
Nothing
yeah!
C
C
If
and
and
this
this
works
or
not
right
but
yeah.
I
agree
with
you.
We
should
put
the
build
from
sha
as
a
hard
requirement.
We
should
put
this
up
front
to
developer
and
we
should
be
describing
this
the
benefit
of
this
right
because
the
in
the
end
today
they
do
cutting
a
release
with
changelog
all
the
shorts
plus
bumping,
we're
gonna
say
in
at
this
stage
of
automation
you
still
have
to
bump
manually,
but
you
bump
with
a
shot.
So
you.
C
Of
the
shot,
that's
it
and
then
it's
also
easier
to
figure
out
what
what's.
What's
the
diff
right,
because
you
you
take
the
old
shot
and
say,
give
me
the
div,
since
this
shot
and
kind
of
give
you
how
how
back
you
are
from
master,
but
they
still
retain
control,
and
then
we
can.
We
can
suggest
do
with
automation.
B
C
C
We
can
take
on
releases
for
you,
but
you
don't
have
to
tag
anymore,
so
you
update
these
pages
by
bumping
the
the
shop,
but
this
is
something
we
can
already
test
internally,
because
we
can
just
coordinate
with
them
and
say:
okay,
can
we
bump
this
version
file
right
now
to
see
if,
if
the
package
goes
through,
I
mean
we
can
test
manually
while
triggering
manual
builds
on
cng
and
omnibus?
This
is
possible.
We
can
even
do
this
up
front
just
as
a
validation
the
pipeline
gets
to
the
end.
We
have
working
packages.
C
Fine,
then
next
step
take
an
auto
deploy
branch
whatever
it
is
and
commit
change
on
on
the
gitlab
pages
version
file.
We
just
replaced
the
same
version
instead
of
referring
it
by
the
shop
right
there.
Sorry,
by
the
time
we.
C
So
end
result:
we
will
deploy
the
same
thing
just
so
wasted
deployment,
but
it
will.
It
would
give
us
an
extra
hint
that,
yes,
this
can
work.
Okay,
and
once
we
have
all
these
things
in
place,
we
we
can
decide
to
just
say
hold
on
on
this.
We
will
build
the
automation
and
then
you
switch
using
sha
or
we
can
see
just
you
can
start
using
right
now.
B
Yeah
yeah,
that
makes
sense.
Okay,
so
that's
another
pre-requisite
issue,
then
I'll
open,
because
that
that
sounds
pretty
important.
We
need
that
done.
I
mean
in
general.
We
need
these
components
in
auto,
deploy
like
they
need
to
be
re
like,
or
they
need
to
be
doing
this
in
auto,
deploy
just
thinking
about
cat
like
we're
talking
about
pages
today,
which
is
great
but
thinking
about
cars
like
they're,
not
even
in
auto,
deploy
at
the
moment,
which
is
fine,
because
that's
that's
one
of
okrs
and
that's
in
progress
but
yeah.
B
It
sounds
like
we
really
need
to
get
that
in
in
in.
We
really
need
to
get
them
in
auto,
deploy
and
that
piece
together
as
well.
It's
like
you're,
not
using
you
know
you
need
to
be
able
to
build
from
a
shower
so
that
you're
slowly
walking
away
from
the
concept
of
tags
yourself,
so
that
you're
ready
for
us
to
take
over
and
I
and
I
think
we
yeah
we'll
we'll
push
against
well,
not
against,
but
we'll
we'll
say,
try
to
avoid
internal
tags,
because
I
think
it'll
lead
to
more
confusion.
B
B
I've
made
this
internal
tag
like
I
do
see
it
in
conversations
already,
and
I
think
this
goes
to
what
you
were
saying
unless
you're
about
talking
to
the
team
and
about
making
sure
they're
on
board
is
that
it's
definitely
easy
for
them
to
be
like
wanting
to
pick
and
choose
the
pieces
they
get
at
a
very
low
level.
I
want
you
to.
I
want
to
do
the
tap
my
own
tagging,
but
I
want
you
to
like
somehow
make
it
all
work
into
the
thing
we
can't.
B
A
I
mean
we
certainly
like
we
can't
provide
every
service
right
now.
So
I
think
this
is
another
thing
where
we
can
kind
of
choose
what
order
we
roll
things
out
and
people
can
opt
in
at
that
stage
or,
if
that
doesn't
meet
their
needs
not
and
over
time,
maybe
we'll
end
up
with
all
components
haven't
opted
in
for
the
same
reason
we
can
address
that,
but
if
we
end
up
with
lots
of
people
wanting
very
unique
stuff,
then
you
know,
I
don't
think
we
can
try
and
support
that.
B
Do
we
even
need
to
for
these
components
that
we
are
like
you're
in
the
gitlab
manager?
Sorry,
the
you
know
the
managed
versioning
scheme.
Should
we
even
be
having
a
very
small
check
in
the
gitlab.org,
get
lab
repo
a
ci
check
so
that
those
version
files
do
like
if
you're
a
master
or
whatever
they
have
to
contain
a
sha,
and
it's
got
to
be
a
ballad
show
on
the
other
reaper.
Do
you
know
what
I
mean
like?
Should
we
be
like
hard
enforcing
that
so
that
people
don't
know
that.
C
So
gizly
is
built
as
part
of
the
ci
of
the
gitlab
org
ci
from
the
content
of
the
thing,
so
it
is
not
checking
if
it's
a
sha
or
not
because
again
when
they
need
to
bump
the
the
version
because
they're
releasing
the
jam,
they
can
put
a
tag
in
there,
so
we
need
something
that
is
buildable
yeah
and
so
what
we
are,
what
we
will
end
up
doing
is
no
matter
what
you
write
there.
Maybe
you
wrote
the
an
rc
version
or,
and
anything
you
think
you,
you
wrote
something
there.
C
B
A
I
think
what
we'll
see
what
will
be
really
interesting
to
see
actually
is,
as
we
put
these
options
together
and
have
like
the
kind
of
like
gains
and
losses,
I
guess
of
what
people
will
or
get
it'll
be
very
interesting
to
see
which
stage
groups
like
do
they
or
are
they
fine
with
that
or
actually
do
we
see
a
kind
of
a
theme
appearing
that
people
don't
like
certain
aspects,
but
I
think
we'll
have
to
just
get
that
together
and
ask
them.
A
It
feels
like,
if
we
get
this,
if
we
got
that
really
clearly
written
out
for
the
pages
one
it
we
could.
It
would
be
pretty
easy
for
us
to
also
just
move
copy
that
over
onto
the
cars
epic,
and
we
could
ask
them
at
the
same
time,
because
we
know
we're
waiting
on
canary
for
the
auto
deploy,
but
it
would
be
interesting
just
to
double
check
like
that.
They
are
really
okay
with
like
what
they're
going
to
like
the
process.
Change
they'll
get
from
that
stuff.
A
C
B
So
I
will
go
to
that
epic
I'll
might
I'll
merge,
there's
two
issues
there.
I
need
to
merge,
that's
fine
and
I'm
going
to
add
two
new
ones.
One
is
pages
needs
to
get
building
in
a
shower,
and
basically
the
auto
deploy
setup
now
needs
to
change
slightly
so
they're
not
cutting
their
own
releases,
they're,
not
relying
on
their
own
internal
on
their
own
releases
to
auto,
deploy
and
then
the
second
one
will
be.
B
Yeah,
I
have
to
figure
out
the
phrasing
but
yeah
like
what
do
we
need
to
do
like
fair
enough
when
we
tag
than
it
like?
Let's
say
we
turn
the
button
on
or
the
feature
flag
on
and
the
next
rc
that
gets
created.
It
all
happily
works,
but
what
does
that
mean
for
existing
like
what?
What's
the
plan
for
existing
releases?
And
I
think
the
situation
is
going
to
be
someone
just
sits
down
and
like
sets
up
everything
previously
for
the
past,
like
three
supportive
releases,
yeah.
A
Yeah,
that
makes
sense
yeah
and
we
should
somewhere.
I
don't
know
if
it's
either
in
that
issue
or
on
the
epic
exit
criteria
or
something
we
should
just
make
sure.
We've
gone
through
like
a
security
release
and
a
patch
release,
and
you
know,
ticked
off
all
the
different
types
of
releases.
But
we
can.
We
can
build
that
in.
B
A
A
Yes,
so
I
was
just
wondering:
would
you
be
willing
to
take
on
the
action
to
just
put
together?
The
summary
of,
if
you
adopt
managed
versioning
here
is
here
is
the
process
you
will
get
here?
Are
the
changes
that
will
possibly
become
good
and
bad
and
maybe
any
constraints
that
will
come
with
that.
So
some.
A
Mean
yeah
absolutely,
or
even
I
mean
I'm
not
even
like
as
much
as
that.
Right,
like
you
know,
literally
just
I
guess
enough
that
we
can
to
get
the
pages
maintainers
to
actually
have
something
they
can
look
at
and
actually
see.
Oh
okay,
so
this
is
what's
going
to
happen.
B
Yeah,
I
guess
that's
a
good
way
of
putting
it
like.
I,
I
think
it's
worthwhile
saying
so
on
a
security
release.
This
is
what
you'll
do
merge
onto
your
three
stable
branches
and
then
nothing
like,
for
example
like
that.
Might
I
don't
know
what
it
is
but
and
then
I
think
also
we
do
need
to
call
that
explicitly.
You
no
longer
tag.
You
know
you
know.
B
Think
changelog
will
be
another
big
one
as
well.
It
sounds
like
there's
a
there's,
some
interesting
trade-offs.
We
people
will
need
to
understand
about
change
logs,
like
I
I
don't
know,
pages
do
have
their
own
change
log
process.
Hopefully
it's
similar,
but
I'm
guessing
it's
probably
not.
So
we
should
yeah
well.
B
I
I
think
overall,
I
don't
think
funny
might
be
finding
me
saying
this
now.
I
don't
think
we're
going
to
have
huge
pushback.
If
we
can,
I
I
think
I
think
it's
hard
for
people
to
understand,
but
once
they
understand
hopefully
it'll
be
clear.
I
think
like
like
people
will
be
happy.
I
think,
as
I
said
it
it,
we
do
have
to
answer
all
those
questions.
It's
all
those
questions,
as
you
brought
up
a
lesson
of
like
well,
I'm
so
used
to
doing
this.
How
does
that
affect
that
other
process?
C
So
internally,
because
we
started
this
conversation
at
the
beginning
about
the
requirement
of
tracking
deployment
on
one
side
and
then
we
ended
up
with
the
other
conversation
about.
We
actually
track
on
the
metadata
layer.
But
probably
we
are
not
reading
that
information.
B
Okay,
so
you're
you're
looking
to
break
that
dependency
now
on
looking
at
the
canonical
environments
and
deployments
page
yeah,
I'm
okay
with
that
makes
sense
like,
and
then
we
basically
we
we
start
to.
We
slowly
inch
around
this
idea
of
the
metadata
repository
yeah,
really
absolute
center
of
truth
yeah.
That
makes
sense
to
me.
C
C
So
this
is
an
extra
item
in
the
epics,
which
is
some
kind
of
refactor.
The
tagging
command
to
take
a
look
at
the
product
version
or
release
metadata,
how
you
like
it
to
to
figure
out
the
the
source,
the
search
for
the
new
branches.
B
Yep
that
that
makes
sense
cool
so
do
that
and
make
pages
build
from
sure
and
then.
B
A
Did
we
address
the
question
alessia
that
you
raised
about
patch
releases
like
I
think
we
kind
of
talked
around
it
a
little,
but
we
are
we
in
agreement
that
managed
versions
gives
you
like
a
whole
everything
yeah,
everybody.
C
B
B
B
C
So
I
think
that
what
we
ended
up
doing
with
pages
sorry
with
easily
is
not
that
bad
in
the
sense
that
the
gem
itself
is
not
managed
by
us.
So
when
they
want
to
bump
the
version
they
bump
it
to
another
sea,
so
they
do
their
own
overseas,
so
they
can
publish
and
then
they
bump
it
to
an
rc,
because
this
is
not
really
that
much
visible
to
the
end
customers.
Just
an
internal
detail.
No.
B
B
I
guess
the
thing
is:
is
it's
like
we're
selling
people
you
get
away
from
all
these
like?
Do
you
go
to
cars
and
say
you
don't
have
to
tag
anymore,
we're
doing
all
this,
oh
by
the
way,
because
you've
got
this
ruby
gem,
then
you
kind
of
still
need
to
do
some
tagging.
Maybe
that
that's
what
I'm
worried
about.
I
guess
it's
like
I'm,
perhaps
a
little
bit
of
a
mixed
message,
not
that
I'm,
but
I
I
don't
know
the
solution
but
yeah
it's
and
maybe
there
isn't
a
solution,
but
it
is
tricky.
I.
A
B
B
A
Yeah
definitely
well
it'll
be
interesting
to
see
as
we
go
through
a
few
components
like
how
common
a
theme
this
is,
I'm
getting
really
curious
to
see
like
what
how
pages
like,
if
this
is
what
they
were
understanding
they
were
getting
or
how
they
feel
about
this
kind
of
offer.
B
It's
going
to
be
something
that's
going
to
come
up
straight
away
as
soon
as
we
start
doing,
independent
deploys,
because
then
that
goes
out
the
window,
because
you
can't
really
be
like,
because
you
can't
bump
the
gem
and
the
rail
side
and
deploy
your
own
component
whenever
you
want.
If
I'm
understanding
things.
C
C
A
B
A
One
thing
I
just
wanted
to
mention
a
little
bit
so
game
url
next
week,
myra
is
coming
out
of
release
management
next
thursday,
so
she'll
also
be
able
to
after
that
join
in,
but
it
probably
be
good
for
us
to
at
least
check
in
with
pages
maintainers
and
know
if
we're
going
ahead
with
this
one
or
not,
and
if
we
are
great,
we
can
get
things
set
up.
If
we're
not,
we
can
go
figure
out
whether
we
have
another
stage
group
who
are
ready
to
work
with
us.