►
Description
A re-upload of GitLab's DevOps 101 lecture for CityU's Google Student Developer Club.
Free Licenses of GitLab for Education!
https://about.gitlab.com/solutions/education/join/
A
So
hello,
everyone,
this
talk
for
the
meeting
and
or
the
lecture
is
about
the
devops.
So
we
have
the
pj
and
christina
for
here
they
are
from
gitlab
and
then
we
are
going
to
hand
over
to
them
for
them
to
like
kind
of
give
us
the
introduction
about
what
exactly
is
devops.
And
then
how
can
you
use
data-
or
maybe
you
you
have
used
that
before?
But
you
didn't
know
that
actually
you
are
using
devops
yeah,
so
yeah
table
is
yours.
A
B
C
B
B
With
something
you
might
not
know
anything
about,
but
either
way,
hopefully
today
you
learn
something
new
and
you
can
discover
a
little
more
about
devops.
So,
first
off
an
introduction
to
myself
like
I
was
introduced
earlier,
I
am
a
education
evangelist
at
git
lab
I
go
by
he
him,
so
those
are
my
pronouns.
I
live
in
florida,
I'm
in
orlando
right
now.
B
I
love
disney
because
I
live
in
orlando,
that's
kind
of
our
thing
here
and
really
into
poetry
and
music,
especially
80s,
music
in
80s
and
90s
culture,
and
I'm
a
former
educator.
That's
how
I
came
to
this
position.
I
taught
high
school
english
for
10
years
and
I
also
taught
esau
to
korean
kids.
I
lived
in
korea
for
a
year
and
a
half
and
did
some
esau
education
over
there.
B
If
you
want
to
find
me,
I'm
on
twitter,
at
mets
and
around
I'm
on
gitlab
at
pj
mets
feel
free
to
tag
me
if
you're
ever
working
in
gitlab
and
you're
looking
at
something
and
don't
know
what
to
do
next
and
I'm
also
on
twitch
at
mets
and
around
as
well,
where
I
stream,
maybe
about
once
or
twice
a
week
right
now,
I'm
learning
python.
I
actually
have
my
book
here,
learning
python,
as
well
as
doing
it
online,
because
python
is
not
a
language
I
had
experience
with.
B
B
Software
is
eating
the
world.
This
is
from
mark
andreessen,
who's,
a
famous
venture,
capitalist
and
an
investor
in
tech
and
a
former
software
engineer,
and
what
we
mean
by
this
and
what
I
take
from
this
is
that
software
has
become
a
ubiquitous
part
of
everybody's
life
from
the
moment
that
the
iphone
hit
in
2007
software
became
the
thing
that
everyone
was
going
to
need
to
do.
I
always
tell
people
even
zaxby's,
wendy's
mcdonald's,
they
have
apps
and
those
apps
are
built
for
these
companies.
B
So
you
have
to
have
some
kind
of
software,
and
specifically
we
want
to
talk
about
sweet,
green,
no,
I'm
from
florida.
We
don't
have
sweet
greens
here,
but
I'm
looking
forward
to
getting
one,
because
I
tried
one
when
I
was
on
the
west
coast
once
and
it
was
a
really
good
salad
and
I'm
actually
happy
about
this
picture,
because
that
was
my
order
was
the
kale
season.
I
was
super
excited
about
it,
but
sweet
greens
whole
kind
of
deal
is
that
they
don't
say
we're
just
a
salad
chain.
B
They
say
we're
not
just
a
salad,
restaurant,
we
are
a
tech
company
and
when
they
ipo'd,
they
ipo'd
like
a
tech
company
they're,
not
just
an
app
where
you
build
a
salad
and
get
it
delivered
to
you.
It's
not
just
integrated
with
doordash
or
ubereats,
or
things
like
that.
It
is
a
revolution
in
the
way
that
they
are
approaching
the
supply
chain,
as
well
they're
bringing
tech
to
the
supply
chain.
B
So
everything
from
where
the
food
is
grown
to
how
it's
transported
to
distributors,
all
of
that
process
of
making
a
salad
that
ends
up
in
front
of
you
is
now
being
taken
over
by
software
and
they're
looking
to
change
the
world.
In
that
way,
the
ceo
said:
we
see
sweet
green
as
being
more
than
just
a
restaurant.
We
are
evolving
into
a
food
platform
and
that's
the
way
that
the
new
world
works.
B
B
Common
for
people
who
are
learning
to
code
computer
science,
students,
any
students
that
are
learning
to
code,
you
often
do
it
on
your
own
first,
so
I
started
learning
the
code
in
2020
and
I
stored
all
the
source
code
on
my
computer.
I
compiled
everything
and
ran
everything
locally
and
to
debug.
I
just
looked
at
the
code
right
where
it
was.
I
didn't
have
any
other
tools.
It
was
just
me
myself
and
I
building
a
website
or
building
a
simple
game
in
c
sharp,
something
very
straightforward.
B
It's
just
what's
on
my
computer
and
that's
it,
and
I
remember
I
had
a
moment
when
I
was
working
on
my
first
website
with
a
friend
of
mine.
He
was
helping
me
learn
and
I
was
like
he
told
me
to
run
my
program.
We
were
using
asp.net
core
and
that's
a
c
sharp
back
end
with
some
html
on
the
front
end
and
it
it
ran.
B
And
then
it
gave
me
an
address
and
I
was
like
oh
there's
my
website
and
I
tried
to
send
him
the
link
and
he
was
like
you
can't
send
me
the
link
I
was
like
well.
No,
it's
running
goes
yeah,
it's
running
on
localhost.
That
means
it's
just
on
your
computer
you're,
the
only
one
who
can
see
it.
I
was
like,
oh
well
how?
How
do
I
send
it
to
you,
and
I
was
like
oh
well,
that's
kind
of
the
next
step.
B
I
had
learned
how
to
build
this
website,
but
the
next
step
was
sharing
it
with
people
and
that's
where
we
find
our
two
big
challenges
when
you're
coding,
when
we're
coding
on
our
own,
we
get
to
a
point
where
we
want
to
share
what
we're
building
with
the
world.
We
meet
some
obstacles,
so
first
off
is
collaborating.
If
you
want
to
share
specifically
your
code
with
somebody
say
you're
working
on
something
in
javascript
and
you've
got
a
friend
who
you
think
is
great
at
javascript
and
you
ask
them
hey
I've
got
this
code.
B
I
can't
figure
out
what's
wrong
with
it.
Can
I
show
you
it
and
they're
like
yeah,
you
wouldn't
just
send
them
the
file
as
like
an
attachment
in
an
email,
it's
not
as
efficient.
So
some
way
to
collaborate
on
our
code
is
important.
You
know
when
you're
doing
it
on
your
own.
You
don't
have
to
worry
about
collaboration,
but
software,
especially
the
software.
That's
eating
the
world
is
not
built
on
your
own,
it's
built
as
part
of
a
team,
it's
built
as
part
of
a
team.
B
That's
part
of
a
team
of
teams
that
makes
up
a
company,
so
you
have
to
know
how
to
collaborate
with
friends,
colleagues
or
anyone
else.
So,
if
you're
doing
open
source,
you
need
a
way
that
you
can
work
in
open
source
and
collaborate
on
it.
The
other
challenge
is
to
run
our
code
somewhere,
so
everyone
can
see
it
and
that's
that
local
host
issue
that
I
had
where
I
wanted
people
to
see
my
website,
but
I
needed
the
place
to
host
it.
B
So
this
is
the
software
development
life
cycle.
This
is
how
software
is
made
in
a
very
broad
sense.
So
first
is
the
idea.
Someone
says:
hey.
I've
got
a
great
idea
for
an
app
and
those
of
you
who
are
about
to
graduate
with
cs
degrees,
get
ready.
All
of
your
friends
are
going
to
come
to
you
with
great
ideas
for
apps,
be
ready,
so
ideas
that
solve
a
particular
problem
faced
by
a
set
of
target
users
looking
at
the
world
and
saying
this
is
a
problem
that
needs
fixing.
B
You
know,
we've
got
all
these
taxis
but
they're
so
expensive.
I
mean
what,
if
what,
if
you
were
driving
somewhere
and
you
could
just
give
somebody
a
ride,
that's
how
uber
started
right.
What,
if
you
could
just
deliver
food
from
any
restaurant?
That's
how
doordash
gets
started.
What,
if
you've
got
240
characters
of
an
idea
that
you
really
need
to
shout
at
the
world
and
there's
twitter,
so
there's
some
sort
of
problem
and
the
app
solves
it.
That's
ideation!
B
You
move
on
to
requirements,
you
say:
okay,
what
will
it
take
to
actually
make
this
app
happen?
What
are
the
requirements
of
this
app?
What
are
the
rules?
How
will
it
function?
What
will
it
do
and,
after
that,
it's
design
where
a
team
of
designers
actually
say
this
is
how
it's
going
to
look.
This
is
how
the
flow
for
the
user
is
going
to
move
and
they
design
the
whole
app
visually
as
well
as
structurally
after
that,
it's
development.
This
is
the
part
that
everyone
thinks
about
when
they
think
about
coding
or
an
engineer.
B
Development
writing
the
code
that
makes
the
app
work
after
that
you
have
to
test
it
and
make
sure
that
it
actually
works.
The
way
you
think
test
for
weird
edge
cases
is
always
a
good
idea,
making
sure
that
someone
doesn't
like
hold
down
the
screen
and
hit
the
power
button
at
the
same
time
and
somehow
that
logs
them
into
the
root,
and
then
they
have
access
to
data.
B
These
things
that
happen
inside
of
apps
that
you
have
to
test
for,
oh
well,
they
went
from
the
home
page
directly
to
here
and
that
crashes,
the
app
you
don't
want,
your
app
crashing,
so
you
test
for
it.
Finally,
you
deploy
this
working
app
to
the
world
in
a
place
where
everyone
can
access
it,
whether
that's
to
a
cloud
provider
like
aws
or
google
cloud
or
azure
or
heroku.
B
B
Now,
when
software
started
being
built
in
the
oh,
my
gosh,
like
60s
70s,
it
kind
of
followed
the
same
style
of
production
that
most
of
the
world
did,
which
was
kind
of
an
assembly
line.
It
was
you
make
your
part,
and
then
you
pass
it
to
the
next
team
and
they
make
their
part
and
they
pass
it
to
the
next
team.
It's
very
much
like
the
way
model
t
cars
were
made
in
the
early
20th
century.
B
In
the
1900s
there
was
one
person
who
put
the
wheel
on,
and
the
next
person
put
the
screws
on
to
keep
the
wheel
on
the
next
person,
and
so
so
on
and
so
on.
That's
how
software
was
built
originally
and
if
you're
old
enough
to
remember
like
me,
software
used
to
literally
be
shipped
out
to
people
on
cds
or
on
floppy
disks.
It
wasn't
something
you
could
just
download
or
literally
have
access
to
on
a
computer
in
your
pocket.
B
So
this
is
how
it
used
to
work.
There
was
the
concept,
the
initiation
of
that
concept
and
the
sort
of
coming
together
and
deciding
who
the
users
were
going
to
be.
Who
was
it
for
an
analysis
of
how
it
was
going
to
work,
actually
designing
it
construction
of
it
testing
of
it
deployment,
and
then
you
just
send
it
out
and
you're
like
all
right?
B
The
software
is
out
there.
Now,
let's
see
what
happens.
This
is
the
waterfall
method,
and
this
is
how
software
is
built
for
a
while
until
agile
came
along,
agile,
said
software
is
not
a
car,
it's
not
a
a
can
of
beans.
It's
not
there's
so
much
that
the
production,
the
the
oh.
I
totally
forgot
the
the
word
for
it.
The
assembly
line,
an
assembly
line
does
a
lot
of
things
in
our
world.
All
our
electronics
are
made
by
it.
You
know
beds
cars
planes
everything's
on
the
assembly
line.
People
started
looking
at
software
going.
B
B
If
we
sort
of
connect
these
groups
and
so
taking
the
first
few
groups
and
saying
not
that
they're,
a
single
team
but
opening
up
communication
between
those
teams
and
then
designing
construction,
opening
up
communication,
so
they're
forced
to
work
together,
more
and
agile
becomes
the
way
that
software
is
made.
This
goes
on
for
a
while,
and
then
I
want
to
say
it's
around
2007-2006.
B
I
actually
read
an
article,
an
academic
article
from
2007,
and
it
said
we
need
an
assembly
line
for
software
and
when
I
read
it,
I
was
like
that's
describing
devops
so
within
agile.
What
we
end
up
seeing
happen
is
we
end
up
with
this
wall
between
two
major
sides?
We
have
developers
on
one
side
that
are
writing
the
new
features
for
code
that
are
looking
for
ways
to
deliver
the
software
faster.
B
Here's
another
update,
here's
another
update,
we're
making
things
better
if
you've
ever
opened
a
social
media
app
and
it
suddenly
looks
different
and
it
catches
you
off
guard,
that's
the
developers.
They
created
a
new
way
to
experience,
instagram
and
developers
are
making
changes
every
single
day
on
the
other
side
of
this
wall
were
operators.
This
was
ops,
their
job
was
to
keep
the
service
or
the
app
stable,
to
keep
it
secure
and
to
keep
it
reliable.
B
So,
on
one
side,
you've
got
people
who
are
constantly
trying
to
make
changes
and
trying
to
make
new
features
and
saying
we
added
this
great
new
feature
for
our
users
and
on
the
other
side,
you
have
operators
who
are
going.
What,
if
that's
not
secure?
Have
we
really
tested
this?
What
if
someone
can
access
and
it
becomes
sort
of
not
a
war,
but
operators
and
developers
can
be
kind
of
at
odds
from
time
to
time.
B
Dev
and
ops
were
separate
for
a
while
and
that's
when
devops
comes
along
and
tries
to
connect
the
two.
We
want
to
break
that
wall
down
and
we
want
more
collaboration
in
the
21st
century
that
that
wall
between
the
two,
if
you're,
not
moving
faster
than
your
competitors,
then
you're
being
left
behind.
B
B
B
So
ops
is
now
involved
in
planning
with
dev
dev
is
creating
the
code,
verifying
it
packaging
it
and
then
ops
takes
over
for
release,
but
we
got
rid
of
that
wall
in
the
middle.
It's
constant
collaboration
between
the
two
and
that
makes
for
faster
releases,
one
of
the
central
ways
that
devops
works
and
one
of
the
essential
pieces
of
technology
that
makes
it
even
possible
is
git
and
git
is
the
main
technology.
B
A
B
Of
javascript
and
it
makes
a
bot
tweet
at
mountain
dew,
every
single
day,
yelling
at
them
to
sponsor
me,
complicated
programs,
complicated
apps,
I
zoom,
you
know,
like
google,
slides
all
the
things
I'm
using
right
now
require
tons
of
code
and
it
needs
a
place
to
live
so
the
example.
We
want
to
give
you
about
how
git
helps
and
how
git
allows
you
to
work
collaboratively,
isn't
something
that
you're
probably
familiar
with,
which
is
google
docs.
B
So
the
old
way
of
working
with
software
can
be
compared
to
microsoft
word
and
basically,
one
person
could
edit
the
document
at
the
time
they
would
type
up
whatever
they
needed
in
the
document.
They
would
save
it
and
then
they
would
send
that
file
off
to
somebody
else.
Then
that
person
gets
it
and
they
add
something
to
it
and
then
they
send
it
off
or
they
send
it
back.
It's
a
lot
of
back
and
forth
when
you've
got
a
file
saved
on
a
hard
drive.
B
B
Five
final
final
final
copy
in
all
caps,
so
I
know
that
that's
the
one
to
use
or
renaming
old
copies,
don't
use
me,
but
I
needed
to
keep
it
just
in
case
I
needed
to
go
back
to
an
old
version
later
on.
So
you
end
up
with
multiple
copies.
You
end
up
with
version
conflicts
where
you're
like
do
I
have
do.
I
have
the
most
recent
document.
B
A
B
B
B
There's
no
conflicts
because
you're
never
taking
it
away,
saving
it
and
bringing
it
back
and
there's
it's
conflicting
with
what
someone
else
did
there's
real
time
feedback.
I
could
be
typing
an
article
and
my
manager
could
be
right
there
giving
me
comments
and
helping
me
understand
what
needs
to
be
fixed
and
changed,
or
she
could
just
be
making
the
changes
right
behind
me
for
things
that
I
might
have
missed
and
then,
finally,
it's
concurrent,
it's
all
right
there
same
time
same
people.
B
This
is
how
git
works.
Git
is
a
central
repository
of
your
code
of
your
app
that
you
pull
onto
your
local
computer.
The
git
lives
in
the
cloud
or
on
git
lab
in
a
repository,
pull
it
to
your
computer
change.
Whatever
you
need
to
change
lines
40
through
52,
I
changed
the
way
the
function
was
running
because
it
was
throwing
an
error.
B
You
save
it,
you
push
it
back
in
and
the
repository
reflects
that
change
at
the
same
time,
you're
doing
that
your
colleague
or
your
teammate,
if
you're
in
a
team
project,
has
also
pulled
it
to
their
local
computer
and
they
change
lines
20
through
26,
and
then
they
say.
Oh,
I
needed
to
make
this
a
little
more
efficient,
so
I
changed
the
code
and
they
push
it
back
and
now
those
changes
are
reflected.
B
Git
is
the
heart
of
devops,
because
it
allows
for
collaborative
work
more
quickly
and
more
easily.
All
right,
so
we're
going
to
talk
about
the
history
of
devops.
So
what
happens?
Is
developers
love
automation?
They
love
things
that
can
be
done
automatically
that
can
take
work
off
of
their
plate.
If
something
can
be,
automated
developers
are
going
to
want
to
do
it.
So
what
happens?
Is
a
lot
of
companies
come
up
with
these
great
tools
that
help
you
do
things
more
quickly?
Let's
say
you're
wanting
a
repository.
B
Github
was
the
place
to
do
it.
Let's
say
you
want
to
work
collaboratively
with
other
people,
you're
going
to
be
going
to
jenkins,
let's
say
you're
looking
to
do
some
ci
cd,
some
automation,
real
automation
of
your
code,
jfrog
new,
relic
chef.
These
were
all
companies
that
at
one
time,
were
creating
these
tools,
and
that
was
their
tool.
So
you
would
take
their
tool.
You
would
use
it
in
your
development
process
and
that's
how
it
worked
for
a
long
time.
B
You
just
had
several
different
tools
and
it
was
great
at
first
because
having
these
specific
tools
sped
so
much
up
in
oh
the
chat's
happening.
I
just
wanted
to
make
sure
I
wasn't
missing
anything
in
the
chat.
It
sped
up
production
and
that
was
important
to
people,
so
this
was
working
in
a
while
at
the
very
beginning,
like
I
said,
automation
tools.
B
All
of
this
is
happening
in
the
very
beginning
and
everyone's
kind
of
trying
to
figure
out.
Okay,
we
got
this
devops
methodology,
this
culture.
How
do
we
make
it
work
best
and
companies
start
popping
up,
so
that's
bring
your
own
devops.
It
was
you're
gonna,
have
all
these
different
tools
and
it
can
increase
productivity
and
that's
great,
but
it
ends
up
with
an
uncoordinated
purchasing
and
if
you're
a
company
you
don't
wanna
buy,
you
know
14
different
licenses
for
an
app
so
that
your
team
can
be
more
productive
because
yeah
they're
more
productive.
B
Now,
but
now
you've
got
14
licenses.
And
now
you
need
to
manage
those
14
licenses,
and
now
you
need
to
teach
people
how
to
use
these
14
apps,
so
it
can
be
a
little
redundant.
Maybe
you've
got
a
tool
that
does
two
things,
but
you
don't
like
the
way
it
does.
That
second
thing,
and
so
you've
got
another
tool.
B
That
does
that
a
little
better,
but
some
people
on
the
train
team
prefer
the
first
tool,
so
it
ends
up
with
a
lot
of
each
team,
is
selecting
their
own
tools
and
that
can
lead
to
conflicts
between
teams.
Well,
we
were
using
jfrog,
oh
well,
we
were
using
travis
ci.
Well,
that's
a
conflict
and
that
really
shouldn't
be
happening
and
that
no
alignment
among
teams
can
bring
down
productivity.
So
there
was
an
increase,
but
it's
not
as
high
as
it
could
be.
B
B
It
last
year
we're
all
going
to
use
this,
and
everyone
agrees.
Okay,
this
one
does
a
really
good
job,
we're
going
to
use
that
one.
It
reduces
the
license
cost.
It
reduces
the
training
overhead,
because
now
all
the
teams
are
working
on
the
same
same
tools,
but
what's
hard
is
now
you've
got
not
really
a
connection
between
these
two
tools.
Maybe
atlassian
doesn't
play
as
nice
with
jfrog,
as
you
like.
B
Maybe
get
lab
doesn't
play
as
nice
with
this
one
as
you'd,
like
maybe
there's
not
really
a
connection,
and
you
kind
of
have
to
manually
make
these
connections
and
that's
really
hard.
So
that's
adding
time
you
can
lead
to
data
loss
from
one
app
to
another
to
another,
it's
just
not
as
ideal,
but
it's
still
better
than
it
was
before
best
in
class
after
best
in
class.
We
end
up
moving
on
to
diy.
B
B
We
should
work
on
making
an
integration
with
them
to
make
it
easier
for
our
customers
to
use
it.
So
now,
you've
got
things
like,
for
instance,
heroku
heroku
can
automatically
deploy
from
your
github
account.
You've
got
atlassian
automatically
connecting
to
jfrog.
You've
got
these
different
tools
starting
to
recognize
each
other,
and
they
start
building
the
connection
for
you
or
a
devops
engineer
makes
that
connection
and
forces
it
with
some
code
and
some
scripts.
B
It's
still
not
perfect,
because
you've
still
got
separate
tools
that
you're
having
to
draw
these
bridges
between
them,
and
that
can
be
a
fragile
and
tenuous
connection.
If
you
built
it
yourself,
devops
engineers
are
really
smart
people.
They
work
really
hard
on
making
these
connections
work
and
they're
really
good
at
building
awesome
infrastructure
to
host
all
these
tools
at
the
same
time.
B
But
what
happens
when
your
devops
engineer
leaves
for
another
job
and
you're
left
with
something
you're
like
oh
well?
They
always
knew
what
to
do
here.
So
now
what
happens?
So
these
connections
are
great
and
they
take
a
lot
of
like
written
determination
and
and
hard
work,
but
it
can
be
tenuous
and
it
can
be
fragile
and
security
and
testing
usually
comes
pretty
late
in
this
process
too.
So
it
was
again
good,
but
it's
not
the
best
that
it
can
be
so
at
gitlab.
B
One
app
one
website
or
one
self-hosted
place
where
your
team
goes
to
do
everything
to
plan
it
to
code
it
to
test
it
to
defend
it
against
outside
intrusion,
security
everything's
in
one
place-
and
this
is
what
we
call
the
devops
platform.
This
is
the
new
thing.
It's
faster
you've
got
one
place
to
go,
there's
fewer
errors.
You
don't
have
to
worry
about
integrating
with
a
whole
nother
tool,
because
the
tools
right
there
in
the
same
window
in
the
same
tab,
whatever
you
need,
is
right
there.
B
So
this
is
a
sort
of
example
of
how
working
with
the
team
will
look
when
you're
talking
about
devops
and
when
you're
using
source
control
with
git.
So
git
works
on
an
idea
of
branches.
The
main
branch
is
the
branch
of
code
that
ends
up
getting
deployed.
So
if
you're
looking
at
say
a
code
base
on
git
lab,
when
you
find
the
branch
called
main
that's
the
code,
that's
usually
live
somewhere.
B
When
you
want
to
make
a
change
to
the
code,
if
you
change
it
in
main,
it
changes
live
it
changes
in
production
and
that's
how
you
end
up
with
you
know:
production
going
down
and
that's
how
you
end
up
with
broken
databases
and
problems
like
that.
So
in
order
to
avoid
that
you
don't
change
the
main
branch
until
you're
sure
it's
ready.
So
what
you
do
is
you
create
an
issue
right
here
on
the
main
branch
and
in
the
issue
you
discuss
what
it
is
that
you
want
to
change.
B
B
You
create
what
we
call
a
merge
request
if
you're
familiar
with
github
they're
called
pull
requests
over
there.
We
call
it
a
merge
request
and
you
say
you
make
this
merge
question
like
hey.
What
we're
going
to
do
is
we're
going
to
add
this
functionality
and
inside
that
merge
request.
You've
now
created
a
whole
new
branch.
B
That
branch
is
named
whatever
you
want.
Like.
I
said
this.
One
is
main
in
some
older
systems.
It's
called
master.
Now
it's
called
name,
you
create
this
merge
request.
You
got
a
totally
different
branch
and
that's
where
you
start
changing
the
code.
You
work
in
this
other
branch
and
you
make
changes
to
the
code
you're
like
you
know
what
we
noticed.
There's
a
function
running
here
that
doesn't
even
get
used
anymore.
It's
eating
up
some
cycles
in
our
cpu
and
we
should
get
rid
of
it.
So
you
delete
it.
B
B
I
want
to
see
how
it's
going
to
look
to
the
future
user
without
having
to
push
it
to
production
after
that
more
discussion,
more
collaboration,
more
time
spent
making
sure
that
this
is
the
way
that
you
want
it
to
look.
Is
this
the
the
best
change
that
we
can
make?
Is
this
the
right
way
to
move
it?
Is
this
a
good
iteration,
a
good
small
change
that
makes
it
better?
B
B
Maine
now
has
that
here
the
cd
pipeline
runs
which
stands
for
continuous
deployment
or
continuous
development,
and
that
now
runs
automatically
deploys
it
and
your
app
is
live
and
it
never
had
any
downtime.
It
just
instantaneously
changes
right
here,
because
a
cd
and
now
you
use
the
rest
of
the
gitlab
tools
to
monitor
your
app
how's
everything
looking
are
we
having
any
problems?
Are
we
noticing
any
secret
detection
that
has
kind
of
led
to
some
problems?
This
part
right
here,
modded
in
your
app
and
this
part
right
here-
writing
code.
B
B
B
And
this
is
an
example
of
what
that
process.
I
just
described
looks
like
between
me
and
christina
hi.
My
name
is
pj
metz,
I'm
the
education
evangelist
at
gitlab
on
the
education
team,
and
I'm
here
to
talk
to
you
about
how
you
can
use
git
lab
in
order
to
facilitate
some
cooperative
work
with
maybe
some
teammates
of
yours,
if
you're
at
work
or
some
fellow
students,
if
you're
working
on
a
group
project.
So
what
we're
looking
at
right
now
is
my
profile
page.
B
That's
got
my
activity
and
all
the
stuff
that
I've
been
doing
on
git
live.
You
can
see
how
many
contributions
I've
been
making
on
different
days,
but
what
I
need
to
do
is
I
need
to
work
on
my
twitter
bots.
I
have
a
bunch
of
twitter
bots
in
a
project
called
divas
live
and
in
here
what
I
want
to
do
is,
I
need
to
add
a
new
variable
in
here.
So
that
way
we
can
see
it
printed
to
the
console.
B
I
like
I
like
having
stuff
show
up
in
the
console,
so
I
need
to
do
that,
but
I
want
to
get
my
teammates
involved.
So
what
I'm
going
to
do
is
I'm
going
to
create
an
issue
and
I'm
going
to
expand
this
over
here,
I'm
going
to
head
to
issues
and
I'm
going
to
make
a
new
one
and
I'm
going
to
call
this
add
console
log
for
a
variable,
because
I
want
to
see
that
that
variable
is
showing
up
correctly.
B
I'm
going
to
assign
this
to
me
for
right
now,
but
I'm
also
going
to
assign
it
to
my
manager
so
that
my
manager
knows
what
I'm
doing,
I'm
not
worried
about
milestone
labels
or
weights,
but
I'm
going
to
go
ahead
and
create
this
issue
here.
So
now.
This
issue
is
here.
This
is
a
change
that
we
want
to
make
to
some
code
and
everything
starts
as
an
issue.
I've
got
my
boss
and
myself
tagged
on
it
and
if
I
want
to
make
some
changes,
I
need
a
merge
request.
B
B
So
I
have
several
different
tweets
in
here,
but
I
turn
it
into
a
variable
here
called
post
status,
but
I
want
to
see
what
it's
going
to
be
in
the
log
before
it
just
becomes
a
tweet,
so
I
need
console.log
for
that,
so
console.log
host
status
and
that's
there
it's
great.
So
what
we're
going
to
do
is
I
need
to
say
I
want
this
change
to
be
made
the
merge
request
and
I
need
my
boss
to
check
it
because
I
don't
just
want
to
push
anything
to
main.
B
So
I'm
going
to
click
commit
I'm
committing
it
to
the
branch
that
I'm
on
right
now,
which
was
automatically
created
from
the
issue,
adding
a
console
log
here
and
I'm
going
to
commit
that
all
changes
are
committed.
We
can
go
back
to
our
merge
request
over
here
and
we
can
see
here's
the
merge
request
and
we
can
see
the
changes
right
here
so
now.
I'm
gonna
hand
this
off
to
christina
huppy
who's
gonna
tell
us
whether
we
can
merge
this
or
not.
D
Hey
everyone,
I'm
christina
huppy,
a
manager
of
education
programs
and
pj's
manager.
It
looks
like
pj
just
sent
over
a
merge
request
for
me
to
review.
I
can
see
it
here.
My
merge
request
list
and
it
looks
like
he
wants
to
resolve
an
ad
console
log
for
a
variable.
So
let's
go
ahead
and
click
on
that
merge
request
and
we
can
review
the
changes.
We
can
click
on
this
change,
tab
and
scroll
down
and
see
what
piece
of
code
he
changed.
D
D
D
B
B
That
means
there's
something
in
my
to-do
list
and
it
looks
like
I
gotta
sign
that
merge
request
that
I
made
to
my
manager
back,
so
I'm
gonna
go
ahead
and
head
to
that
merge
request
and
let's
see
I
was
hoping
she
was
just
going
to
merge
it,
but
must
have
been
something
it
looks
like
she
made
a
suggested
change,
okay,
so
in
line
40
I
did
not
put
an
end
parenthesis
there
and
she
has
gone
ahead
and
made
a
change
there.
So
it's
gotta
end
parentheses.
Now
she
gave
me
the
ping-pong
back
to
me.
B
I
can
apply
this
suggestion
just
right
there,
because
I
know
she's
right.
I'm
gonna
apply
that
all
the
threads
have
been
resolved.
This
merge
request
is
ready.
I'm
gonna
mark
it
as
ready,
but
I'm
gonna
send
it
back
to
my
boss
so
that
my
boss
makes
the
final
decision
to
merge
it
or
not.
So
I'm
going
to
unassign
myself,
I'm
going
to
assign
christina
and
now
she
will
know
that
it's
her
turn
to
get
this
thing
merged.
D
It
looks
like
pj
has
made
a
change
to
the
merge
request
and
assigned
it
back
to
me,
so
I'm
going
to
go
ahead
and
click
on
it.
I
can
scroll
down
and
see
that
everything
in
this
thread
has
been
resolved
and
the
suggestion
has
been
applied.
So
I
am
going
to
go
ahead
and
merge
this,
so
I'm
going
to
go
ahead
and
click
work.
B
All
right,
I'm
pretty
sure
my
merge
request
has
been
taken
care
of
so
I'm
going
to
head
out
over
head
over
to
divas
live
and
I'm
going
to
head
into
my
ci
cd,
and
I
should
see
it
running
because
it
got
pushed
to
maine
there.
It
is
triggered
by
christina
hoopy.
So
I
can
click
into
here
and
I
can
actually
take
a
look
inside
of
the
inside
of
the
pipeline
and
actually
see
what's
going
on
in
here
and
watch
it
get
completed.
B
So
you
can
see
it's
running
with
a
get
live
runner
on
a
shared
runner,
it's
using
docker
with
ruby
latest.
These
are
all
instructions
that
I
have
in
my
ci
cd.
I've
got
build,
succeeded
and
it's
going
to
say
it's
live
job
succeeded.
We
are
good
to
go.
My
bots
change
is
live
now
on
the
internet
and
that's
a
quick
intro
on
how
you
can
use
git
lab
to
collaborate
with
people.
I'm
gonna
bring
christina
back
in
for
a
second
and
that's
the
whole
show.
B
Hi,
my
name
is
pj
matt,
perfect,
so
yeah.
That
was
just
an
example
of
how
you
would
use
git
lab
in
order
to
collaborate
with
someone
else
because,
like
I
said
at
the
very
beginning,
if
you're
building
code
on
your
own,
if
you're
developing
it
on
your
own
and
you're,
the
only
person
there's
no
need
to
really
create
an
issue
except
to
keep
track
of
things.
B
You
don't
have
to
tag
other
people,
you
just
kind
of
do
it
all
yourself,
but
when
we're
talking
about
building
software,
we're
talking
teams
of
15
and
those
teams
are
part
of
like
30
teams
and
those
30
teams
are
part
of
a
company
of
1700
people.
So
the
idea
of
collaboration
and
making
collaboration
as
smooth
and
easy
as
possible
is
part
of
why
you
would
go
through
something
like
we
just
did.
B
That
was
obviously,
and
I
want
to
make
sure
this
is
very
clear.
That
was
a
very
simple
missing
parenthesis.
A
lot
of
times.
It's
hey.
This
test
came
back
with
some
interesting
results,
we're
wondering
where
the
issue
is,
and
you
work
on
what's
happening.
So
sometimes
the
solution
is
not
so
obvious
that
you
end
up
with
a
lot
of
back
and
forth,
but
the
collaboration
is
the
aspect
we
were
trying
to
show
off
there.
B
So
this
cycle
is
similar
to
the
previous
cycle
that
we
showed
you
before.
It's
all
the
same
stages
here,
but
now
we're
talking
about
how
over
here
when
you're,
creating
and
verifying
and
packaging
up
your
code,
you
can
do
so
securely
and
do
what's
called
shift
left.
Oftentimes
security
was
left
to
operations
and
shift
left
is
an
idea
of
considering
security
earlier
and
especially
in
verify.
B
The
defense
stage
anymore,
it's
now
called
the
oh.
I
know
this
one
I
can't
remember,
but
we
changed
it
from
defend,
but
what
happens
here
is
git
lab
lets
you
manage
all
of
this
in
one
place,
you
don't
have
to
worry
about.
Okay,
we
created
in
this
app
and
now
we're
going
to
take
everything
and
move
it
to
another
app
and
then
we're
going
to
save
it
in
this
app
we're
going
to
move
it
to
another
app
or
you've
got
your
automation
setup
where
it
automatically
connects
from
one
app
to
another.
C
B
System
that
you
don't
quite
know
how
to
use
as
well
as
they
did
so
if
you've
got
one
place
to
do
it,
it
leads
to
a
nice
smooth
cycle
where
developers
on
this
side
and
operations
on
this
side
can
work
together,
and
I
do
want
to
clarify
something
about
devops.
If
you
type
what
is
devops
into
google
you're
going
to
find
80
different
people
with
80
different
definitions
of
it,
because
it
is
a
it
is
a
concept
as
opposed
to
a
single
kind
of
entity.
B
First
and
foremost,
one
of
the
things
I've
learned
is
that
devops
is
about.
Culture
is
about
the
the
people
who
are
working
on
it
right,
so
making
sure
you've
got
the
right
culture
that
devops
can
flourish
in
right,
making
sure
you've
got
the
process
and
that
the
process
is
well
documented.
So
people
can
follow
the
right
process
and
the
last
thing
is
actually
tools.
B
First
and
foremost,
it's
a
culture
change.
Next,
it's
a
process,
change
and
then
finally,
it's
about
the
tools
you're
using
right,
so
anything
that
can
make
the
culture
better
is
something
that's
better.
Anything
that
makes
the
process
easier
is
better.
The
actual
tool
you
use
doesn't
matter,
except
that
it
works
for
you
and
your
team
if
it
doesn't
work
for
your
team,
that's
what
you
should
reconsider.
B
So
when
we
talk
about
devops,
it's
protect,
it's
called
protect.
Guys
when
I
was
like
defend,
is
something
different.
It's
protect.
I
remember
now,
don't
worry,
so
this
is
everything
you
need
for
devops.
These
are
the
stages
of
devops
here
and
underneath
it
are
the
ways
that
gitlab
has
specific
functions
inside
of
our
software
as
a
service
or
inside
of
self-hosted.
B
B
Plan
is
going
to
be
tracking
the
time
spent
on
those
issues
having
boards
of
issues
that
you
can
easily
look
at
and
see.
Labels
on
them
planning
is
when
you're
collaborating
with
someone
else
and
just
talking
about
what
it
is
you're
going
to
do
and
how
you're
going
to
accomplish
it
create
is
likely
the
most
popular
stages
where
you
get
the
source
code
management.
This
is
where
you're
using
git,
where
you
have
your
code
reviews,
you
have
a
static
site
editor.
B
B
This
is
the
review
apps,
where
you
can
see
what
the
app
looks
like
before
it's
actually
deployed
packaging
is
for
containers
like
docker
your
package
registry
using
the
helm
chart
registry.
If
you're
doing
kubernetes,
we've
got
kubernetes
stuff
now
that
it's
bring
your
own
kubernetes
to
gitlab,
so
we're
integrating
with
that
secure.
B
Like
we
said,
we
talk
about
security
and
it's
the
earlier
in
the
cycle
that
you
consider
security,
usually
the
better
off
you
are
you
don't
want
to
you,
don't
want
to
have
this
big,
beautiful
house
you've
built
and
when
you're
ready
to
move
in
that's
when
you
decide
what
kind
of
lock
you're
going
to
use.
That's
when
you
decide
what
kind
of
security
system
you're
going
to
get,
you
need
to
consider
that,
while
it's
being
built
all
right,
we've
got
this
window
here,
but
is
this
too
close
to
the
ground?
B
Should
we
maybe
push
it
up
a
little
bit
while
you're
designing?
You
should
be
considering
security,
so
we've
got
it.
You
know
it's
in
the
middle
here,
but
like
more
and
more.
This
is
what
we
meant
by
shift
left
shift
left.
Think
of
security.
Earlier
things
like
secret
detection,
hey
did
you
accidentally
leave
the
keys
to
your
api
in
the
code,
and
now
it's
visible
to
everybody
things
like
code
quality.
Is
it
written
as
efficiently
as
it
could
be
dast
sas,
fuzz
testing?
All
of
this
is
securing
your
app.
B
Releasing
is
the
other
part
of
ci
cd,
continuous
delivery.
Continuous
deployment
things
like
feature
flags,
turning
on
and
off
features
to
see
how
it
works
with
your
app,
like
we
said
here
in
configure
over
here,
is
package
over
here's
configure.
We've
got
kubernetes
management
things
like
chat,
ops
as
code
all
these
buzzwords.
B
That
mean
a
lot
to
a
lot
of
people,
but
it
means
a
little
less
to
me
because
I'm
not
quite
there
yet,
but
it's
important
for
people
who
are
really
looking
to
efficiently
make
code
like
make
it
the
best
that
it
can
be
configure
it
so
that
it's
it's
humming
like
a
beautiful
machine
and
then
finally
monitoring.
What
are
your
metrics?
What
is
your
incident
management
when
your
app
goes
down?
What
do
you
do?
D
B
Face
it,
your
app's
got
a
99.8
uptime.
What
happens
in
that
point
two
percent,
what
happens
when
you're
at
facebook
and
it's
down
for
a
whole
day
and
then
finally
protect
used
to
be
defend.
This
is
actually
keeping
out
people
that
are
not
supposed
to
be
in
keeping
out
hackers
keeping
out
bad
actors
all
of
these
again,
these
are
the
stages
of
devops,
and
all
of
these
things
down
here
are
things
that
get
lab
offers.
B
So
again,
as
a
company,
what
are
we
first
commit?
Was
october
2011.,
like
I
said,
10
years
old
in
october,
2021
we
became
incorporated
in
2014,
and
the
thing
I'm
most
proud
of
for
my
company
is
our
values.
We
don't
talk
about
culture
at
gitlab.
We
talk
about
values
and
those
are
collaboration,
results,
efficiency,
diversity,
inclusion,
belonging
and
transparency.
B
These
five
values
are
the
way
that
we
drive
everything
we
do
at
our
company.
We
want
to
collaborate
with
each
other.
We
are
results,
oriented
and
focused.
We
are
focused
on
doing
things
efficiently
and
we
pride
ourselves
on
diversity,
inclusion
and
a
feeling
of
belonging
for
our
team
members
and
for
the
broader
community
and
then
finally,
transparency.
We
try
and
make
sure
that
you
can
know
as
much
about
it
as
possible.
So
the
transparency
end.
B
We
got
30
million
plus
registered
users,
we
have
an
education
program,
an
open
source
program,
a
startup
and
an
enterprise
program,
and,
like
I
said
before,
we
are
the
devops
platform
and
no
don't
scroll
yet,
and
we
are
open
source
core.
So,
like
an
open
source
company,
you
can
contribute
to
git
lab
you
can
get
into
our
code
and
you
can
help
us
make
gitlab
more
efficient
and
the
reason
we
do.
B
B
There
are
tons
of
organizations
that
are
using
git
lab
the
devops
platform
places
like
goldman
sachs
wish
t-mobile
ubs
where's
my
favorite
ticket
master,
these
major
companies
fanatics
they
are
building
their
their
apps,
their
web
apps,
their
phone
apps
their
infrastructure.
They
are
using
gitlab
to
build
it
and
we've
got
great
relationships
with
these
companies,
and
this
list
is
always
growing.
Of
course,
like
I
said
earlier,
these
values
are
very
important
to
us.
Working
asynchronously
give
us
a
fully
remote
company
top
to
bottom.
B
My
manager
is
in
one
state,
and
I
am
2
000
miles
away.
Our
director,
our
former
director,
was
in
europe.
I
have
a
couple
team
members
in
europe
as
well.
I
have
coffee
chats
with
people
who
live
in
new
zealand
where
that
little
overlap
of
work
time
for
us,
we
hang
out
and
we
have
some
coffee
and
we
just
talk
about
things.
We
collaborate
asynchronously
on
a
fully
remote
workforce
and
we
use
git
lab
to
build
gitlab.
B
We
are
issue
first
handbook.
First,
we
are
always
using
gitlab
the
way
we
think
it
should
be
used
like
we
said,
results
oriented
it's
about
the
outcomes,
not
how
many
hours
you
put
in
efficiency.
Our
big
thing
is
a
boring
solution.
Wins
it's
not
about
being
fancy,
it's
not
about
being
flashy,
it's
not
about
being
a
10x
developer.
What's
the
boring
solution
that
fixes
it
that
makes
it
work
better
immediately!
That's
what
we
focus
on
diversity,
like
we
said
remote.
Only
we
trend
towards
global
diversity.
B
We
have
team
members
in
countries
all
over
the
world.
Like
I
said
one
of
my
teammates
is
in
germany.
Another
teammate
of
mine
is
in
california
another
one.
I
hang
out
with
people
who
live
in
latin
america,
south
america,
the
caribbean,
the
netherlands.
I'm
constantly
talking
to
these
people
from
around
the
world,
but
we
hire
people
who
add
to
our
culture,
not
who
fit
our
culture.
B
We
believe
in
iterations
the
minimum
viable
change.
That's
the
I
in
credit.
I
missed
that
earlier,
a
minimum
viable
change.
What's
the
smallest
thing,
we
can
change.
That
makes
it
better
and
if
you
constantly
make
little
changes
that
make
it
better
leads
to
a
big
big,
big
change
in
the
end,
rather
than
focusing
on,
I
got
to
make
this
big
change
right
now.
B
What's
the
smallest
change
you
can
make,
that
makes
it
better
when
you
focus
on
that,
you
can
iterate
more
quickly
and
constantly
get
better
and
better
and
then
finally,
like
we
said,
transparency
public
by
default,
we
don't
make
it
private.
Unless
we
I
mean,
usually
it's
if
we're
legally
required
to
make
it
private
our
strategy,
our
roadmap,
our
goals,
the
handbook
I
highly
suggest.
Looking
through
our
handbook,
it's
fantastic
like
we
said,
that's
the
ui
that
you
saw
in
the
video
earlier.
This
is
in
dark
mode,
so
you've
got
dark
mode.
B
B
B
We've
got
meetups
from
time
to
time.
We
have
something
called
student,
spotlights
if
you've
built
something
on
gitlab
and
you
want
to
show
it
off
apply
to
the
student
spotlights
I'll
check
it
out.
Send
me
a
video
showing
me
what
you
did.
I
might
host
you
on
twitch
and
we
can
talk
about
what
you
built
on
gitlab.
B
We've
got
a
forum
where
you
can
chat
with
other
people
who
are
using
it.
A
forum
is
a
great
place
to
get
started
and
see
what
other
people
tend
to
be
talking
about
too,
and
you
can
find
interesting
issues
to
work
on
in
the
forum
as
well
and
just
sharing
your
ideas
like
open
an
issue
say
a
feature
that
you
would
love
to
see
in
gitlab.
You
know
get
involved.
B
This
is
us,
I'm
pj,
matt's
education,
evangelist.
That's
me
with
the
biggest
smile
that
I
inherited
from
my
dad.
That's
what
he
does
in
every
picture.
This
is
dr
christina
hubert,
she's,
the
manager
of
education
programs.
We
are
the
education
team,
it's
the
two
of
us,
we're
very,
very
excited
that
we
were
able
to
be
here.
Thank
you,
spencer.
Thank
you,
kim
for
coming
through.
If
you're
interested
in
being
a
part
of
the
gitlab
for
education
program,
tell
cityu
that
they
can
apply
for
the
top
tier
join
our
education
program.
B
It
already
has
a
million
plus
users,
a
thousand
plus
institutions.
80
plus
countries
are
already
using
gitlab
for
education,
it's
totally
free.
If
it's
used
for
teaching-
and
we
want
you-
we
want
you
to
have
it-
we're
not
tricky
we're
not
like
you
can
have
it.
If
you
do
this
thing
for
us,
no
just
we
want
you
to
have
it.
Are
you
using
it
for
a
classroom?
Take
the
license,
we
want
it
for
you.
B
Finally,
these
are
some
results
from
our
our
survey
response.
I
wanted
to
get
to
there's
another
slide
that
I
really
wanted
to
show
off.
I'm
going
to
come
back
to
this
one,
so
in
the
survey
what
we
saw,
we
did
a
survey
in
2020
about
people
who
were
using
git
lab
or
people
who
just
wanted
to
know
about
devops
in
education
and
what
we
saw
was
there
was
a
multi-disciplinary
adoption.
It's
not
just
computer
science,
people
that
are
using
git
lab
it
is.
It
is
architecture
it
is.
B
You
can
use
it
in
an
english
class.
I
absolutely
can
make
that
happen.
We're
seeing
devops
culture
come
into
the
classroom
as
well,
and
we're
seeing
easier,
cross-campus
collaboration
between
different
schools
between
different
organizations
on
campus,
then.
Finally,
the
thing
the
of
the
stages,
the
things
that
tend
to
get
used
the
most
and
this
right
here
create
is
the
biggest
thing
that's
being
used.
B
That's
where
you're
writing
code
and
creating
code
that
gets
used
by
other
people,
that's
the
one
that
gets
used
the
most
and
if
that's
all,
you
want
to
use
perfect
we're
going
to
hope
that
you
can
learn
to
use
these
other
things
as
well,
and
we
want
to
help
with
that
last
thing.
These
are
some
great
studies
that
dublin
city,
university,
harriet,
watt,
university
and
university
of
surrey,
they've
used
git
lab
and
there's
some
fantastic
stuff
that
these
schools
have
done.
B
Harriet
watt
does
not
grade
code
anymore;
they
just
run
ci
pipelines
on
code
to
make
sure
it
works
and
that's
how
it
gets
graded
now.
So,
if
you
want
to
read
more
about
that
check
out
the
slideshare
and
click
these
links
and
that's
it
54
minutes,
that's
the
longest
lecture
I've
given
in
like
a
year
and
a
half.
A
Oh,
that's
pretty
amazing.
Thank
you,
pj
for
sharing
this
like
whole,
like
road
map,
the
history,
the
about
the
devops
like
from
scratch.
I
definitely
been
through
all
the
process
so
when
you
say
like
the
step
like
how
you
guys
feel
the
this
kind
of
education,
the
whole
platform
I
was
like,
I
keep
knocking
my
head
like.
Oh,
yes,
this
is
exactly
what
we
want.
A
It's
like
right
now,
it's
too
many
things
like
going
around
like
we
don't
know
like
how
can
we
deal
with
all
the
capacity
and
like
we
just
the
only
thing
that
people
usually
do
is
like
keep
hiring
the
software
engineer
and
then
keep
hiring
a
lot
of
people
to
get
all
the
stuff
together
and
then
in
the
end,
it's
just
like.
Oh
wait,
a
second
just
we.
Actually
we
don't
need
this
capacity
yeah.
We
just
need
the
simplified
solution
for
all
these
questions.
C
Yeah-
and
I
think
also
I
saw
during
your
presentation-
there's
a
chat
from
neil
and
he
was
mentioning
like.
Oh
what
does
it
feel
so
similar
to
what
you
are
doing
on
github?
Is
it
devops
and
that's
definitely
how
I
first
felt
when
I
realized
that
I
was
doing
that
off
stuff
all
along,
but
you
never
realized
that
you're
actually
doing
it.
So
I
think
that
was
the
cool
part.
The
aha
moment.
B
Yeah,
the
biggest
part
of
devops
is
since
it
is
a
culture
change,
so
much
of
it
is
already
being
done
like
agile's,
not
bad.
It
was
really
important,
it's
really
useful
and
it
changed
the
way
that
we
approach
software.
A
lot
of
agile
is
in
devops,
it's
just
taking
it
on
that
next
step,
up,
you're
already
doing
devops
and
you
don't
even
know
it
most
of
the
time.
True.
C
B
I
mean
like
I
prefer,
because
I
work
for
them,
but
honestly
I
I
like
it
because,
like
it's,
it's
one
place
and
that's
what
works
best
for
me.
I
know
that,
like,
for
instance,
github
is
kind
of
the
de
facto
place
to
go
for
code
repositories
for
especially
for
individuals,
and
that's
like
when
I
first
learned
get
here's
here's
a
great
story.
When
I
first
learned
git,
I
thought
github
was
git
and
someone
was
talking
to
me
and
they're
like
oh,
so
like
do
you
use
git,
I
was
like
oh
yeah.
B
B
It
also
has
a
little
bit
of
creation
a
little
bit
of
management
in
there.
Where
you
can
create
issues
you
can
collaborate.
Obviously,
but
git
itself
is
an
independent,
open
tool
that
we
use
at
gitlab.
We
do
what
github
does,
but
it's
also
all
the
other
stuff.
You
would
have
to
integrate.
Github
with
a
couple
of
other
platforms,
a
couple
of
other
apps
in
order
to
achieve
what
git
lab
does
on
its
own
azure
devops
is
a
microsoft
tool
that
has
some
stuff.
But
it's
it's
tied
to
azure.
B
D
A
D
D
D
D
Month
so
so
you
see
how
much
faster,
and
that
means
that
we
don't
wait
until
a
feature
is
perfect
to
release
it.
We're
constantly
moving,
and
so
that's
really
that
that's
the
culture
right.
That's
the
that's!
What
you
do
was
talking
about.
It's
a
culture.
It's
a
process,
it's
tools!
So
it's
happening
in
this
flow
and
you
remove
when
you
remove
the
context,
switching
you're,
removing
these
things
hooking
together.
It's
that
much
faster
and
just
the
echo
pins
statement
in
the
chat.
D
C
There's
no
dumb
question
right,
and
so,
while
waiting
for
others,
if
there's
nobody's
asking,
then
I
have
a
very,
very
curious
question
that
so
I
see
in
a
deaf
process,
there's
a
lot
of
different
pits
and
pieces
right,
and
I
guess
that
it's
pretty
easy
for
to
have
human
errors.
Amongst
you
know
different
pieces
of
the
process.
So
is
this
something
common
and
like
what
is
the
most
common
ones
that
you
guys
normally
encounter,
and
can
you
share
a
little
bit.
D
Yeah
I'll
start
and
then
I'll,
let
you
think
about
for
a
second,
but
I
would
say
that
one
of
the
amazing
things
about
get
lab
is
pj
was
talking
about
shifting
security
left
and
shifting
testing
to
the
left,
and
so
I
don't
know,
did
our
demo
show
the
pipeline
running.
I
think
I
I
think
it
did,
but
it
was
really
fast.
D
So
the
idea
is
that
what
vijay
was
kind
of
getting
at
there
is
that
everything
that
happens
after
after
you
commit
a
code
right.
Normally,
you
would
hand
it
to
security
engineers
and
you
would
hand
it
to
compilers,
and
then
you
would
hand
it
to
the
bundlers
right
the
packaging
and
then
you
would
deploy
it
and
something
could
go
wrong
at
each
one
of
those
stages
and
what
happens
with
ci
with
ci
cd
is
that
every
time
we
make
a
commit
the
pipeline
is
set
up
to
run
those
tests
automatically
so
kim.
D
I
would
say
if
it's
it's,
if
it's
configured
properly
you're
doing
that
every
commit.
So
it's
actually
touching
a
lot
more.
You
know
mistakes
and
things
earlier
in
the
process,
at
least
from
the
software.
I'm
not
I've
written
code,
I've
taught
I
taught
python,
but
so
I'm
not.
I
got
a
full
second
to
do
right,
anyways,
but
so
so
just
but
from
my
understanding
and
what
we
talk
about
is
that
that
those
security
tests,
the
all
the
compiling
tests
I'll
give
you
an
example.
D
If
we
don't
if,
if
pj-
and
I
make
an
edit
to
our
website-
and
we
you-
we
don't
use
a
relative
url,
so
we
go
http
if
the
ccitv
python
fails,
it
says
no,
you
have
to
use
a
relative
and
then
we
have
certain
strong
language
that
we
don't
want
to
use
at
gitlab
to
make
sure
that
we're
an
inclusive
environment
and
if
a
word
for
some
reason
shows
up,
so
you
actually
copy
and
paste
something
that
you
didn't
need
to
and
you
didn't
notice
it
will.
The
pipeline
will
fail.
A
B
Yeah,
it's
there's
always
going
to
be
some
human
errors.
The
biggest
one
that
I've
encountered
is
working
on
my
my
twitter
bots,
because
that's
just
me
I'll
often
in
a
rush
commit
something
to
maine
and
then
the
pipeline
will
run
and
I'll
go.
Look
at
my
logs
on
heroku
and
it'll
be
like
code,
one
failed
and
I'm
like,
and
then
all
of
I
have
about
seven
twitter,
bots
they're,
all
down
until
I
figure
out
why
it
failed.
Now
I
gotta
go
back
and
I'm
like.
Why
did
I
do
this?
B
B
So
a
lot
of
the
human
error
can
come
from
not
not
ascribing
to
the
devops
culture
and
process
as
you
should,
but
I
can't
tell
you
how
many
times
I'm
in
a
rush
and
I'm
like
I
gotta,
get
the
spot
out,
I
gotta
go
and
then
it
fails.
And
now
you
know
my
my
shania
twain
bot
isn't
firing
and
everyone's
mad
at
me.
C
C
A
B
B
A
C
So
when
you
find
those
videos
pj,
if
you
can
send
it
to
me
and
then
I'll
send
it
to
the
rest
of
the
club
and
then
people
can
always
re-watch
it,
and
I
think
let's
take
the
last
question
to
respect
everybody's
time,
because
I
know
we
are
like
15
minutes
over
so
neil
say
I'm
locked
into
gitlab
cicd.
Or
can
I
bring
my
own
yeah
and.
D
B
That
article
is,
if
you,
if
you
don't,
if
you're
unable
to
verify
for
some
reason,
maybe
you
are
dangerously
close
to
low
on
your
bank-
account-
maybe
you're
not
banked.
That's
fine.
Those
are
ways
to
get
around
it.
As
far
as
sunil's
question,
are
you
locked
into
gitlab
ci
cd,
or
can
you
bring
your
own?
I'm
pretty
sure
that
gitlab
can
integrate
with
other
ci
cd
users,
because
we
like
to
play
nice
and
we
want
you
to
be
able
to
use
it.
B
B
D
A
D
A
So
we
will
have
another
event
in
the
march
3rd
march
30
and
we
will
send
out
all
the
detail
detail
about
the
event
to
your
email
or,
if
you
sign
out
through
the
baby,
which
is
the
google
developer
student
club,
and
we
will
also
send
you
through
the
link
there.
So
that's
all
for
today
see
you
next
time.