►
Description
Developers love best practices and have strong opinions about our tools. We’re always improving our processes so we can write the most efficient and maintainable code. Our static code analysis tools are a requirement for development. All of our code is stored in revision control systems and we can’t accept updates that haven’t been unit tested. This is how we write great code. Let’s talk about writing code in a cloud environment. "Serverless" ecosystems can remove the complexity of environments, runtimes, and frameworks. Do our typical development processes change when most of our environment is abstracted away from us? I want to discuss how to maintain best practices in the cloud where there is more management and abstraction. I'll also show some new (and old) tools for development and DevOps to facilitate "serverless" development.
A
So
let's
get
started
so
again.
This
is
me
linda
nichols.
I
work
for
microsoft.
I
am
a
cloud
native
global
black
belt
and
I
like
to
focus
really
in
serverless
and
development
and
really
like
developer
process
is
something
I'm
really
passionate
about
I'm
from
virginia
and
I
live
in
norfolk
virginia.
Where
I
organize
a
couple
developer.
Events:
norfolk.js
is
our
javascript
user
group
and
revolution.
Comp
is
our
very
own
conference
here
in
virginia
beach,
and
I
am
a
co-founder
and
organizer
of
both
of
these.
A
So
the
first
thing
that
you
have
to
start
with
anytime
you're
talking
about
code,
that's
in
the
cloud
or
you
know,
serverless
functions
of
the
service,
no
matter
what
cloud
platform
you're
talking
about.
You
always
have
to
have
this.
What
is
a
serverless
slide?
And
I
like
to
to
acknowledge
when
I
do
this-
that
serverless
is
completely
made
up.
A
That
is
part
of
a
greater
event-driven
architecture,
but
also
serverless
tends
to
be
very
inexpensive,
so
it's
very
cheap,
essentially
because
you're
only
paying
for
what
you
use.
You
don't
have
servers
sitting
out
there
forever
idle,
holding
your
code
that
you
pay
for,
if
you
have
thousands
of
apis
you're
only
paying
when
those
apis
are
actually
executed.
A
In
most
cases,
we
really
want
to
focus
on
development
and
our
code
and
making
our
applications
really.
You
know
be
as
streamlined
and
as
fast
as
possible,
so
really
also
within
serverless
or
just
code.
That's
executed
within
a
cloud
platform
you
have
like
so
many
services
that
are
out
there
at
your
disposal
and
a
lot
of
these
services
really
replace
instances
where
we
might
have
written
a
lot
of
code.
Before
you
know,
javascript
developers
are
kind
of
used
to
using
something
like
happy
or
express
for
an
http
server.
A
You
know
platforms
and
services
instead
of
writing
that
code
and
also
there's
not
a
lot
of
you
know
redundant
code,
it's
just
naturally,
micro
services
or
even
like
nano
services,
because
functions
as
a
service
tend
to
be
so
small
and
it's
a
faster
time
to
production,
because
you're
not
worrying
about
that
infrastructure.
It's
so
easy
to
just
deploy
these
functions.
A
So
we
as
javascript
developers,
we
have
a
lot
of
opinions
and
we
love
process
and
best
practices.
If
you
know
developers
in
general
or
especially
javascript
developers,
we
love
to
discuss,
what's
our
what's
our
favorite
everything
and
how
to
make
everything,
you
know
faster
and
look
better
and
be
easier
to
use.
A
So
we
really
we
like
to
use
our
favorite
editor,
our
favorite
languages.
We
our
favorite
formatting
tools.
We
want
our
code
to
be
a
certain
amount
of
pretty.
We
want
static
code,
analysis
rules
and
formatting.
No
one
will
ever
deny
that
they
don't
want
these
things.
They'll
be
arguments
about
when
to
execute
these
tools
or
which
tool
to
use,
but
almost
never
is
anyone
saying
yeah.
I
don't
want
to
do
any
of
this.
A
You
know
unless
you're
talking
about
a
situation
where
you
know
you're
just
trying
to
push
code
to
production
quickly
and
in
those
cases,
no
one's
arguing
for
that.
It's
just
situations
that
sometimes
happen,
and
so
these
are
like
some
examples,
maybe
of
all
the
various
things
that
we
love
and
may
discuss-
and
you
know
in
in
this
perfect
world
where
we're
executing
everything
the
way
that
we
want.
You
know
we're
testing
the
code,
we've
written
the
code
with
all
of
our
perfect
tools
that
we
love
we're
testing
the
code.
A
Oh
wait
like
we
tested
the
code,
but
should
we
have
written
them
before?
Do
we
do
tdd?
Maybe
not
that's
another
developer
discussion
and
then
we
commit
the
code.
So
now
we
commit
the
code
to
a
revision
control
system
and
maybe
that
system
is
local.
Maybe
it's
on
a
server.
You
know
somewhere
within
your
building.
Maybe
it's
in
the
cloud
you
know
and
then
now
to
get
that
code
through
development
and
testing
and
production
we've
got
various
branching
strategies.
A
Do
we
squash
commits
we
don't
like?
Do
we
not
squash
them?
Do
we
want
to
you
know?
Do
we
want
to
rebase
our
commit
messages?
Is
it
okay
to
just
you
know,
looks
good
to
me,
here's
my
code
or
do
we
need
to
include
some
sort
of
issue
number
you
know
for
another
system.
You
know
the
the
branch
names
have
to
be
some
sort
of
specific
format.
A
These
are
all
things
that
developers
care
about
and
we
focus
on
and
again
all
kinds
of
choices
here,
there's
nothing
that
anybody
has
to
know
or
shouldn't
use.
It's
all
just
very
opinionated
and
most
products
are
just
you
know
doing
the
job
for
us.
You
know
we're
merging
our
code,
then
into
master
into
production.
A
A
A
A
A
So
now
here's
the
topic
of
our
talk,
because
we're
going
to
talk
about
what
about
code,
that's
written
for
the
cloud.
What
about
serverless
code?
What
about
code
that's
going
to
go
to
a
function
as
a
service,
as
opposed
to
maybe
just
application
code
that
we're
used
to
writing
before,
where
it
gets
packaged
up
and
maybe
containerized
or
something
and
it's
you
know,
maybe
used
on-prem
or
it's
used
in.
You
know
maybe
some
other
cloud
service,
but
it's
not
quite
functions
as
a
service.
A
And
so
this
is
our
dramatic
reenactment.
Here
we've
got
our
programmer
he's
in
the
aws
console.
This
is
aws
lambda,
there's
an
editor.
The
editor
you
know
does
have
like
a
little
bit
of
interesting
features
here.
As
far
as
you
know,
auto
complete
and
you
know
preventing
bugs,
but,
as
you
can
tell,
he
made
some
choices
there.
He
made
some
changes
and
then
he
pushed
to
production,
so
that
seems
a
little
dramatic.
However,
I
have
seen
this
happen
before
that
editor
is
available.
A
So
let's
kind
of
zoom
in
again
and
look
at
this
code
well
already
we're
seeing
that
there's
some
kind
of
bugs
in
this
code.
There's
even
this
editor
here
is
flagging.
Some
errors,
but
our
developer
is
is
essentially
ignoring
those
and
hitting
publish,
because
we
said
it
was
fast
to
get
code
to
production
using
serverless
and
he's
going
to
do
that.
A
Yeah,
but
it
doesn't
make
sense
right
like
why
would
you
push
your
code
to
production
when
we've
talked
about
how
developers
have
all
these
opinions
and,
unfortunately,
no
matter
how
fully
managed
a
serverless
or
cloud
service?
Is
it's
not
fully
managed
enough
to
format
and
debug
and
test
your
messy
code
garbage
in
garbage
out.
A
A
So
I'm
going
to
talk
about
now,
how
all
of
the
development
practices
that
we
love
still
apply
in
this
environment
that,
even
though
it's
scary,
even
though
it's
weird,
even
though
it's
different.
It's
still
the
same,
so
you
don't
have
to
sacrifice
all
that.
You
love
like
maybe
some
of
the
services
that
you
love.
We
will
now
get
rid
of,
because
we
don't
need
that
code
anymore.
A
We
don't
need
those
frameworks,
but
as
far
as
you
know,
running
through
testing
your
code,
making
sure
that
it's
quality,
all
of
those
things
are
super
important
and
I
just
always
want
to
keep
stressing
that
so
here's
my
very
highly
opinionated
tool
set
and-
and
you
know
anyone
could
could
sort
of
say
that
that
any
of
these
tools
they
would
prefer
something
else
and
that's
fine,
but
this
is
what
I'm
going
to
kind
of
demonstrate
today.
So,
first
of
all
eslint,
this
is
very
important
to
me.
I
love
eslint.
A
I
have
eslint
in
my
editor.
I
have
sometimes
I'll
use
eslint
as
a
pre-commit
hook.
I
always
have
it
as
some
sort
of
like
cicd
process,
no
matter
what
tool
I'm
using
to
run
a
linter,
because
I've
seen
code
that
wasn't
linted,
make
it
into
a
code
base,
and
sometimes
it's
just
ugly.
Sometimes
it's
just
inconsistent,
but
lint
can
also
find
errors.
A
Editor
config
is
a
file
that
you
can
put
in
your
code
base
that
will
also
enforce
style
like
tabs
versus
spaces
for
a
code
base.
So
if
you
have
maybe
like
open
source
software,
that
a
lot
of
people
are
contributing
to,
this
is
really
helpful
so
that,
when
you're
looking
at
the
code
later,
the
spacing
it
isn't
really
off.
A
As
let's
say,
a
manager
or
a
team
lead
before
it's
committed,
then
that
makes
things
a
lot
easier
for
testing.
I,
like
mocha.
I've,
also
used
just
there's
lots
of
testing
tools
out
there.
This
is
unit
testing,
I'm
I'm
talking
about
here,
more
so
for
ci,
I
like
github
actions.
I
also
like
azure
devops.
A
I've
used
travis
ci
quite
a
bit
also
in
the
past,
and
today
I'm
going
to
show
github
actions
and
for
an
editor
I
really
like
vs
code
and
off
language,
of
course,
javascript
node.js
and
for
cloud
well.
I
prefer
azure
because
I
work
for
microsoft,
but
I
have
a
little
asterisk
there,
because
today,
I'm
going
to
show
in
my
ci
cd
process
how
I
would
deploy
to
both
azure
and
aws
lambda,
just
as
sort
of
proof
that
this
is
really
kind
of
a
cloud
agnostic
way
of
thinking.
A
A
So
now
I'm
gonna
go
switch
over
to
my
editor
and
I'm
going
to
work
on
this
demo.
Essentially,
it's
an
algorithm,
we'll
put
an
asterisk
there
to
determine
who
is
the
best
ghostbuster.
Perhaps
you've
noticed
that
theme
throughout
this
talk.
There's
my
github
repo
there
on
no
dana
only
zuul
and
we're
gonna
go
through
just
some
a
very
simple
process.
A
A
All
right
so
now,
I'm
in
vs
code,
and
I
want
to
talk
about
just
a
couple
things
now
with
my
workflows.
So
I
have
three
workflows.
One
is
pull
request,
and
then
I
have
two
here
that
are
essentially
my
production
workflows.
My
pull
request,
workflow.
The
idea
for
this
is
that
this
just
runs
my
build
my
unit
tests
and
it
does
some
linting
and
really
this
just
this
runs
on
both
of
my
services.
A
So
I
have
four
services
overall,
two
are
not
implemented,
yet
I've
implemented
spengler
and
venkman,
and
this
runs
those
two
services
and
essentially
what
I
want
to
do
with
this
is
I
want
to
say,
when
a
user
issues,
a
pull
request
on
my
main
branch
that
the
linting
and
the
tests
have
to
pass
before
that
pull
request
can
ever
be
pulled
in
an
admin.
Can
you
know
do
it
if
they
want
to?
But
at
least
that
barrier
is
there
that
these
initial
checks
have
to
have
to
run
then
also
for
each
one
of
these
services.
A
Spangler
is
azure
functions.
It
deploys
to
azure
functions
after
it
also
runs
some
additional
tests
even
and
then
vinkman
deploys
to
aws
lambda
if
you're
not
familiar
with
github
actions.
This
is
sort
of
the
format
here.
This
yaml
form
format
and
then
at
the
top
here
it
will
talk
about
the
trigger.
So
here
it's
whenever
you
push
anything
to
the
main
branch
it
deploys,
and
then
I
have
some
checks
that
people
can't
push
directly
to
maine
without
first
issuing
a
pull
request.
A
A
A
A
A
A
A
So
now
github,
this
is
my
github.
Repo
github
has
seen
that
I've
now
pushed
to
this
branch.
So
now
I'm
gonna
do
a
pull
request
and
I'm
gonna
say
this
message
is
okay.
I
would
normally
leave
some
better
comments.
I
don't
care
at
the
moment.
I
could
set
some
reviewers
on
my
team
and
I'm
not
gonna
worry
about
that
either,
but
and
then
also
some
labels,
but
for
the
sake
of
time,
we're
just
going
to
open
a
pull
request,
and
now
we're
going
to
see
here
that
it's
running
these
two
checks.
A
A
Not
just
past
I
had
two
jobs
and
then
I
can
see
what
happened
inside
of
each
job.
So
if
something
fails,
I
can
go
in
here
and
look
and
see
what
happened
with
my
unit
tests.
I
have
some
very,
very
simple
unit
tests
that
meant
for
passing.
Currently
okay,
so
my
pull
request
is
now
ready
to
to
be
pulled
in,
so
I'm
going
to
pull
it
in
and
it's
automatically
going
to
deploy
my
brand
new
algorithms
for
finding
the
best
ghostbuster.
A
There's
a
couple
settings
that
I
have
here.
I
have
the
settings
so
that
it's
a
actually
setting
on
the
main
branch
that
allows
pull
requests
to
not
be
pulled
into
main
unless
they
pass
those
certain
ci
checks.
That's
an
option
within
this
repo.
Also,
I
automatically
delete
branches
after
I
pull
in
a
pull
request.
So
it's
just
a
little
bit
of
housekeeping
that
I
prefer
so
now
we'll
go
up
to
our
actions
and
they're
both
working
on.
A
All
right,
so
this
one
has
already
kind
of
gone
through
the
environment.
Now
so
right
now,
I'm
sort
of
you
know
banking,
everything
on
node
14,
but
you
can
also
specify
other
versions
of
node
and
you
can
run
through
all
of
them.
There's
there's
similar
capabilities
in
azure,
devops
and
travis,
ci
and
jenkins
and
other
tools.
But
I
like
the
way
the
matrix
works
here,
where
it
just
runs
them
all:
a
separate
jobs
and
here's
my
lambda
deploy
option
and
then
my
post
checkout.
So
it
looks
like
that
still
running
here.
A
Okay-
and
you
can
see
here-
it
gives
me
this
deployment
address
okay.
So
now
we
can
look
at
our
algorithms,
so
you'll
notice,
this
url
matches
this
url,
which
has
determined
that
the
I'm
going
to
refresh,
because
this
is
old,
okay,
great-
it
received
my
change
and
it
still
believes
that
the
best
ghostbuster
is
spankler.
Thank
you,
giphy
for
our
gift.
A
A
A
A
So,
in
conclusion,
just
a
couple
things
that
I
want
to
drive
home
here:
no
ops
as
in
not
worrying
about
infrastructure,
worrying
more
about
code
doesn't
mean
no
devops.
That
doesn't
mean
that
you
don't
think
about
your
development
process.
You
don't
think
about
how
you
move
through
your
stages.
It
doesn't
mean
no
devops,
no
ci
cd
tool.
A
All
those
things
still
apply
all
those
things
you
still
care
about.
Almost
everything
you
cared
about
before
as
far
as
process
still
exists.
Online
editors
are
a
lot
better
than
they
have
been
in
the
past
and
they're
getting
better
and
better,
but
it's
not
the
same
as
a
true
revision
control
system,
whether
that's
github
that
I
prefer
or
svn
or
or
whatever
it's
just
not
the
same
and
even
saving
revisions
of
software
in
the
cloud
isn't
quite
the
same
as
a
robust
revision
control
tool.
A
So
love
your
linter.
I
love
my
linter.
You
should
always
love
your
linter,
even
if
you
have
to
run
it
multiple
times
at
multiple
stages,
it's
really
important.
It
will
save
you
from
making
bugs
there's
a
rule,
for
you
know
not
allowing
variables
that
aren't
being
used.
That
has
saved
me
so
many
times
from
times
where
I've
just
misspelled.
Something
put
your
editor
to
work.
Make
your
editor.
A
Testing
in
prod
is
not
testing
and
we
saw
our
yolo
developer
video,
where
our
developer
wrote
some
code
and
then
pushed
it
to
production,
and
then,
of
course,
that
code
was
going
to
fail
and
then
tested
it.
That's
not
actual
testing.
We
need
unit
tests,
we
need
integration
tests,
we
need
load
tests
and
it's
all
important.
I
didn't
go
through
all
the
testing
options
here.
In
fact,
on
in
this
particular
algorithm,
the
testing
is
light,
but
it's
to
give
you
the
idea.
Abstraction
is
not
ci
cd.
A
You
don't
have
bugs
in
production
and,
like
most
importantly,
don't
abandon
what's
important
if
you
have,
if
you're
doing
something,
if
you're,
if
you're
writing
code,
no
matter
where
you're
writing
it,
if
you
feel
a
little
dirty,
if
you
feel
bad,
if
it's
scary
then
think
about
it,
okay,
why
did
I
lose
that
process?
Why
did
I
think
it
was
okay
to
push
directly
to
production?