►
From YouTube: New Staging Kickoff
A
Hey
everyone:
this
is
mack
vp
of
quality,
join
joined
me
by
vincey,
wilson
manager
of
quality
engineering
and
multiple
product
areas.
This
is
the
video
overview
for
our
team.
That's
embarking
on
the
effort
to
improve
our
testing
capabilities
in
staging.
A
This
is
born
out
of
the
the
need
to
address
multiple
corrective
actions.
Add
in
testing
capabilities.
That's
been
requested
by
so
many
people
in
quality
and
development,
going
forward
I'll,
go
ahead
and
share
my
screen
and
run
over
the
the
strategy
in
a
bit
lindsay.
Can
you
see
my
screen
cool?
Thank
you.
A
So
we
had
a
a
mix
of
incidents
related
to
mixed
deployment
that
had
that
has
sparked
the
reason
why
we're
doing
this,
but
that's
not
the
only
reason
why
we've
had
asks
from
from
people
inside
the
company,
especially
in
development
and
quality,
but
they
really
want
to
test
things
in
staging
and
they
cannot
they're
not
able
to,
for
example,
testing,
multiple
tiers
of
payments
access
groups
and
getting
admin
request.
Admin
access
to
be
able
to
do
this.
A
We're
not
able
to
do
this
in
the
16th
station,
and
this
is
where
we're
going
to
go
to
address
these.
These
deficiencies
immediately,
so
I
have
underscored
the
new
things
with
with
the
word
new
here:
we're
gonna
work
on
a
canary
note
for
the
existing
staging
and
we're
gonna.
We're
gonna
call
it
station
canary.
Please
pay
attention
to
the
bold
letters
here,
because
we're
going
to
stick
to
terminologies
for
district
to
make
sure
that
you
know
which
ones
we
are
talking
about
to
test
mixed
deployments.
A
We
need
a
canary
node
to
mirror
what
production
is,
which
is
where
migrations
are
not
compatible
and
one
of
them.
The
the
the
first
version
sits
in
the
the
production
node
and
the
the
incompatibility
one
sits
on
the
canary
node.
It's
called
primary
and
canary
to
do
this.
We
want
we
need
to
add
a
staging
canary
into
staging,
and
this
is
the
fastest
roi
for
us
to
catch
this
mixed
deployment
failures.
A
So
the
task
list
for
that
is
to
set
up
the
the
canary
note.
We
are
in
the
release
tools.
We
make
sure
that
we
have
tests
to
catch
mixed
deployment
workflow
and
then
also.
We
want
to
make
sure
that
the
existing
test
suite
in
staging
gets
addressed
in
terms
of
instabilities,
any
things
that
we
need
to
do
to
make
sure
that
the
suite
that
runs
reliable
reliability.
A
That
is
it
for
the
the
mixed
deployment
track,
and
that
is
the
augmentation
we're
doing
in
the
existing
deployment
first
staging
now.
We,
that
is
not
enough.
We
really
want
to
step
ahead
of
the
the
inefficiencies
and
challenges
and
provide
tooling.
That
is
really
in
the
spirit
of
quality,
is
everyone's
responsibility.
A
We
need
accounts
that
are
already
configured
in
all
the
the
access
admin
owner
maintainer
reporter,
and
we
may
even
move
into
a
data
model
where
we
have
testing
areas
that
is
dedicated
for
each
product
groups,
sub
department
and
so
on,
so
the
vehicle
to
get
us
there
is
this
new
environment
based
on
the
10k
reference
architecture,
we're
going
to
set
it
up
with
with
get,
and
so
this
is
going
to
be
the
nipple
place
where
we
rinse
and
repeat
fast,
going
forward.
A
When
I
say
rinse
and
repeat
fast,
because
there's
a
lot
of
mystery
behind
setting
up
new
environments
at
this
point,
there's
monitoring,
there's
provisioning,
there's,
there's
a
wiring
test
data
wiring
in
release
tools,
configuring
gitlab
qa
at
at
load
testing
and
there's
a
lot
of
hardship
in
the
in
this
startup
process,
and
then
and-
and
I
aim
to
just
remove
all
those
mysterious
curtains-
and
this
proved
to
ourselves
that
we
could
rinse
and
repeat
setting
up
this
environment
fast
and
tearing
it
down
fast.
A
Here
this
is
a
longer
laundry
list
because
we're
doing
it
from
scratch,
we're
dog
food
and
get
we're
accounting
wiring
the
release
tools,
creating
test
data,
new
test
accounts,
broadly
to
democratize,
testing,
for
especially
for
development
and
quality
teams,
adding
load
testing
having
the
same
monitoring
as
what
we
have.
So
this
is
the
again
rinse
repeat
fast
next
onto
the
strategy
track.
The
reason
we're
doing
this
is
we
don't
want
to
create
any
number
of
staging?
I
don't.
I
don't
want
us
to
create
another
5k
staging
or
a
1k
station.
A
If
we
need
new
capabilities,
we
add
it
to
the
10k
reference
architecture,
staging
that's
going
to
be
where
we
rinse
and
repeat
fast,
and
we
want
to
limit
the
number
of
staging
intentionally.
So
if
we
need
new
things
make
sure
we
can
add
on
to
it,
set
it
up
again.
If
we
need
to
this
is
where
we
we
will
go
in
terms
of
making
sure
that
we
have
a
more
robust,
fully
capable
enhanced
capabilities
testing
before
we
reach
production
long
term.
We
also
need
to
factor
in
geo.
A
The
geo
team
has
their
own
staging
as
well.
This
new
10k
will
include
testing
of
geo,
but
that'll
be
a
place
where
we
have
an
opportunity
to
tear
down
and
set
it
up
again
and
then,
and
next
up
is
making
sure.
A
All
of
you
understand
why
we're
doing
this
documenting
in
the
handbook
and
then
also
communicating
it
broadly
for
the
for
the
immediate
folks
that
are
watching
this
video,
the
people
that
have
graciously
volunteered
to
to
help
out
so
nelia
sansef
ian
pierre
vinci,
you're
helping
to
do
the
project
management.
Here.
Please
review
this
video
going
forward
next
steps.
I
will
create
all
these
as
a
task
list
into
the
projects
that
we
are
going
to
track.
So
there
are,
there
are
three
projects
we
are
tracking.
A
This
tasking
one
is
the
infrastructure
issue.
We
will
track
the
overall
task
in
the
gitlab
main
issue
and,
if
there's
anything
that
we
need
to
enhance
get
which
is
the
consolidation
tools
of
choice
for
provisioning
going
forward,
then
we
will
add
things
there
as
well.
So
that's
it
for
the
overview.
I
hope
you
all
get
to
watch
this
and
then
ask
questions
we'll,
be
sending
out
a
agenda
to
list
questions
and
then
we'll
kick
off
now
and
thanks
for
watching.