►
From YouTube: Understanding GitOps usecases
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
A
A
Githubs
dev
circuits
and
cicd
can
always
find
me
on
twitter
at
circe247,
but
first
what
is
githubs
basically
now,
according
to
the
github's
working
group,
it's
simply
a
set
of
principles
around
how
the
whole
systems
we
use
for
our
infrastructure
is
managed
now,
and
these
principles
that
have
been
stated
by
the
ktops
working
group
are
the
creative
desired
stage
version
and
immutable
state,
continuous
reconciliation
by
pulling
automatically
and
also
operations
through
constellation.
A
But
the
key
things
I
want
us
to
take
from
all
these
principles
is
definitely
you
need
to
declare
how
your
infrastructure
should
look
like
if
we
are
already
aware
of
infrastructure
as
code
where
you
can
use
tools
like
terraform
or
any
other,
to
work
when
it
is,
if
you
are
using
home
to
describe
okay.
This
is
how
I
want
my
kubernetes
cluster
to
be.
This
is
the
number
of
nodes.
This
is
the
number
of
pods.
A
A
A
Devops
is
a
culture,
it's
how
you
do
things
and
how
you
ensure
that
your
application
moves
from
development
to
production
and
back
because
once
it
gets
to
production,
you
need
to
be
track
it
you
need
to
do
your
tracing
and
go
back
and
recommendations.
Go
back
to
the
development
stream
to
maintain
the
circle.
A
Number
four
git
of
skipped
ops
mainly
focused
on
ensuring
that
your
infrastructure
is
deployed
and
is
maintained
as
you
require,
and
the
way
your
application
moves
to
your
production
environment
is
also
maintained
efficiently.
That
is
the
goal
of
github.
That's
you've
written
how
your
application
should
be
and
how
you
are
sorry
how
your
infrastructure
should
look
like
and
how
your
application
should
be
deployed
to
that
infrastructure.
A
Then
all
the
process
of
testing
of
version,
control,
building
images
and
so
on
down
to
deploying
them
mostly
to
kubernetes
to
kubernetes
cluster
is
what
githubs
is
about
now.
Also,
someone
would
ask,
what's
basically
the
difference
between
githubs
and
infrastructure
as
code,
because
it
feels
like
it's
just
some
new
way
of
bringing
infrastructure
as
good.
A
You
might
say
that,
but
the
difference
here
is:
let's
put
it
this
way.
Githubs
is
like
when
infrastructure
has
code,
meets
much
request
or
pull
request.
That
is,
people
can
collaborate.
Let
me
make
changes
to
your
application.
Probably
your
developers
discovered.
Oh,
they
need
more
resources
for
to
run
certain
applications
or
they
need
to
request
for
more
server
resources.
They
create
a
pro
request
or
email
request
and
cicd
runs
all
your
necessary
policy
checks
and
all
your
testing
against
the
submissions
they've
made
before
the
application
gets
deployed.
A
A
The
infrastructure
has
codes
that
you
for
a
code
that
you've
created
once
it
has
been
accepted
by
your
policies
and
push
to
probably
a
production
branch
or
some
branch
system
that
you
have
for
your
workflow.
You
have,
or
probably
probably,
to
some
image
repository
somewhere.
You
have
your
on
on
your
community's
cluster
infrastructure.
You
will
have
an
agent
that
will
constantly
be
pulling
and
be
checking
that
production
branch
that
you've
specified
for
where
your
disaster
would
be
to
constantly
see.
A
If
there
are
new
changes,
it
pulls
them
or
it
should
be,
checking
an
image
repository
where
the
image
of
your
application
has
been
stored
and
anytime.
There
is
a
new
change.
It
pulls
it
and
applies
them
to
your
infrastructure,
and
it
also
ensures
regularly
automatically
to
check,
which
is
where
con
operations
via
continuous
reconciliation
comes
in
to
check
the
desired
state
against
the
actual
state
idea.
Changes
have
things
improved
or
are
there
new
updates
or
is
there
any
issue?
That's
happened
on
the
cluster,
that's
making
that
has
now
made
the
two
environments
to
be
different.
A
Then
it
automatically
reconcile
pull
the
most
recent
or
the
most
updated
code
from
your
repository
or
your
production
branch
and
apply
them
while
for
infrastructure
asphalt,
new
change
has
to
be
introduced
before
it
is
pushed
to
production.
A
You
need
to
push
it
to
either
your
community's
cluster,
your
infrastructure,
for
it's
to
be
deployed
now,
but
in
the
pool
strategy,
the
agent
there's
an
agent
in
your
communities,
cluster
that
will
constantly
look
out
for
new
changes
and
pull
those
changes
to
your
cluster
to
be
applied
to
your
cluster.
Now.
One
advantage
of
this
is
your
secrets
and
your
some
other
critical
things
that
are
necessary
for
your
cluster
to
run
are
stored
on
the
cluster.
A
A
While
for
pool
strategy,
the
agent
is
already
living
within
the
same
cluster
as
where
your
applications
will
be
deployed.
So
it
only
needs
to
communicate
with
the
repository
to
confirm
if
there
are
new
changes
and
post
them.
Now,
let's
see
a
pictorial
presentation
of
what
a
pool
department
would
look
like
this
image
was
taken
from
the
github
store
tech
website.
A
Now,
we'll
see
here,
we
see
here
that
you
have
your
code
or
your
application
in
your
application
repository
when
changes
are
done,
it
triggers
a
pipeline
and
that
pipeline
runs
all
the
necessary
jobs
or
all
the
necessary
things
that
you
really
jobs
that
you
need
to
confirm.
A
If
everything
is
located
or
to
build
images,
then
it
pushes
the
images
to
your
image,
repository
like
with
the
current
history
or
gitlab
image
registry
and
also
maintains
updates
your
environmental
repository,
while
in
your
environment,
which
most
often
is
your
kubernetes
cluster,
the
agent
you
have
in
this
case,
which,
in
the
case
of
this
image
you're
calling
an
operator,
will
constantly
check
your
image
registry
or
your
environment
repository
to
confirm
other
new
changes
at
the
end
you
update.
If
there
are,
it
then
pulls
those
changes
and
applies
them
now.
A
A
A
The
top
level
management
can
be
able
to
review
changes
that
are
happening
and
they
can
be
able
to
approve
or
make
recommendations
to
the
requested
changes
and
the
sres
or
infrastructure
engineers
who
have
access
to
actually
let
this
team
get
to
play
can
also
see
all
the
things
that
have
been
done
and
are
proof
before
it
goes
forward
now.
This
also
allows
everyone
to
be
knowledgeable
about
what
the
infrastructure
looks
like
how
things
are
being
deployed
and
be
able
to
contribute
new
knowledge
to
the
rest
of
the
team.
A
Now
one
key
advantage.
Another
key
advantage
of
using
githubs
as
defined
by
the
github's
working
group
is
your
secrets,
are
now
secure
because
you
don't
need
to
maintain
your
secrets
in
different
places
like
okay,
you
need
to
set
up,
for
example,
if
you're
using
gitlab,
you
need
to
set
up
some
secrets
or
you
need
to
integrate
gitlab
with
your
communities
cluster
or
you
need
to
do
a
lot
of
things
to
make
sure
your
project
or
your
repository
can
communicate.
A
Your
gitlab
project
can
communicate
with
the
cluster
to
make
any
deployments
necessary,
but
in
the
case
of
githubs,
if
you
are
using
a
gear,
a
kubernetes
agent,
you
only
need
to
put
your
secrets
in
the
repository,
I'm
sorry
in
your
kubernetes
cluster.
So
all
the
only
communication,
the
only
credentials
that
needs
to
be
configured
with
git
lab
is
the
credential
is
what
tevac
credential
is
necessary
for
the
communities
agent
or
operator
to
pull,
to
pull
or
communicate
with
your
project
to
see
for
changes
that
have
happened
and
deploy
them
now.
A
Lastly,
because
there
is
need,
because
you
already
have
a
mechanism
that
pulls
for
changes,
it's
easier
for
development
to
move
fast
and
deployments
to
happen
at
almost
any
time,
because
constantly
you
don't
necessarily
need
to
go
and
trigger
a
deployment
to
production.
There's
an
engine
that
constantly
pulls
and
sees
what
new
changes
are
there
to
be
deployed.
A
Now,
after
we've
seen
now
that
we've
seen
what
githubs
is
and
why
use
githubs,
the
next
thing
is:
what
exactly
can
you
use
githubs
for,
which
is
the
main?
The
main
part
of
this
presentation,
the
use
cases
the
first
and
the
most
obvious.
One
is
definitely
infrastructure
optimisation.
A
Now
you
have
your
communities
cluster.
How
do
you
maintain
it?
How
do
you
manage
it?
Kubernetes
is,
has
been
created
in
such
a
way
that
you
can
easily
create
a
declarative
state
of
what
your
community's
cluster
should
look
like
what
your
deployment
on
communities
should
look
like.
You
can
create
your
kubernetes
manifest
file
to
define
the
okay,
the
number
of
ports
you
want
to
deploy.
Do
you
how
you
want
your
applications
to
communicate
the
services,
your
your
storage
classes,
your
persistent
volumes,
etc?
A
You
can
define
them
in
a
manifest
and
you
can
even
use
things
like
helm
to
define,
to
use
a
more
descriptive
language
to
define
how
your
application
should
look
like
or
use
helm
charts
to
define.
Okay.
This
is
the
values.yaml5
using
helmchat
to
now
say:
okay,
these
are
the
things
I
need
for
my
home
charts
and
they
are
automatically
deployed
now.
A
You
have
a
mechanism
in
which
your
application
is
pulled
securely.
Your
the
manifests
are
pulled
into
your
environment
and
deployed
in
your
environment,
and
also
you
ensure
that
there
is
reconciliation
between
the
the
this
reconciliation
between
what
is
running
your
infrastructure
and
what
you've
defined.
Now
you
can
now.
The
next
thing
is
drift
management.
A
In
certain
situations,
there
have
been
people
that
decided
to
deploy
some
changes
to
your
cluster
decide.
While
you
have
a
versioned,
a
kit
repository
hosting
probably
your
manifest,
it
can
be
a
huge
mess.
When
sometimes
you
need
to
deploy
things,
and
there
are
some
conflicts
in
how
applications
or
the
cluster
has
been
deployed.
Applications
have
been
deployed
to
the
cluster
with
githubs.
You
can
ensure
that
there
are
no
drifts
any
and
any
time
they
are
drift.
A
It
should
automatically
be
consulted
because
you've
already
defined
how
your
cluster
should
look
like
and
how
your
application
should
be
deployed
to
your
cluster.
The
kubernetes
agent
you
have
or
operator
you
have
in
your
cluster
will
ensure
that
the
2d
disaster
and
the
actual
state
are
the
same.
This
way,
you
avoid
drift
management
completely.
A
And
create
problems
or
probably
take
down
the
infrastructure.
Now
you
need
to
since
github
itself
are
a
set
of
policies.
It
now
depends
on
what
tools
you
use
to
ensure
that
for
every
change
that
I've
made,
the
necessary
checks
are
done.
The
necessary
security
scanning
are
done,
the
necessary
everything
necessary
is
done,
and
there
are
levels
of
approvals.
Okay,
you
might
have
code
owners
set
within
your
project
where,
anytime,
certain
changes
are
made
to
certain
parts
of
the
git
repository.
That
is
maintaining
your
infrastructure
application.
A
Certain
people
must
approve,
or
certain
people
will
be
notified
to
review
and
approve,
and
mostly
because
when
you
use
a
match
request,
you
create
a
match,
request
or
pull
request.
You
create
a
mad
request.
As
soon
as
you
submit
your
match
requests.
There
are
certain
people
that
will
be
notified
to
approve,
maybe
quality
assurance.
There
are,
probably
audits,
probably
are
trying
to
spin
up
more
instances
that
might
cost
the
company
a
lot
of
money.
A
They
need
to
be
able
to
review
and
ensure
that
okay,
we
are
not
going
beyond
or
we
are
not
using
dependencies
that
might
hurt
the
company
and,
as
soon
as
that
is
done
at
the
last
stage,
might
be
the
sru's
who
do
the
final.
Okay,
let's
match
this,
and
as
soon
as
it's
matched
to
your
production
branch
or
infrared
branch
or
it's
compiled
as
an
as
an
image
and
hosted
in
the
repository.
A
That's
all
everything
is
done.
It's
now
left
for
the
kubernetes
agent
to
pull
those
new
changes
otherwise
and
enforcing
this
policy
that
this
policies
means
that
anything
that
gets
to
that
final
stage
of
either
hitting
getting
merged
into
the
production
branch
or
being
built
as
an
image
and
kept
in
the
image.
Repository
has
been
certified
to
be
okay
and
ready
for
production.
A
A
Tooling,
for
all
of
your
infrastructure
is
ensuring
that
all
the
necessary
security
tools
or
security
checks
that
need
to
be
done,
for
example,
maybe
secret
detection,
so
that
none
of
your
application
is
actually
leaking
any
secret
static
application
testing.
You
did
dyna
dust,
the
dynamics,
security
testing
license
compliance,
sometimes
we
add
license.
People
might
mistakenly
add
licenses
that
are
dependencies
that
have
licenses
that
your
organization
don't
support
or
in
certain
scenarios
you
are,
there
are
certain
dependencies
that
probably
this
is
security
reasons
or
due
to
some
other
regulatory
requirements.
A
You
are
not
supposed
to
use
them
and
your
developers
missed
it
or
they
use
the
dependency
that,
for
one
reason
or
the
other
includes
some
of
those
security
challenges.
Some
of
the
things
that
have
the
security
challenges
that
you
are
trying
to
fight
against.
So
all
these
security
checks
ensures
that
nothing
gets
passed.
A
Your
production
branch,
without
you,
detecting,
and
this
and
having
a
security
dashboard,
ensures
this
happen
because
it
gives
your
quality
a
chance
of
security
team,
an
interface
where
they
can
monitor
how
how
many
security
challenges
or
security
vulnerabilities
are
happening
without
having
to
necessarily
even
touch
the
code,
they
would
have
been
able
to
see
okay.
This
is
these
are
the
things
that
happen
or
if
they
need
to
improve
the
scanning
or
add
more
scanning
tools
or
more
things,
but
majorly
to
ensure
that
whatever
gets
to
your
production
branch
has
been
fully
tested
and
reliable.
A
Now
the
next
thing
is
governance
and
compliance.
Now
this
is
especially
for
environment
like
in
fintech
or
banking
industry,
where
there's
a
lot
of
regulation-
and
we
all
know
that
yeah
in
the
startup
world
or
another
tech,
but
it's
just
it's
easy
to
jump
on
it
later,
starting
new
things.
Oh
cuban
is
yeah.
We
are,
we
are
in
serverless
yeah.
We
are
in
the
githubs
yeah
we
are
in
when
regulated
environments
like
banking,
we
have
just
a
lot
of
regulation.
A
A
Where
are
audits
maintained
where
the
retractions
that
have
been
introduced
and
since
we
are
using
git
as
the
main
version
of
control
for
for
key
tops,
it's
easy
to
have
a
history,
a
virtual
history
of
how
an
infrastructure
has
changed,
how
we
introduced
what
when
was
introduced
and
so
on,
and
when
in
your
continuous
integration
pipeline,
you
also
have
tools
that
are
ensuring.
A
There
are
no
issues
in
your
supply
chain.
You,
you
are
using
the
right
dependencies.
They
are
supposed
to
use.
You
are
using.
You
are
following
some
certain
components
to
ensure
you
are
using
the
right
licenses.
You
are
using
the
right,
every
necessary
checks
and
every
requirement
that
are
needed
are
done
down
to
you
having
you
having
your
changes
pushed
production.
A
Ensuring
that
there
is
no
way
in
which
a
compromise
can
happen
or
secrets
can
be
leaked
is
extremely
important.
That
is
where
github
shines
like
githubs
shines,
because,
most
times
your
secrets
live
in
the
kubernetes
cluster.
So
you
have
little
or
no
need
at
all
to
add
your
secret
or
to
expose
your
secrets
within
your
project.
A
Deployed
and
your
infrastructure
is
securely
maintained
and
operated
now,
the
next
thing
is
yeah,
not
everyone
is
using
kubernetes
and
not
everyone
is
using
the
latest
shiny
things
around
the
cloud
native
ecosystem
can
still
use
the
principles
of
githubs
now,
because,
basically,
what
is
github
it's
basically
you
having
a
declarative
state
of
your
infrastructure.
It's
you
ensuring
that
your
your
manifesto,
your
declarative
state,
is
pulled
continuously
to
your
cluster
and
also
ensuring
that
the
two
states
of
your
cluster,
the
design,
desire
that
actual
state
are
continuously
maintained
and
operated.
A
So
now
this
can
apply
to
anything
outside
of
communities.
As
long
as
you
can
use
things
like
teraform
to
define
how
your
application
would
look
like
also
have
something
like
ansible
to
define
how
your
configuration
would
be,
then
you
can
have
some
form
of.
A
Maybe
ci
mechanism
to
ensure
that
continuously,
maybe
after
some
interval,
some
ci
jumps
or
some
script,
runs
to
pull,
to
check
your
production
branch
or
your,
whichever
branch
you're
using
and
compared
to
your
infrastructure,
to
check.
If
there's
any
drift
has
having
changes
in
your
deployed
state,
has
there
been
new
objects
that
have
been
introduced?
Then
it
applies
them
now.
The
main
thing
is
about
the
principles
using
and
living
by.
A
This
is
the
end
of
my
talk
and
I
hope
we
learnt
quite
a
number
of
things
around
the
use
cases
of
github.
If
you
want
to
learn
more
about
githubs
and
other
things
around
it.
These
are
a
few
links,
especially
git
of
the
tech.
That's
where,
if
you
are
new
completely
to
github,
you
can
learn
more
information
about
it.
You
can
also
check
the
open,
github
working
group,
github
page,
that's
where
you
can
see
more
documents
around
the
principles
of
githubs
and
some
of
the
awesome
work
that
they've
done
on
youtube.