►
From YouTube: Infrastructure as Code plans
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
Let
me
share
my
screen
and
I
will
start
with
a
quick
walkthrough
so
raise
my
screen,
and
this
is
our
infrastructure
scored,
viable
epic,
it's
epic,
not
1960,
and
basically
what
you
can
see
here.
It's
really
in
priority
order.
How
we
plan
to
ship
the
features
to
you
to
add
them
together.
The
first
two
issues
here
are
more
about
preparatory
issues
where
we
get
all
the
team
up
to
speed
and
we
are
doing
some
UX
research
in
terms
of
UX
research.
A
We
try
to
set
up
user
journey
and
I
will
be
happy
to
discuss
this
journey
with
you.
What
we
have
right
now
is
already
pretty
complex.
It
involves
the
infrastructure
teams
workflows
like
setting
that
leads
to
actual
managing
term
for
modules
and
other
stuff,
but
it
involves
as
well
how
a
developer
code
from
a
gate
commit
ends
up
into
deployment
through
creating
a
docker
image,
for
example
or
various
ways.
A
A
A
One
of
the
first
topics
we
would
like
to
write
down
is
actually
recommended,
gitlab
recommended
in
such
as
flow
setup.
This
would
be
something
similar
to
what
we
have
right
now,
we'll
get
the
gitlab
flow
itself,
because
we
hear
quite
often
users
asking
us
what
is
the
recommended
way
of
setting
up
interest
code
inside
of
it
lab
here
we
will
try
to
describe
a
few
setups
that
we
think
are
useful
and
for
the
industry
best
practices,
and
actually
this
will
lead
our
development
further
in
the
future
as
well.
A
A
It
should
be
if
nobody
touched
it
by
hand
as
a
result,
when
you
change
your
turf
from
code
before
applying
those
changes,
start
from
compares
what
your
code
expects
to
have
to
what
your
state
currently
has,
and
this
difference
is
called
the
term
from
plan.
When
you
make
a
change
in
gate,
we
have
the
merge
request
to
review
your
change
files,
but
in
case
of
terraform,
you
actually
would
like
to
review
your
travel
plans
as
well.
A
A
Then
we
have
the
gitlab
manager
from
state.
This
basically
would
mean
that
we
would
like
to
make
it
super
easy
for
you
to
start
new
terraform
project
with
convention.
Over
configuration
set
up,
good
lab
would
basically
say
that
your
state
file
is
stored
in
this
s3
or
GCP
bucket
it's
encrypted,
it's
versioned,
etc,
and
you
don't
have
to
enforce
these
logics
and
it
will
be
pretty
clear
and
well-documented
for
you
at
the
same
time.
A
Actually
it
helps
us
as
well
to
be
more
integrational
and
perform,
because,
basically
the
single
click
you
can
get
a
turn
from
run
deployment
using
Whitlam.
Instead,
then,
you
would
like
to
provide
a
trap
for
module
registry.
This
is
this
item
member
free
here
as
well
at
the
top.
The
refers
between
these
two
lines
is
that
the
community
contribution
started
a
few
weeks
ago
at
the
same
time,
and
we
were
writing
our
own
plan.
A
Currently,
you
can
use
four
modules
bid
gate
lab
either
by
having
those
modules
in
the
same
project
and
just
referencing
them
by
the
path
or
you
can
use
them
with
beat
tags
with
references
having
the
proper
module
registry
will
allow
us
to
use
versioning
scheme
and
villa
laws,
basically
summer-like
versioning,
and
make
it
much
more
flexible
for
you
and
much
more
easier
to
maintain
your
modules
and
especially
their
references
to
your
modules.
These
are
basically
our
top
priorities
for
the
coming
months.
A
The
next
one
is
the
getting
started
to
reform
is
more
of
a
nice-to-have
thing
for
companies
who
are
just
moving
toward
star
form
to
make
it
easy
to
set
up
track
from
project
and
get
going
with
draw
form.
Basically,
these
are
plans,
and
this
is
that.
Are
we
going
to
more
detail
video
during
our
cad
meeting.