►
Description
Hosted by Jacksonville Developers User Group (JaxDug). Here is a link to the event where you will find the streaming information: https://www.meetup.com/jaxdug/events/msctdpyccfbpb/
Azure DevOps Services and all of the automation involved for a complete DevOps environment can be daunting. In this talk, Jeffrey Palermo provides prescriptive guidance for developers to fall into the "pit of success" when creating automated DevOps pipelines for complex .NET apps targeting Azure.
Speaker:
Jeffrey Palermo is the CEO of Clear Measure, a software architecture company that empowers our client's development teams to be self-sufficient: moving fast, delivering quality, and running their systems with confidence. Jeffrey has been recognized as a Microsoft MVP since 2006 and has spoken at national conferences such as Microsoft Ignite, TechEd, VS Live, and DevTeach. He has founded and run several software user groups and is the author of several print books, video books, and many articles. A Christian, graduate of Texas A&M University (BA), and the Jack Welch Management Institute (MBA), an Eagle Scout, and an Iraq war veteran, Jeffrey likes to spend time with his family of five camping and riding dirt bikes.
A
A
A
B
B
My
name
is
jeffrey
palermo
and
I've
been
developing
professionally
since
1997,
and
it's
almost
exclusively
been
on
the
microsoft
platform,
so
I've
gone
really
deep
into
there
and
done
a
small
amount
of
java
on
the
side
and
other
things,
but
really
I've
been
able
to
ride
this
microsoft
train
for
well
over
20
years
and
and
the
tooling
has
been
consistently
outstanding.
So
if
you
I
know
over
the
last
seven
years,
the
number
of
developers
in
our
industry
has
doubled.
B
B
B
It's
really
to
help
people
learn.
So
I
just
wanted
to
throw
that
out.
There.
I've
also
been
a
microsoft
mvp
since
2006
and
I'm
a
chief
architect
at
clearmeasure,
which,
which
is
a
software
architecture,
company
that
helps.net
development
teams
kind
of
be
able
to
be
more
effective
and
do
more
internally
a
little
bit
about
myself.
Just
personally,
I'm
I
kind
of
get
my
my
monthly
exercise
in
the
amateur
dirt
bike
racing
scene
and
not
particularly
good
or
fast,
but
it's
fun.
You
can
see
me
way
back
in
the
pack.
B
So
today's
today's
session
we're
going
to
be
talking
about
the
challenges
of
devops
and
looking
at
the
structure
that
you
need
with
your
pipeline
and
then
and
then
really
how
to
get
started.
So
I
mentioned
before,
if
you
want
to
do
a
screenshot
of
this
of
this
screen,
it
has
my
email
address
on
it.
I
already
mentioned
my
book
be
happy
to
give
you
a
a
free
electronic
copy,
so
jeffrey
at
clear,
dash
measure,
dot
com
and
also
I'm
the
host
of
a
podcast.
B
It's
called
the
azure
devops
podcast,
and
I
mean
if
you,
if
you
just
search
for
azure.
This
is
in
the
top
five,
certainly
certain
for
devops
it's
kind
of
in
the
top
of
the
list
as
well,
and
it's
all
about
shipping
software.
So
that's
that's
what
that
podcast
is
about
all
the
different
types
of
software.
You
can
work
on
on
the
microsoft
platform
and
then
there's
a
new
video
show
that
you
might
be
interested
in
architect,
tips.clearmeasure.com,
it's
just
a
it's
just
a
five
five
minute
short
tips.
B
So
the
seven
key
elements
of
a
devops
environment
are
right
here
on
the
screen.
We
need
to
make
some
design
decisions.
We
need
to
structure
our
source
control
in
a
certain
way,
because
the
source
control
that
is
the
that
is
the
headwaters
of
the
devops
pipeline,
which
the
analogy
is
water,
it's
pipeline.
B
B
Then
we
need
to
do
manual
testing,
which
is
user
experience
testing
I
like
to
call
it
and
then
we
actually
need
to
release
the
production
and
then
observe
the
system,
and
I
call
that
telemetry
observation.
We
need
to
gather
telemetry
and
and
make
sure
the
software
is
doing
what
we
expected
to
do
and
and
that
the
users
of
our
software
are
doing
what
what
we
expected
to
do.
B
If
you
turn
on
turn
on
the
faucet
in
your
house,
there's
certain
things
that
you
need
in
order
to
be
satisfied
with
the
experience
one
when
you
turn
on
the
water
when
you're
ready
for
water,
the
water
needs
to
be
there
and
also
the
water
pressure
needs
to
be
at
the
right
level
and
consistent
if
you
turn
it
on
and
it's
just
drip
drip
drip.
Well,
that's
not
good
and
if
you
turn
it
on
and
it's
blowing
you
away
like
a
fire
hose.
B
Well,
that's
not
good
either
or
if
you
turn
it
on
and
then
some
comes
out
and
it
stops
and
then
some
comes
out
and
it
stops
also.
We
need
quality.
If
we
turn
on
the
faucet
and
the
water
is
brown,
then
that's
not
going
to
work
for
us.
If
we
turn
on
the
water
and
it's
clear
and
then
it's
brown,
it's
clear
and
then
it's
brown
that
doesn't
work
either
and
it's
it's
a
fallacy
to
think
that
we
could
accept
brown,
water
from
say
the
city
or
except
groundwater
from
our
own
water.
B
Well
and
then
in
the
house
right
behind
the
faucet,
where
we
turn
it
on.
We
have
this
uber
mega
filter,
that's
somehow
going
to
remove
all
the
impurities
and
we
just
let
it
be
brown
and
all
the
pipes,
but
but
by
golly
we're
going
to
clean
it
up
right
before
it
comes
out
of
the
faucet
that
doesn't
work
either.
We
know
from
water
pipelines
that
you
have
to
keep
the
water
clean
in
every
part
of
the
pipe
and
every
every
time
you
move
it
forward
to
a
different
location.
B
It
needs
to
be
tested
and
treated
and
filtered
and
cleaned.
So
all
of
those
transfer
over
to
your
your
devops
pipeline
and
again
your
source
control,
is
the
headwaters
so
think
about
those
concepts.
As
you
think
about
your
pipeline
every
time
you
move
it
forward
to
a
next
stage.
You
need
to
have
filters
which
are
essentially
quality
controls.
B
B
So
I
love
this
analogy
now.
This
here
on
the
screen
is
a
a
sample
architecture
of
of
a
devops
environment,
and
this
is
actually
the
top
third
of
a
larger
architecture
poster
that,
by
the
way,
if,
if
any
of
you
would
like
the
high
resolution
version,
send
me
an
email,
be
happy
to
be
happy
to
send
it
over
to
you.
But
this
is
a
this.
B
Is
an
architecture
poster
for,
and
it's
in
the
book
as
well
for
the
structure
of
a
devops
environment
using
the
microsoft
stack,
so
azure
pipelines,
octopus,
deploy,
is
really
popular,
integrated
with
azure
pipelines,
redgate
for
sql
server
and
there's
a
minimum
number
of
things
that
you
need
in
in
your
devops
environment
and
this
kind
of
annotates
every
little
thing.
Now,
I'm
going
to
cover
a
lot
of
this.
B
It
doesn't
do
everything
that
you
need,
and
so,
as
you
get
more
complex,
for
example,
a
lot
of
teams
add
on
octopus,
deploy
for
the
complex
deployment
environments
or,
as
the
databases
grow
beyond
your
free
and
open
source
database,
migrations
tool
like
roundhouse
or
ailey
sql,
then
they'll,
sometimes
graduate
to
the
redgate
products
which
have
fantastic
support
or
layer
on
the
redgate
products
for
test
database,
restore
on
demand
for
manual
test
environment
deployments,
and
things
like
that,
so
azure
devops.
That
is
your
nucleus.
B
That's
that's
your
core,
your
orchestration,
but
you
are
going
to
add
products
to
it.
So
if
you
find
yourself
struggling
where
oh,
why
can't
I
do
this?
Why
can't
I
do
that?
Well,
it
may
be
an
area
of
the
product
that
that
you
know
is
not
just
going
to
be
fully
featured
like
you
need
it
to
be,
but
there's
other
products
that
are
complementary,
all
right.
B
B
Now
we
need
a
process,
so
the
first
four
steps
of
this
process
at
the
top.
Those
are
design
decisions
that
we
need
to
make.
The
second
three
are
specifically
developer
coding
tasks
where
I'm
gonna
type
some
code,
we're
gonna,
do
a
build,
we're
gonna
and
then
we're
going
to
get
it
to
the
point
where
I
have
a
deployable
package
in
the
appropriate
format.
B
That's
ready
to
go
to
an
environment,
and
then
the
bottom
is
a
progression
of
environments,
a
progression
of
deployments
where
every
deploy
remember
every
time
we
move
forward,
we
have
to
have
a
quality
check
to
make
sure
that
we're
not
introducing
a
bug
introducing
a
problem,
and
so
this
is
the
way
that
I
want
you
to
think
about
this
process
as
you
create
it
for
yourself
in
azure
boards.
I
want
you
to
think
about
it
as
a
state
machine
pattern
and
you
have
an
issue
or
a
card
story
card,
a
product
backlog
item.
B
Whatever
you
call
it.
You
have
a
particular
card
issue
in
its
simplest
form
and
you
have
a
series
of
states
now
in
order
to
transition
between
the
states,
you
need
some
activity
to
happen.
You
need
a
person
or
a
role
that
is
responsible
and
capable
of
performing
that
activity
and
that's
essentially
a
state
machine
pattern.
So
conceptual
definition
is
figuring
out
what
the
heck
this
is.
Why
are
we
doing
it?
The
beginning
of
requirements
and
by
the
way,
the
first
four
all
of
those
make
up
the
old
term
requirements?
B
Okay,
so
conceptual
definition?
Why
are
we
doing
this?
What's
the
general
concept
ux
design
is
how
a
human
how's
a
human
going
to
use
this.
How
is
a
human
going
to
experience
this,
and
if
it
has
a
visual
element,
then
obviously
you're
going
to
have
a
wireframe
a
picture
of
a
screen
of
some
sort
or
if
it's
just
a
change
in
behavior
and
moving
data?
Where
there's
no
change
to
the
visual
visual
interface,
then
then
the
only
change
to
the
human
experience
may
be
hey.
B
B
So
there's
at
least
two
test
scenarios
and
oftentimes
there's
multiple
multiple
ways
to
go
through
the
software.
So
that's
what
that
is.
If
you
don't
make
those
design
decisions,
then,
based
on
the
personalities
and
differences
of
which
developer
happens,
to
grab
the
issue,
you're
gonna
you're
gonna
have
different
results,
but
but
either
way
either
way.
These
are
states
and,
of
course,
after
development
you
have
the
functional
validation
at
the
team
level.
B
Then
the
user
experience
validation
at
the
same
product
management
level
and
then
release
validation,
which
is
which
is
again
back
in
the
in
the
release,
management
or
technical
level,
getting
it
out
to
production
and
then
it's
done
and
and
the
person
that's
qualified
to
take
a
state
from
one
to
the
next
is
also
qualified
to
evaluate
whether
it's
ready
or
if
any
dependencies
haven't
been
met
and
then
can
revert
it
back
to
the
previous
state.
That's
the
quality,
control
check
so
map
this
out
to
your
kanban
board
and
and
then
in
azure
boards.
B
You
should
have
a
you
should
have
something
that
looks
kind
of
like
this.
Now
I
understand
that
the
process
templates
in
there
kind
of
give
you
things
like
not
started
in
progress
and
done,
and
really
the
not
started,
is
kind
of
off
to
the
left
of
the
screen
here
and
the
done
is
the
last
column.
So
we
have.
B
We
have
eight
different
descriptions
for
in
progress.
Now
you
could
just
lump
it
all
into
one
and
say:
oh,
it's
still
in
progress,
but
as
your
team
gets
larger
and
probably
larger
than
say,
three
people
somebody's
going
to
ask
hey.
Why
is
this
taking
so
long
and
we
have
seen
time
and
time
again
things
that
are.
B
Everybody
else
thinks
that
they're
in
development
and
actively
being
worked
on,
but
really
we
found
that
there
is
a
technical
design
decision
that
is
being
worked
through
or
hasn't
been
done
or
that
you
know
part
of
the
user.
Experience
is
still
being
discussed,
but
because
we
didn't
have
granularity
on
those
different
decisions
and
those
different
activities
from
the
from
the
outside.
All
we
knew
was
this
amorphous.
Oh
it's
in
progress,
but
we
didn't
actually
know
what
type
of
decision
or
activity
was
holding
it
up.
B
So
it's
important
to
craft
your
own
process
for
your
team
so
that
the
distinct
activities
are
called
out
with
some
sort
of
name
and
again
I
don't
care
what
you
call
these
columns
at
the
top.
Just
make
sure
you
have
every
concept,
every
concept
represented.
So
that's
how
you
lay
out
azure
boards
to
track
your
work
and
the
most
important
I
find
the
most.
The
most
efficient
is
the
statuses
ahead
of
development.
B
We
find
that
once
once
you
have
some
working
code
and
you're
going
through
tests.
A
lot
of
people
have
developed
those
statuses
after
the
column
that
represents
hands-on
keyboard
coding
and
actually
typing,
but
the
design
decisions
ahead
of
development
tend
to
be
left
off
pretty
often
now.
The
next
bit
is
source
control
structure.
So
this
is
the
architecture
of
your
source
control
and
your
team
and
your
your
applications.
B
These
are
the
general
rules
of
thumb
now.
Azure
repos
is
fantastic
for
hosting
source
control
and
and
it's
full
get
and
a
lot
of
people.
A
lot
of
you
are
probably
already
using
it,
but
there
are
some
rules
and
if
you
don't
follow
the
rules,
then
you're
just
gonna
cause
unnecessary
pain.
For
example,
a
lot
of
you
work
on
significant
software
systems
and
you
may
have
been
divided
into
multiple
teams.
B
If
you
try
to
have
two
teams
commit
code
to
the
same
git
repository,
then
you're
going
to
cause
yourself
pain,
and
so
you
want
to
make
sure
that
one
team
owns
a
repository.
Now
I
can
own
multiple
repositories-
that's
just
fine,
but
it
needs
to
really
own
that
repository
and
not
have
commits
being
made
by
other
teams,
and
a
software
system
may
be
segmented
and
decomposed
into
multiple
version.
B
Software
applications,
but
every
version
software
application
needs
to
have
a
dedicated
git
repository
and
now,
by
the
way,
it's
perfectly
fine
for
one
version:
software
application
to
have
multiple
processes,
for
instance
a
web
application
and
a
sql
server
database
and
a
couple
of
offline
jobs.
Those
are
all
different
processes
that
have
to
be
deployed
but
they're,
a
part
of
one
versioned
software
application.
B
So
every
git
repository
has
one
software
build
configuration
when
you
have
a
build,
you
build
everything
in
that
git
repository
and
you
create
a
release
candidate
with
that,
and
then
you
deploy
that,
and
so,
if
you're,
some
of
you
know
out
there,
thinking
wait
a
minute.
No,
no!
We
currently
build.
We
currently
build
just
part
of
the
git
repository
and
we
take
only
one
piece
of
it
and
then
we
build
well.
You
also
might
be
wondering
why
has
this
thing
gotten
so
complicated,
and
why
do
we
fight
with
the
tooling?
That's
why?
So?
B
You
need
one
git
repository,
which
has
one
version:
software
application,
which
has
one
software
build
configuration.
You
build
everything,
that's
in
that
git
repository
and
produce
a
release
candidate,
and
then
you
deploy
it
downstream
to
the
different
environments
and
we'll
talk
about
testing
in
each
of
these
stages
as
well.
B
There
is
a
concept
that's
constantly
represented
in
in
your
devops
pipeline,
and
that
is
the
concept
of
a
test.
Now
some
of
you
are
very
familiar
with
test
driven
development,
and
so
the
concept
of
a
test,
you've
heard,
arrange,
act,
assert
so
just
think
of
a
unit
test.
There
are
steps
that
you
do
to
arrange
things
to
be
prepared
in
order
to
conduct
the
test
and
exercise
the
system
under
test
and
then
the
act.
B
The
act
is
actually
doing
it,
calling
the
right
method
executing
it
and
then,
after
that,
there's
multiple
things
that
you
do
to
execute
assert
statements
to
check
to
make
sure
that
the
right
thing
happened.
Well,
that's
that's
the
constitutive
test,
so
think
of
the
test
as
an
abstract
concept
and
even
a
c-sharp
interface.
I
test.
B
Okay,
it
has
multiple
things
to
do
to
set
up
and
get
ready,
arrange
one
thing
in
order
to
do:
do
it
and
then
multiple
things
to
check
to
make
sure
that
the
right
things
happened
all
right
now,
let's,
let's
evaluate
that
and
apply
that
to
our
builds
well,
every
pipeline
is
going
to
have
two
build
configurations.
You
have
your
private
build
and
you
have
your
integration
build
and
I'm
going
to
go
pretty
fast.
So
some
of
these
things-
you
don't
quite
catch,
refer
back
to
the
2006
book,
titled
continuous
integration.
B
It
was
the
seminal
book
that
defined
the
practice
of
continuous
integration
and
there
are
three
key
steps.
You
have
your
private
build
which
happens
on
the
developer.
Workstation.
To
answer
the
question:
can
I
share
this
code
with
my
team
or
have
I
destabilized
the
source
code?
That's
your
private,
build.
It
runs
locally,
all
completely
locally.
B
Then
the
integration
build
is
on
a
shared,
build
server.
Of
course,
azure
devops
provides
those
shared,
build
servers
and
it
answers.
The
question
is
this
code:
now
mixed
and
mingled,
with
code
from
other
team
members,
still
stable
and
ready
to
be
ready
to
be
deployed
to
an
environment,
or
is
this
code
mixed
with
the
other
team
members
now
unstable
and
we
need
to
fix
it?
Okay,
so
those
are
the
two
builds.
B
The
third
step
of
continuous
integration
is
the
first
deployment
and
that
answers
the
question:
does
this
release
candidate,
which
is
the
product
of
the
build
and
oftentimes
we
say?
Does
this
build?
Does
this
build
as
a
noun
still
deploy
start
up
and
generally
work
like
it
should?
Because
if
it
doesn't,
we've
destabilized
something
and
there's
no
there's
no
purpose
to
even
deploy
to
a
manual
test
environment
and
waste
a
human's
time?
B
We
don't
have
cd,
we
don't
have
continuous
delivery,
which
is
now
somehow
a
synonym
of
just
deployments
and
then
we'll
look
at
what
they
have
and
they
have
an
automatically
contr
automatically
triggered
compile
process,
but
they
thought
that
they
had
quote
ci.
So
I
just
want
to
stress
that
continuous
integration
has
three
key
steps
and
you
need
all
three:
the
private
build
integration
build
and
your
first
deployment.
Okay,
if
you
have
those
three
steps
in
place.
B
Well
then,
yes,
you
have
continuous
integration,
then
you
can
of
course
go
on
to
deploying
to
test
environments
and
staging
and
production
whatnot.
But
think
of
this
concept
of
I
test
the
abstract
test,
your
private
build
is
a
test.
There's
things
that
you
do
to
set
up
and
get
ready
to
go.
The
act
is
actually
transitioning
from
source
code
to
executable
artifacts,
which
is
compilation
assuming
you're,
running
msbuild.exe,
on.net
framework
and
running.net.exe
on
net5.net
core,
and
then
the
assert
statements
are
multiple.
B
If
you
have
a
unit
test
suite
great,
that's
that's
one
thing
you
do
to
check
to
see:
if
hey
are
things
going
well,
an
integration
test
suite
is
another
assert
in
the
private
build
if
you
have
a
static
code
analysis
and
and
same
thing
with
the
integration
build.
So
you
need
those
things
now.
If
we
can
map
it
out
and
look
at
the
steps
in
the
arrange
column,
we
definitely
have
to
clean
up
temporary
files
and
things
of
previous
runs.
B
In
the
act
column,
it's
compilation
in
the
assert
column,
unit,
test
integration
test
and
then
and
then
you
would
do
essentially
a
test
tear
down
or
finish
out
on
the
build
server
now
static
code
analysis
as
you
as
you
mature.
That
really
should
be
an
assert.
So
but
if
you're
just
getting
started
with
static
code
analysis,
sometimes
you'll
say
you
know
what
we
can't
fail
it
just
yet,
because
we're
still
learning
what
rule
sets
we
need.
That's
fine.
B
Okay,
so
at
the
end
of
the
build,
we
need
to
package
our
release
and
if
you
have
an
application
that
has
a
web
application,
an
offline
job,
sql
server
database
and
then
a
full
system
acceptance
test
suite.
Then
you
have
four
things
that
are
going
to
need
to
be
deployed
to
the
tdd
environment,
which
I'll
talk
about
a
minute.
B
In
azure
pipelines.
There
is
the
old
style
drop
method
of
storing
build
artifacts,
and
that
came
about
before
the
azure
artifacts
product
was
online
with
a
built-in
nuget
server,
and
so,
if
you're,
if
you're
starting
a
configuration,
now
just
ignore
the
built-in
build
artifacts
and
for
every
deployable
process
in
your
application
package
that
up
as
a
nuget
package
and
store
it
in
azure
artifacts.
B
Command
line,
but
what
I
love
to
do
is
use
the
open
source
tool
octopack,
which
is
actually
a
wrapper
around
the
nuget
command
line,
and
it
simplifies
the
command
line.
Experience
of
zipping
up
everything
you
need
to
in
our
literally
you
can
call
net.exe
publish
on
a
particular
project
and
then
the
resulting
directory.
B
It
just
has
a
few
idiosyncrasies
that
you
have
to
deal
with,
whereas
octopack
deals
with
those
idiosyncrasies
for
you
and
creates
nuget
packages
when
the
purpose
of
that
is
for
deployment
now,
some
people
say
well
wait
a
minute.
What,
if
I'm,
what
if
I'm
planning
on
deploying
it
as
a
docker
container
in
those
cases
that
the
docker
can-
and
this
is
just
speculative
by
the
way,
the
docker
container.
B
If,
if
the
deployment
is
a
docker
host,
the
actual
package
may
end
up
being
your
your
docker
container,
all
right,
so
you
need
four
all
right
in
this.
In
this
example
that
I'm
showing
on
the
screen,
you
need
four
one
for
each
independently
deployable
process
and
I'll
talk
about
the
test
suite
later.
B
All
right
here
is
the
dependency
diagrams
of
the
different
environments.
Now
I
haven't
talked
about
the
environments,
yet
we
have
the
tdd
environment,
the
uat
environment
and
the
production
environment.
These
are
categories
of
environments.
Every
devops
pipeline
will
have
a
minimum
of
three
environments.
Okay,
so
as
you
as
you
configure
your
release,
manager
or
if
you
use
the
new
yaml
style
multi-stage
in
in
azure
pipelines,
you
need
at
least
three
environments
to
deploy
to
and
let's
just
walk
backwards.
Production
is
a
category
of
environment.
B
To
start
out
with,
you
may
only
have
one
production
environment,
but
a
lot
of
people
have
multiple
production
environments,
but
production
is
a
category.
Let's
take
salesforce
or
skype.
They
don't
have
just
one
production
environment.
There's
multiple
production
environments,
heck
azure
azure
has
what
over
a
dozen
production
environments.
Now
every
region
is
a
production
environment.
B
Now
every
region
is
implementing
implemented
as
a
cluster,
so
here
in
austin
texas,
if
I
choose
south
central
in
order
to
be
in
san
antonio,
then
I
choose
essentially
I'm
choosing
the
san
antonio
production
environment,
but
I
know
under
the
covers,
there
are
two
different
buildings
that
make
up
south
central
because
of
the
redundancy
that
is
the
clustering
at
the
data
center
level.
So
you
still
have
you
still
have
those
concepts
represented
but
need
at
least
one
production
environment.
B
Let's
walk
back
from
there
manual
testing,
uat
manual
testing
is
a
category
we
need
to
have
at
least
one
environment
where
people
can
manually
test
and
uat
is
a
really
common
user
acceptance
test.
That's
a
really
common
name
for
a
manual
test
environment.
We
need
at
least
one
environment.
Now
in
a
lot
of
organizations,
you
need
to
parallelize
that
as
well.
You
need
multiple
common
names
for
manual
test
environments
are
dev
test,
sit,
ditch
staging
you
know
any
any
number
of
names
and
you
can
choose
to.
B
You
know
deploy
to
all
of
them
at
the
same
time
or
you
can
stage
a
few
in
a
row,
but
they
are
all
manual
test
environments
and
you
can
have
as
many
as
you
want,
but
you
need
at
least
one.
If
you
don't
have
one,
you
can't
do
manual
testing,
okay,
pull
back
from
manual
testing
environment,
and
now
we
have
our
test
automation,
environment.
This
is
the
environment
that
fulfills
the
last
stage
of
continuous
integration.
That
answers
the
question:
will
this
build
even
deploy?
B
Will
this
build
even
start
up
properly
on
on
this
configuration,
and
will
this
pass
our
full
system
test?
Will
it
generally
work
and
you
need
at
least
one
of
those,
the
most
common
name
for
that
is
the
tdd
environment
stands
for
test
driven
development?
No
humans
are
allowed
on
this
environment.
It
doesn't
make
any
sense.
The
bill
is
just
going
to
automatically
deploy,
run
the
test
kind
of
throw
it
away,
and
so
it's
perfect
for
infrastructure
as
code
in
azure,
because
it
can
just
create
the
environment,
use
the
environment,
throw
the
environment
away.
B
Now,
if
you're
going
to
run
endurance
tests
that
run,
you
know,
run
the
software
for
seven
days
straight
to
check
for
memory
leaks
or,
if
you're,
going
to
do
some
security
penetration
testing.
If
you
have
other
types
of
test
suite,
you
know
what,
maybe
you
need
more
than
one
test
automation,
environment,
that's
particularly
fine,
but
you
need
at
least
one
okay.
B
There
was
gonna,
be
designer
support
and
and
at
azure
release
manager,
as
you
see
on
the
screen
was
going
to
be
brought
over
into
the
fold
subsequent
to
that
a
lot
of
key
people
left
and
went
to
github,
and
so
the
roadmap
materially
changed
here.
We
are
a
year
and
a
half
later
and
we
have
a
v1
implementation
or
really
a
half
implementation
of
the
ammo
configuration
in
for
your
builds
and
a
lot
of
people
are
thinking
man.
Why
don't?
Why?
Don't
I
understand
this?
Why
is
it
so
hard?
B
Why,
for
some
of
these
steps,
I
have
to
insert
a
magic
grid
in
the
yaml
and
then
other
teams
are
are
saying
really.
I
just
prefer
using
the
designer
and
then
people
say
no,
no,
you
need
to
store
your
build
configuration
in
the
git
repository.
We
need
to
be
using
yaml
and
we
have
a
half
implementation
right
now,
so
it
can
be
a
little
bit
stressful
because,
yes,
we
would
love
to
have
the
advantages
of
storing
the
build
configurations
in
the
same
git
repository
as
our
application.
B
B
Unfortunately,
I
still
recommend
using
the
designer
version
you're,
not
getting
the
benefit
of
being
able
to
branch.
Your
build
configurations
like
you
would,
if
you
stored
your
configuration,
your
build
configuration
in
source
control,
but
given
that
we
are
still
waiting
on
some
of
the
critical
enhancements
to
the
yaml
version,
unfortunately,
that's
what
we
still
recommend
and
I
want
you-
I
don't
want
you
fighting
with
the
tool.
I
want
you
to
get
down
the
road
and
be
able
to
move
fast.
B
So
that's
what
I
find
myself
still
still
recommending
now
for
people
who've
reached
expert
level
with
azure
devops.
You
don't
need
a
recommendation
for
me
if
you
are
already
at
expert
level
in
azure,
devops
and
you're,
slinging,
yaml
and
and
the
the
downsides
don't
phase
you,
then
by
all
means
you
make
your
own
decision,
but
for
people
who
who
really
are
asking
for
that
recommendation
from
me.
B
That's
the
recommendation
that
I
give
because,
like
because
the
designer
scenario
it
works,
and
it's
simple
and
I'll-
show
you
an
example
a
little
bit
later,
all
right,
let's
get
into
the
environments.
So
we
have
this
concept
of
a
abstract
test.
Well,
your
tdd
environment
is
an
implementation
of
a
test.
Your
manual
test
environment,
uat,
is
an
implementation
of
a
test.
Your
production
environment
is
an
implementation
of
a
test.
B
Let
me
tell
you
why:
the
the
td
environment,
your
test,
automation,
environment,
we're
going
to
do
some
setup,
we're
going
to
configure
the
environment,
we're
actually
going
to
deploy.
That's
our
act
and
the
asserts
are
the
acceptance
test
suite
to
make
sure
that
everything
goes
well
in
our
manual
test
environment.
We're
going
to
have
the
same
setup.
B
It's
going
to
be
a
little
bit
different
because
we're
not
going
to
load
data
on
every
on
every
deployment,
but
the
assert
is
done
by
humans.
The
assert
is
done
by
a
person
that
comes
in
and
either
gives
their
thumbs
up,
or
they
say,
nope
something's
wrong
with
it
and
then
log
a
bug
same
thing
with
production.
Now
we
could
think,
oh
when
we
deploy
to
production,
then
we're
done.
B
But
that's
not
the
case.
Everyone
here
probably
remembers
the
scientific
method
and
the
most
important
part
in
the
scientific
method
is
the
realization
that
the
process
of
science
can't
actually
prove
anything
and
can't
actually
make
any
definitive
statements.
But
it
is
a
process
of
experimentation
so
that
we
can
disprove
our
wrong
guesses.
Why?
Because
the
scientific
method
starts
with
a
hypothesis.
B
Okay,
we
from
our
judgment.
In
our
past
experience,
we
make
a
guess
at
the
answer
to
some
question.
Then
we
craft
an
experiment
that
says:
okay.
If
my
guess
is
right,
then
some
other
scenario
will
all
will
be
true
and
we
craft
an
experiment
which
is
an
essentially
an
assert
statement,
and
if
that
doesn't
come
out
to
be
true,
we'll
guess
what
our
hypothesis
was
wrong
and
if
we
do
enough
experiments
and
enough
tests
of
our
hypothesis.
B
Well,
then
other
people
start
to
believe
that
our
hypothesis,
just
might
be
true.
We
still
can't
say
it
definitively
is
true,
but
we've
done
enough
experiments
that
other
people
believe
in
the
experiments
that
we've
done,
and
so
we
come
to
an
understanding
and
that's
how
hypotheses
become
theories
and
theories
become
laws.
Okay,
same
thing
with
software
architecture,
software
in
general,
we
want
to
accomplish
something
in
the
marketplace
and
so
product
management
of
course
think.
How
could
we
do
that?
B
B
Well,
we
deployed
a
production
that
is
actually
the
conducting
of
an
experiment,
and
so
that
is
when
we
need
to
start
collecting
telemetry
from
how
our
users
are
using
the
software
to
see
if
our
hypothesis
is
correct
because
it
might
not
be.
There
were
some
some
studies
and
surveys
just
a
couple
years
ago,
that
looked
at
the
effectiveness
of
scrum's
product
owner
role
and
and
what
the
study
found
was
that
and
sam
gukenheimer
actually
would
participate
in
the
study,
and
he
kind
of
turned
me
on
to
this.
B
He
was
a
guest
on
the
azure
devops
podcast
a
couple
years
back,
and
he
said
that
what
the
study
found
was
that
a
third
of
the
time
what
the
product
owner
said
we
should
do
was
was
spot
on
a
third
of
the
time
it
got
the
desired
effect
out
in
the
marketplace
with
the
users.
It
was
awesome,
a
third
of
the
time
we
did
the
software,
we
put
it
out
there.
It
had
absolutely
no
effect
on
the
problem
whatsoever.
B
We
invested
the
time
we
did
the
development,
it
had
no
effect
on
what
we
were
trying
to
accomplish
and
then
a
third
of
the
time
we
did
it
and
it
did
the
opposite
of
what
we
wanted.
It
was
actually
destructive
it.
It
fought
against
us
from
what
we
were
trying
to
accomplish
and
we
need
to
roll
it
back
and
get
that
out
of
there.
Okay,
so
the
concept
of
a
person
product
owner
in
that
scrum
process,
somehow
being
the
ultimate
subject
matter
expert.
B
No
one
can
be
okay,
so
we
need
to
recognize
that
what
we
are
doing
all
those
issue
cards
that
pop
up
on
our
board.
Those
are
hypotheses.
Those
are
hey.
This
would
be
a
good
thing
to
do
and
it
would
help
us
accomplish
a
goal,
but
when
we
get
to
production,
if
we
don't
gather
telemetry
intentionally
and
funnel
that
back,
then
we
have
no
ability
to
finish
the
test,
which
is
assert
statements.
B
Did
users
start
using
the
software?
More
did
lost
passwords,
go
down,
did
revenue
go
up?
Did
sales
go
up,
did
shopping,
cart,
completions,
go
up
whatever,
whatever
you're
trying
to
accomplish
all
right.
So,
let's
dive
into
what
a
deployment
to
the
tdd
environment
looks
like,
and
there
is
a
pattern
that
emerges
and
if
you
have
pages
and
pages
of
steps
in
your
azure
devops
configuration,
then
you're
not
you're,
not
using
the
tool
like
it's
intended
to
be.
There
is
a
clear
pattern
that
you
go
through
and
this
particular
one
has
three
iterations.
B
Okay,
there
are
three
things
that
are
being
done
here
and
you
can
see
the
pattern
I'm
to
skip
the
first
step
right
now.
So
look
at
the
step
obtain
database
package.
These
first
four
steps
are
doing
database.
Okay,
now
I'm
ignoring
the
offline
job
and
because
I
don't
want
the
screen
to
be
too
big,
but
for
each
imagine
a
for
each
statement
for
each
deployable
process
in
my
release,
candidate,
meaning
for
each
unique
nuget
file
that
has
the
same
name
and
version
number
ie
is
the
same
release.
B
Candidate
one
release
candidate
can
have
four
nuget
files,
it's
the
same
release
candidate,
but
there's
four
things
to
deploy
for
each
of
those
files.
We
need
to
get
the
package,
we
need
to
do
some
environment
configuration
and
then
we
need
to
put
the
files
there.
That's
the
deployment,
okay,
all
right!
So
that's
the
database.
The
database
has
these
four
steps
in
the
azure
pipelines
configuration
next.
One
is
the
ui
which
is
the
asp.net
web
web
application.
B
We
need
to
deploy
that
web
application
to
azure
app
service
in
this
case,
so
we
need
to
get
obtain
ui
package.
We
need
to
get
the
package
get
the
nuget
file.
We
need
to
do
some
environment
configuration
which
is
really
this
for
this
next
one,
and
then
we
need
to
copy
the
files
there
which
is
ui,
deploy
and
then
because
it's
a
web
application,
you
have
to
do
one
more
step,
which
is
start.
The
web
application
start
the
website.
B
B
Are
you
running
and
are
you
healthy
and
the
software
needs
to
be
baked
in
the
ability
to
answer
that
question,
and
so,
if
we
call
a
web
server,
so
we
call
essentially
an
api
controller
on
a
web
application.
We
should
be
able
to
ask
it:
are
you
running
and
are
you
healthy
now
it
can
quickly
if
it
can
answer
back.
Are
you
running?
Well,
that's
yes,
but
are
you
healthy?
B
Well,
we
don't
want
to
just
return
a
canned
answer
because
if
it
doesn't
have
the
connection
string
to
its
database
and
if
it
can't
talk
to
its
database
or
whatever
other
dependencies
that
it
has,
then
it's
not
healthy.
So
you
want
to
have
a,
and
this
is
more
elaborated
in
the
book.
You
want
to
have
a
health
check
controller,
which
has
just
a
couple
ends
of
code
to
call
out
to
each
of
the
key
dependencies
just
to
make
sure
it
gets
a
return
call
before
it
passes
back
the
answer.
B
So,
however,
many
dependencies,
this
particular
deployed
process
has
you
want
to
have
just
a
few
lines
of
code
to
tickle
each
dependency
before
you
report
back.
I
am
healthy.
Okay
because
it
doesn't
know
it.
Does
this
no
good
in
azure
devops
for
this
deployment
to
report
back,
I
was
successful,
but
then
you
pull
up
the
you
pull
up
the
software
and
it's
completely
broken
and
you
find
oh,
it
didn't
actually
deploy
properly
because
deploying
properly
means
starting
up
properly.
Okay.
So
we
want
this
to
check
to
see
hey.
B
Did
you
start
up
properly
and
are
you
healthy
and
we
don't
want
to
have
to
burden?
We
don't
have
the
logic
of
of
health
as
a
part
of
our
deployment
configuration
here.
We
want
the
we
want.
The
deployed
process
itself
to
know
how
to
self-evaluate
what
it
means
to
be
healthy.
Okay,
all
right
after
this
self-health
check.
Now
we
go
and
we're
we're
going
to
do
more
assertions,
but
now
we
have
a
test
suite
to
deal
with,
but
in
order
to
deploy
the
test
suite,
we
do
our
same
pattern.
B
Get
the
nuget
package
do
a
little
bit
of
environment
configuration
poking
in
configuration
files
and
whatnot
and
then
checking
asserting.
Well,
we
can
run
vs
test
and
actually
run
that
in
unit
or
xunit
library.
That's
going
to
in
the
web
context
probably
run
some
selenium
tests
which
open
up,
browsers
and
type
in
text
boxes
and
click
buttons
and
actually
run
tests
that
exercise
the
fully
deployed
new,
build
that
we
have
and
then
at
the
end
of
the
tdd
environment
deployment
configuration
we
just
run.
This
run
this
process
that
deletes
the
resource
group.
B
B
You
want
to
look
at
the
configuration
and
make
sure
that
you,
you
mandate,
that
all
reviewer
comments
be
addressed
and
that
the
integration
build
succeeds
before
allowing
a
pull
request
to
be
approved
and
capers
jones
has
a
has
some
some
findings
and
all
of
his
studies
and
a
recommendation
about
how
to
how
to
increase
quality
in
a
team
setting.
He
found
that
there
were
three
quality
control
techniques
that,
when
put
together,
had
a
high
correlation
with,
with
overall
delivered
quality
of
a
software
team.
B
The
first
one
was
testing
in
general,
just
different
levels
of
testing.
So
if
you're
doing
manual,
testing
unit
testing
automated
unit
testing
automated
integration
testing
automated
full
system
testing,
you
definitely
got
the
testing
covered.
Then
the
next
one
was
static
code
analysis,
if
you've
put,
if
you
put
the
rosslyn
static
analyzers
in
your
integration,
build
and
are
failing.
If
you
have
some
rules
that
that
absolutely
fail
and
you're
you've
got
those
in
there,
then
that
satisfies
that
and
you're
doing
good
there.
B
The
third
one
is
formal
inspections,
and
that
is
having
the
code
and
changes
reviewed
and
taken
through
a
formal
inspection
checklist
and
the
pull
request.
Implementation
in
azure
devops
is
perfect
for
the
implementation
of
formal
inspections,
and
so
if
any
managers
are
on,
this
call
go
back
to
work
and
figure
out
how
to
create
an
inspection
checklist
start
small.
I
mean
it
could
be
things
like.
B
Every
new
change
or
every
new
class
has
a
corresponding
additional
automated
test
of
some
sort.
If
we
made
a
change
to
the
code-
and
we
didn't
add
an
additional
test
well,
that
pull
request
should
not
be
completed.
That's
that's
a
rule
that
I
suggest
by
the
way,
but
whatever
it
is,
for
your
team
make
a
bullet
list
of
things
to
check
okay
and
and
then,
when
someone
hits
the
approve
button
on
that
pull
request,
they're,
basically
saying
hey,
I
went
through
the
checklist.
B
I
made
sure
that
this
this
set
of
changes
here
complies
with
everything
that
we,
as
a
team,
said
that
we
were
going
to
be
consistent
with
and
then
that's
it.
That's
it's
not
hard,
but
it
has
such
a
profound
effect
because
we,
as
a
team
could
say
we
do
all
these
things
in
a
consistent
way,
but
we
don't
and
we're
stressed-
and
we
try
to
go
fast.
B
We
forget
we
just
don't,
but
but
implementing
inspections
is
going
to
increase
your
quality,
and
so
I
highly
encourage
you
to
enable
pull
requests
and
get
your
team,
an
inspection
checklist
okay.
So
let's
talk
about
the
different
classes
of
environments
and
what
types
of
things
that
you
should
be
doing
with
each
of
the
classes
of
environments.
Again
these
are
the
these
are
the
classes
of
environments
and
you
need
one
of
each.
You
need
at
least
one
of
each
in
your
devops
pipeline.
B
You're-
probably
not
going
to
recreate
that
environment
every
time,
because
it
would
it
would
mess
with
manual
testing
scenarios,
so
you'd
have
some
on-demand
steps
and
then
definitely
by
the
time
you
get
to
production,
you're
going
to
do
less
and
less
now
notice
that
running
the
health
check
is
across
every
environment.
You
don't
know
that
a
deployment
succeeded
until
you
ask
the
application.
Hey
ed.
Did
you
start
up
hey?
Are
you
healthy?
Okay?
B
Even
if
your
application
is
an
offline
job
of
some
sort,
running
azure
functions
or
web
job
or
a
dapper
sidecar
app
or
you
just
you
need
to
ask
it
hey.
Are
you
online?
Are
you
running
and
are
you
healthy?
Are
you
happy
because
if
any
of
those
processes
can't
get
to
one
of
their
dependencies,
they're
not
happy
and
the
first
time
you
run
a
transaction
of
a
certain
type?
B
Every
time
you
do
something
you
want
to
capture
what
the
screen
looks
like
and
then
save
it
off
as
an
image
file
and
azure
devops.
The
azure
pipeline's
integration
with
the
azure
test
plans
just
keeps
every
one
of
those
screenshots
and
and
it's
beautiful
and
it
works
simply,
and
every
test
you'll
be
able
to
see
the
steps
that
go
through
I'll
zoom
in
a
little
bit,
and
you
can
see
you
can
see
this
screen
of
this
example.
Web
application.
You
see
some
text
boxes
and
you
see
the
save
button.
Okay,
now
this
test.
B
If
this
test
fails
at
some
sort
which
the
tests
were
designed
to
fail
when
we
break
it,
and
so
this
test
will
fail
at
some
point
and
as
long
as
we
have
a
screenshot,
it's
going
to
save
us
a
whole
lot
of
money
with
repro
reproduction,
we'll
be
able
to
see
what
the
screen
looked
like,
which
will
probably
point
us
in
the
right
direction.
If
we
can't
see
what
the
screen
looked
like,
all
we
know
is:
oh
the
test
failed.
Well,
when
did
it
fail?
Well,
maybe
we
can
go.
B
It's
belong
through
the
logs
and
see
what
line
of
code
in
the
test
method
actually
failed,
and
then
why
did
it
fail?
But
if
we
have
the
screenshots
every
step
of
the
way
we're
taking
screenshots,
we
know
exactly
what
happened.
So
I
highly
encourage
you
to
use
azure
devops
in
this
way.
It
sounds
like
it
sounds
so
simple,
take
screenshots
and
save
them
now
on
every
single,
every
single,
build,
every
single
deployment
to
the
tdd
environment
and
every
single
acceptance
test.
That's
run
in
the
td
environment,
keep
every
single
image
file.
B
Yes,
that's
exactly
what
I
mean.
It
will
be
a
long
time
before
you
even
think
about
the
amount
of
image
files
that
you
want
to
save,
and
you
know
what
there's
there's
a
solution
for
for
storage
anyway,
you
just
you
only
keep.
You
know
the
last
some
number
of
builds.
If
you
don't
care
what
happened
over
a
month
ago,
okay,
azure
devops
will
automatically
clean
that
up
for
you
no
big
deal,
but
yes,
you
want
as
granular
information
as
possible
here
all
right.
B
Let's
talk
about
production
telemetry
that
I
that
I
push
so
much
logs
are
important.
Logs
are
great,
but
logs
only
get
you
so
far.
You
also
need
to
add
to
your
telemetry
tool
belt
logs.
Don't
actually
give
you
the
full
picture,
we
we
often
do
software
that
equips
and
populates
data
warehouses,
so
that
our
customers
and
our
users
can
ask
intelligent
questions
about
the
data
and
find
trends.
B
Metrics
are
numbers,
events
are
names
and
often
often
include
metrics.
Now,
let's
look
at.
Let's
look
at
our
application
again,
really
just
simple,
simple
application
scenario:
here
everybody
has
at
least
one
of
these.
You
have
a
you:
have
a
web
application.
You
have
an
offline
job,
you
have
a
sql
server
database.
B
You
have
a
test
suite
every
one
of
those
should
emit
logs
metrics
and
events
to
application,
insights,
okay,
it
works
hand
in
hand
with
works
hand
in
hand
with
azure
devops,
and
if
I
go
back
to
the
view
of
the
deployment
notice,
the
first
step
release
annotation.
This
is
actually
telling
application
insights
hey.
B
I
am
deploying
version
such
and
such
of
applications
such
and
such
okay,
we'll
see
that
a
little
bit
later,
all
right
web
application,
yep
nice
to
stream,
to
the
same
instance
of
application
insights.
All
of
the
deployed
processes
of
a
particular
application
need
to
push
their
data
to
the
same
instance
of
application.
Insights.
Now,
log
analytics.
If
you
have
vms
or
if
you
have
other
legacy
stuff,
then
you
can
aggregate
all
that
stuff
in
log
analytics.
B
But
if
you
have
everything
in
azure
in
azure
resources,
then
you
might
not
even
need
log
analytics
and
you
can
get
everything
you
need
from
application
insights.
Okay,
now
just
by
enabling
application
insights,
you
get
a
lot
of
logs
for
free
and,
if
you're,
using
entity
framework,
if
you're
using
sql
server,
there's
so
much
that
application
insights
knows
because
it
knowsabout.net,
and
so
the
actual
logging
of
what
query
is
being
run.
B
B
Okay,
they
have
names,
and
you
could
probably
guess
that
this
application
uses
a
cqrs
pattern,
because
these
are
named
in
the
form
of
a
command
which
effectively
is
just
wrapping
up.
The
intent
of
the
user
or
the
request
of
a
user
in
the
form
of
an
object
and
it's
carrying
object-oriented
development,
all
the
way
up
to
the
user,
interface
and
packaging
up
what
the
user
asked
to
do
as
an
object
and
then
carrying
it
forward.
B
Okay,
highly
recommend
that
method
by
the
way,
and
so
we
can
see
different,
different
custom
events
and
we
can
choose
some
of
them
and
graph
them
over
time
and
see
that
oh,
we
actually
have
an
increase
in
and
we
can
see
which
events
we
have
an
increase
of
and
which
events
maybe
stayed
stable.
It's
one
thing
to
say:
oh
our
requests
per
second
or
our
overall
requests
went
up.
Okay,
what
does
that
mean?
B
Did
did
the
transactions
that
we
care
about
increase
or
just
general
usage,
some
of
which
that
we
don't
care
about?
Okay,
these
green
boxes.
These
green
check
marks
across
the
top
are
the
annotations,
the
release
annotations
for
every
one
of
the
green
box.
That
is
a
deployment
to
the
environment
that
we
have
selected
for
this
particular
graph.
B
B
A
B
B
The
answer
to
your
question
is
yes,
it
has
been
updated
in
ms
build
octopack
was
a
nuget
package
with
net
core
octopack
is,
is
an
exe
command
line
tool,
and
so,
as
you're
running.net.exe
publish
all
the
files
that
need
to
get
to
an
environment
will
be
put
in
your
published
directory
and
then
you're
on
octopack.exe,
again
giving
it
that
directory
path
and
it'll
do
its
thing
and
produce
your
nuget
package.
So,
yes,
it's
been
updated
with
net
core.
A
B
A
It
says:
oh,
it's
already
created,
it
doesn't
create
it
for
you,
so
we
build
all
of
the
the
pipeline
out,
but
when
we
try
to
attach
the
project
to
it,
we
can't
say
hey.
I
want
you
to
build
this
pipeline.
When
you
check
it,
you
know
it
wants
to
create
a
new
one.
I
just
find
that
really
difficult,
or
you
know
really
frustrating
that
we
can't
attach
to
an
existing
pipeline.
A
B
B
You
ended
up
having
a
general
sim,
a
similar
structure
because
you
wanted
to
mimic
it,
but
you
still
had
to
duplicate
and
create
five
additional
five
cruise
control
configurations,
which
was
the
definition
of
of
that
pipeline,
and
so
I
think
the
same
has
been
in
nant.
The
same
has
been
in
team
city.
I
think
the
same
has
been
in
in
azure
pipelines,
and
so
it's
up
to
it's
up
to
the
organization
to
create
consistency
or
some
conventions
across
teams
and
across
projects.
Because
yeah
you
do.
B
You
are
kind
of
having
independent
logic
now
when
it
comes
to
when
it
comes
to
the
the
integration
build.
Most
of
that
logic
ends
up
being
stored
in
source
control.
In
your
in
whatever
your
build
script
is
microsoft
doesn't
provide
one
and
that's
unfortunate
still
because
over
you
know
almost
two
decades
now
the
structure
of
a
build
file
or
even
in
the
90s,
with
c-sharp
a
make
file.
B
The
structure
of
those
is
actually
a
well-known
pattern,
and
but
microsoft
still
doesn't
provide
one,
and
so
too
many
customers,
too
many
users
of
azure
pipelines,
end
up
using
all
of
those
step
templates
and
actually
creating
make
file
logic
in
azure
pipelines
and
it
just
it's
not
maintainable
that
way.
So
in
my
book
I
do
give
a
template
for
a
dot
net
core
build
file
in
powershell
format
that
that
can
simplify.
That
now
I
will
say
on
the
deployment
side,
every
environment.
B
Unless
you
extract
to
step
template
libraries,
every
environment
does
duplicate
logic,
even
if
your
intention
is
to
have
the
same
logic,
from
the
tdd
environment,
to
the
uat
environment,
to
the
production
environment
and
on
the
small
end.
Okay,
that's
a
little
paper
cut
but
as
you
rack
up
more
environments
and
your
application
may
have
you
know
two
or
three
offline
jobs
that
you're
deploying
and
you
may
have
a
web
application.
Oh,
but
then
you
also
have
a
api
application.
B
Oh,
but
now
we
also
have
a
webassembly
blazer
application,
oh
and-
and
it
gets
more
complex,
that's
when
a
lot
of
a
lot
of
azure,
devops
users,
kind
of
graduate
from
the
release
manager,
format
and
then
augment
the
product
with
octopus,
deploy
which
supports
the
more
complex
deployment
scenarios
and
has
a
single
deployment
configuration
for
any
number
of
environments
and
supports
multi-tenancy
out
of
the
box
and
really
simplifies
there.
So
you
don't
have
as
much
duplication
when
it
comes
to
deployment
logic.
A
B
Yeah,
I
will
say
it's
not
an
either
or
some
people
that
not
familiar
with
either
product
it's
octopus,
deploy
is
is
just
that
deploy
octopus,
deploy
is
not
a
build.
Server,
does
not
have
a
build
server
in
it
and
does
not
run
tests.
It
is
awesome
at
all
the
deployment,
stuff
and
environment
management
and
even
even
maintaining
your
environments,
but
it
is
meant
to
be
paired
with
a
a
product
that
has
a
first-class
build
server.
So
that's.
A
B
Awesome,
I'm
I'm
curious
to
know
how
many
people
are,
how
many
people
are
already
using
azure,
devops,
significantly
or
or
how
many,
maybe
just
using
it,
to
to
trigger
a
compilation
and
still
working
on
on
getting
the
full
integra
continuous
integration
steps
who
wants
to
throw
into
chat
kind
of
what?
What
level
of
implementation
they've
achieved.
A
We
had
it
all
automated
lower
environments
with
red
gate,
but
they
had
a
more
manual
position
for
that.
So
but
yeah
I've
been
using
it
my
current
company
for
over
six
years
and
everything's
automated,
and
I
actually
wrote
a
blog
post
about
how
much
time
it
saved
our
company
sig.
You
know
and
it's
a
significant
amount
of
time
over
the
you
know
the
past
five
six
years.
I
actually
wrote
that
for
octopus
deploy
a
few
months
ago,
okay,.
B
B
B
B
B
Oh
wait
a
minute
all
that
data
is
going
from
an
aws
data
center
to
an
azure
data
center,
as
opposed
to
you
know,
within
the
same
azure
data
center,
where
I
didn't
even
notice
the
the
large
file
copy,
so
that
just
is
just
just
something
to
keep
in
mind.
If
you're
going
to
run
your
own
octopus
server.
Okay,
great,
you
can
put
it
in
the
azure
region
where
you
want
it.
B
However,
however,
moving
registering
a
dedicated
octopus
tentacle
that
lived
in
the
azure
region
that
that
allowed
control
over
how
that
how
the
data
flowed
so
yeah
there's
plenty
of
configurations
to
make
sure
that
data
doesn't
have
to
go
through
the
host
just
to
and
a
lot
with
with
firewalls.
If
you
register
your
own
agents
with
octopus
or
register
your
own
agents
with
azure
devops,
you
want
to
control
the
network
topology
and
so
a
lot
of
times.