►
Description
Join the CDF community to discover more about what industry experts have to say about building your software stack and the tools and platforms you should be using to help you on your journey.
The panel's prompts are the following:
What does a modern software stack look like?
What things should we consider when making tooling and platform choices in 2021?
The Continuous Delivery Foundation (CDF) end user council provides the opportunity for end user organizations to have context-rich discussions on how various organizations pursue their modernization efforts in the most effective way. CDF End-User Council is open to leadership teams from CDF end-user members and invited guests. To join or for more information please visit: https://cd.foundation/end-user-council
A
Hello
good
morning,
good
afternoon,
good
evening,
all
of
you
from
wherever
you
might
be
joining
us.
I
am
tracy
miranda.
The
executive
director
of
the
continuous
delivery
foundation
joining
you
from
a
very
rainy
ottawa
in
canada.
So
thank
you
all
for
being
here.
Take
a
moment
to
let
us
know
where
you're
joining
from
and
yeah.
I'm
super
thrilled
today
to
have
this
conversation
around
tools
and
technology
choices,
and
we
have
some
really
great
folks.
B
Thank
you.
So
my
name
is
derapki
pluto
and
I'm
a
software
engineer
at
google
working
on
cloud,
ci,
cd
cloud,
continuous
delivery,
specifically
working
on
tecton.
I've
worked
on
projects
that
enables
software
engineers
to
build
and
deploy
cloud
native
applications.
I
am
a
research
grad.
I
graduated
from
mit
with
the
bachelors
in
electrical
engineering
and
computer
science,
so
I'm
very
new
in
this
field,
and
I've
spoken
in
previous
conferences,
including
continuously
library
conference
and
next
week,
I'll
be
speaking
at
the
open
source
summit.
A
C
Sure
so,
I'm
owen,
I'm
the
esri
lead
at
a
company
called
intelligent
growth
solutions,
limited
which
works
in
the
vertical
farming
space
and
yeah.
That
role
kind
of
sees
me
looking
at
things
from
the
local
dev
environment
through
to
what
we're
actually
running
in
production
and
how
we
get
observability
onto
that
and
the
various
choices
and
challenges
which
come
along
with
that
as
well,
particularly
in
a
small
company
which
is
looking
at
growth
over
the
next
year.
So
how
we
build
into
that.
A
So
how
we're
going
to
approach
this
so
first
we're
going
to
talk
in
more
details
and
sort
of
take
a
deep
dive
and
hear
from
owen
about
the
specific
case
he's
dealing
with
like
just
understand,
more
kind
of
the
real
world
issues
he's
facing
and
then
from
there
we'll
kind
of
take
a
step
back
and
sort
of
put
this
in
context
for
everybody
joining
on
the
call
and
maybe
ask
ourselves
you
know
what
does
a
modern
software
stack?
Look
like?
A
How
do
we
kind
of
summarize
some
of
these
points
to
turn
them
into
decisions?
Questions
we
can
ask
ourselves
for
decisions.
We
need
to
make
when
choosing
tooling
and
platform
choices
for
2021,
and
maybe
the
some
of
the
factors
we
need
to
think
through
and
yet
we'll
be
looking
to
drop
to
share
a
lot
on
that
and,
as
ever
folks,
please
go
ahead
and
ask
questions.
We've
got
an
ask
a
question
button
or
put
some
comments
in
in
the
comment
box
and
yeah.
A
We
might
even
be
able
to
have
some
of
you
come
and
ask
them
live
if
you're
up
for
it
and
just
be
part
of
the
discussion.
So
that's
what
it's
all
about,
just
having
real-time
conversations
and
learning
from
each
other
and
do
feel
free
to
share
your
own
perspectives.
As
we
talk
about
specific
things
in
the
stacks
as
we
go,
okay,
so
let's
get
started
and
owen.
First
of
all,
what
is
vertical
farming?
Can
you
start.
C
You
have
multiple
towers,
you
have
trays
in
the
towers
and
you
have
lifts
which
move
up
and
down
and
within
that
you
have
a
totally
controlled
environment,
so
ability
to
have
specific
temperature
changes
between
trays
is
the
ability
to
control
the
lighting
between
trays
and
the
ability
to
water
them
on
a
schedule.
It's
a
heavy
hardware
element,
there's
also
quite
a
big
software
element,
as
well
as
far
as
scheduling
things
like
growing
crops
and
this
totally
controlled
artificial
environment,
and
so
it's
got
some
interesting
advantages
to
it
in
that
it
can
be.
C
Efficient
as
far
as
use
of
water
use
of
power,
but
also
it
allows
us
to
now
look
at
growing
crops
in
areas
where
traditionally,
you
wouldn't
be
able
to
be
that
in
middle
of
a
city
or
in
an
extremely
hot
climate
which
can
support
that
traditionally
and
that's
the
idea,
it's
a
very,
very
high
density,
totally
controlled
environment
for
growing
crops.
In
so
I
think
it's
a
decent
summary,
there's,
probably
something
that.
C
So
early
work
was
largely
with
leafy
greens
because
they
were
quite
easy
to
grow,
but
I
believe
we've
looked
into
strawberries,
looked
into
chillies,
looked
into
flowers,
looked
into
things
like
seed
potatoes,
so
it's
really
vertical
farming,
as
a
concept
is
still
quite
new
and
we're
still
discovering
what
we
can
do
with
the
platform
and
our
customers
are
still
discovering
what
they
can
actually
do
with
the
platforms.
So
we
haven't
really
found
the
limitations
yet
which
is
exciting,
but
it
also
means,
in
addition
to
the
traditional
hardware
and
software.
C
C
Part
of
it
is
making
sure
we
have
the
correct
tool
in
place
to
be
able
to
quite
rapidly
diagnose
problems
which
do
occur,
which
can
be
a
little
bit
complicated
because
some
of
this
isn't
necessarily
just
pure
web
requests.
We've
got
interactions
with
hardware,
so
some
of
the
office
shelf
tooling
doesn't
necessarily
work
there
and
then
it's
also
looking
into
the
whole
kind
of
dev
release
cycle
as
well.
So
what
does
the
experience?
Look
like
from
a
developer's
perspective
of
writing
code
against
this
kind
of
modern
technology
stack.
C
What
are
the
pain
points
there?
How
can
we
optimize
the
experience
of
working
locally
versus
working
on
the
cloud,
so
it
kind
of
overall
isn't
primarily
about
reliability
of
it
in
production.
The
best
way
we
can
ensure
that
is
to
actually
bring
production,
as
far
as
we
can
left
from
the
developer
experience
and
get
that
process
working
and
get
them
familiar
with
tools
from
that
point,
so
that's
kind
of
where
the
team
sits
at
the
moment.
A
Okay,
so
when
you
came
into
the
job
you
had
an
existing
tech
stack,
so
it
wasn't
something
you
got
to
bail
from
the
ground
up
right
like
I
think
it's
a
myth.
I
don't
know
if
there's
anyone
who
has
ever
had
that
luxury
of
starting
completely
greenfield
but
was
was
that
the
case
you
had
to
contend
with
something
there.
C
Very
much
a
case
and
from
prior
to
igs,
where
I
used
to
do
more
contracting
and
consulting
it
was
also
the
case.
I
saw
quite
a
lot,
doesn't
matter
on
the
side
of
the
company,
especially
with
quite
often
in
an
early
company.
The
tooling
is
simply
largely
decided
by
what
the
early
starts
are
familiar
with,
and
that's
a
completely
valid
way
of
doing
it.
C
You're
often
trying
to
deliver
value
very
quickly,
so
you're
picking
things
which
people
are
familiar
with
and
can
iterate
on
quite
quickly
and
then,
as
you
begin
to
grow,
you
begin
to
think
more
around.
How
does
this
run
in
production?
How
do
I
integrate
these
different
bits
of
talking
together?
How
do
I
get
information
out
of
them
and
that's
probably
around
the
point
I
joined
it
was
there'd
already
been
an
established
software
function
for
a
period
of
time,
not
an.
C
Period
of
time
it
was
ramping
up
for
first
customer
release,
and
so
we
had
a
lot
of
tooling.
We
had
some
really
great
bits
of
tools,
great
bits
of
technology,
but
the
integration
wasn't
necessarily
there
and
the
overall
insight
wasn't
necessarily
there
either.
So
I
joined
it
that
slice
and
I
think,
that's
as
close
as
you
get
to
really
coming
into
greenfield-
is
there's
tooling,
but
people
aren't
too
married
to
it
at
that
moment
in
time,
but
yeah.
A
C
There
might
be
dragons
yeah,
it's
it's.
Actually,
it
is
a
really
tough
one
and
it
a
lot
of
it
depends
on
the
size
of
your
imagination.
You're
going
into
the
place
I
tend
to
start
with,
is
actually
the
release
process,
because
that
can
give
you
an
idea
of
what
types
of
tooling
they
have
running
in
different
environments,
potentially
what
the
kind
of
handover
between
environments
are
and
that
release
process
really
for
me
starts
from
developer
writing
first
line
of
code
running
into
production.
C
So
I
try
and
get
to
grips
with
that
and
dig
into
that
to
see
right.
What
are
our
targets
as
well
as
platforms
go?
Are
we
looking
at
traditional
vms?
Are
we
looking
on
premise?
Are
we
looking
at
kubernetes
running
somewhere?
What's
the
different
artifact
storage,
which
is
in
place,
then
what
languages
are
in
use?
Do
we
have
anything
like
static
analysis
of
code?
C
So
it's
beginning
that
release
process
really
gives
me
the
kind
of
high
level
view,
and
then
I
use
that
start
running
into
conversations
with
not
just
the
engineers,
but
also
the
stakeholders
or
the
product
owners
which
are
involved
to
kind
of
get
an
understanding
of
their
perspective
on
the
tooling,
as
well
as
an
understanding
of
the
engineer's
perspective
on
the
tooling,
because
you
need
to
marry
those
up
at
some
point.
Downline.
A
Yeah
no
perfect
and
yeah.
I
really
like
that
marrying
both
the
engineering
side
with
the
kind
of
commercial
or
business
goals,
okay,
so
this
might
be
a
good
time
to
ask
yourself
like
what
does
a
modern
software
stack,
look
like
like
in
today,
age
what
are
kind
of
key
features
and
drop?
Maybe
from
your
experience,
how
would
you
characterize
some
of
the
features
of
a
modern
software
stack.
B
So,
for
example,
you
can
use
saturn
to
build
test
the
applications
across
multiple
car
providers
and
hybrid
environments,
and
that's
very
critical
in
a
situation
like
ours,
where
we're
working
on
an
open
source
project,
that's
kubernetes
native
and
needs
to
work
across
different
systems
and
environments,
and
this
also
enables
our
users
to
easily
move
between
different
providers
or
environments
based
on
their
requirements.
As
the
business
is
growing
or
changing,
they
can
also
move
along
with
the
tools
and
give
them
flexibility
to
adjust
as
needed.
B
B
Some
of
the
things
that
we've
been
looking
at
in
titan
is
around
generating
and
signing
provenance,
and
we
have
a
project
called
tetron
chains.
That's
still
very
nascent
and
that's
making
progress
on
these
total
meets
that
process
for
you.
So
the
way
texture
chains
works
is
that
when
you
install
it
in
your
kubernetes
cluster,
it
will
be
a
controller
that
will
observe
your
task
runs
and
then
it
will
take
a
snapshot
of
them
when
they're
completed,
sign
them
and
then
store
them
somewhere.
B
A
second
thing
that
we're
doing
around
software,
such
as
supply
chain
security,
is
hermetic
execution,
where
you
can
specify
that
some
building
or
some
steps
in
your
release
process
should
happen
without
network
access,
and
this
ensures
that
it's
reproducible
it's
more
secure
and
it's
one
of
the
best
like
release
engineering
practices
out
there.
So
the
third
thing
I'd
mention
is
extensibility
in
modern
software
stack
in
the
tools
that
you're
choosing.
B
So,
are
you
empowering
users
to
build
the
plugins
that
they
need
to
get
functionality?
That's
not
available
in
the
tools
directly.
So
do
they
have
a
way
to
extend
api
to
get
things
that
they
need
for
their
bespoke
use
cases
or
their
requirements.
So
in
terms
of
the
way
we're
solving?
This
is
through
something
called
tecton
custom
tasks,
so
you
can
write
custom
tasks
and
their
corresponding
controllers.
That
would
run
on
your
kubernetes
cluster
to
provide
this
extended
functionality,
that's
not
available
in
the
tecton
pipelines
api.
B
So
one
controller
that
I
recently
wrote
is
tecton
pipelines
in
pipelines.
So
we
have
steps
that
built
into
tasks
and
then
pipelines,
but
we
didn't
have
a
form
of
embedding
pipelines
in
pipelines
and
we
have
use
cases
we've
had
from
users
around
needing
to
be
able
to
embed
or
specify
a
set
of
tasks
that
should
happen
within
a
pipeline.
A
C
So
actually,
this
is
once
I
actually
agree
with
everything
which
was
said,
particularly
the
extensibility
component.
I
just
wanted
to
touch
on
that
for
a
moment,
because
I
think
it's
one
of
the
big
shifts
we've
seen
over
the
last
10
15
years,
where
it
was
much
more
common
to
be
adopting
tooling,
which
had
limited
apis
where
a
lot
of
the
data
was
very
closed
off
and
so
the
ability
to
integrate
that
or
to
do
customizations
on
that
was
quite
a
high
barrier.
C
It
really
is
a
tough
one
to
actually
achieve
so
I
know
for
us
that
you
know:
we've
adopted
kubernetes
we're
using
containers
for
a
large
portion
of
what
we're
doing
and
about
95
percent
of
our
stack
is
actually
fairly
portable,
but
I'm
also
very
aware
we
have
this
five
percent,
which
is
a
azure
service.
Bus
which
doesn't
have
any
local
emulator,
doesn't
really
have
a
way
to
move.
C
C
C
The
big
thing
which
I
think
is
important,
though,
which
sometimes
get
missed,
gets
missed,
is
making
an
informed
decision
on
that
is
really
important,
not
just
kind
of
blindly
walking
into
it,
but
making
use
of
things
potentially
like
architectural
decision
records
to
capture
the
context
and
why
a
certain
tool
was
chose
chosen
with
the
knowledge
that,
yes,
it
wasn't
as
portable,
but
this
is
why
so
people
can
look
back
at
it
a
year
or
two
down
the
line
and
go
okay.
We
made
this
decision
now.
Our
circumstances
has
changed.
How
do
we
reevaluate
that.
C
Yeah
so
specifically
less
about
necessarily
capturing
the
exact
architectural
way,
that's
useful,
but
that
is
very
subject
to
change,
but
more
around
capturing
the
context
on
why
a
decision
was
made.
What
were
the
pros
and
cons
which
were
considered
what
was
looked
at
as
alternatives,
and
why
was
that
decision
made,
because
I
found
that
context?
Quite
often
he
gets
lost
and
quite
often
gets
forgotten,
especially
if
people
come
and
go
or
if
it's
been
a
period
of
time,
and
I
I
know
myself-
I've
definitely
come
into
places
and
gone.
C
A
A
C
So,
if
you're
working
in
more
regulated
sectors,
in
particular
your
number
of
options
which
you
have
or
if
you
work
in
government,
where
there's
a
specific
procurement
process,
you
have
to
go
through
your
ability
to
quite
rapidly
change
to
something
new
or
adopts
on.
You
is
limited,
even
without
that
vote
there
is.
There
is
a
challenge
in
not
wanting
to
bring
in
too
many
different
providers
too
many
different
sets
of
tooling,
which
is
why
making
smart
sources
when
you
can
is
quite
important.
C
So
if
you've
got
a
relatively
small
team,
each
new
provider,
even
if
it's
just
using
azure
and
say
google
cloud
being
able
to
bring
both
them
to
bear,
requires
cognitive
load
on
a
management
map
it
requires.
You
know
simple
things
like
setting
up
users
setting
up
security,
so
even
when
you're
in
an
environment
which
does
have
that
flexibility
in
a
lot
of
startups,
do
you
still
sometimes
have
to
limit
yourself
and
kind
of
have
to
make
a
decision?
Okay,
we
have
these
core
bits
of
platform.
So
for
us
I
would
say
we're
on
azure.
C
We
use
kubernetes
they're,
probably
our
two,
and
we
are
primarily
a
dotnet
docnet
shop
and
with
a
limited
amount
of
python,
so
there
are
other
main
constraints.
While
we
would
be
able
to
move
out
of
azure
for
something
on
google
cloud,
if
there
was
a
compelling
reason
to
part
of
the
kind
of
thought
process
on
that
would
be
okay.
What
is
the
operation
overhead
of
doing
this?
What
is
the
cognitive
load
on
developers?
How
can
we
abstract
it
away
in
such
a
way,
and
do
we
have
the
time
to
create
those
abstractions?
C
A
B
Yeah
just
to
continue
what
you're
saying
about
having
different
levels
of
abstraction
so
like
we
have
tecton,
which
provides
or
gives
you
the
all
like
most
of
the
control
that
you
would
need,
while
I'm
starting
out
with
the
kubernetes
in
question
detail.
But
you
can
have
something
like
jenkins
x,
that
uses
tecton
as
its
execution
engine.
B
It
provides
a
different
level
of
abstraction
away
and
even
things
like
ibm
cloud
or
openshift,
so
having
a
standard
that,
but
then
having
tools
that
build
on
top
of
it
and
interpret
with
it
then
gives
people
different
levels
of
control
of
flexibility
around
this.
So
beyond
portability,
security
and
extensibility
that
we
just
discussed
earlier.
One
of
the
other
things
that
I
would
consider
when
making
tooling
and
platform
choices
would
be
around
interoperability
and
observability.
B
So
around
interoperability.
The
coin
is
saying:
one
size
does
not
fit
all
so
like
do
the
tools
that
you
have
in
your
stack
or
interpolate
with
other
tools
as
you,
because
in
many
cases
you
find
that
you
need
a
combination
of
tools
to
meet
your
requirements
or
to
solve
your
use
cases.
So
we
need
to
consider
how
these
tools
work
with
other
tools.
B
So
in
our
case,
we
tacked
on
we
care
a
lot
about
interoperability,
so
it
interprets
with
jenkins,
jacket,
x,
carpol,
canadian,
even
github
actions
ago,
cd
and
many
other
continuous
delivery
tools.
So
you
can
take
what
you
need
from
each
of
all
these
tools
to
fit
your
specific
use,
cases
and
requirements
in
your
organization
and
the
second
part
is
observability.
B
So,
for
example,
as
you're
incorporating
some
of
the
continuous
delivery
practices
or
processes,
you
can
get
measurements
into
like,
for
example,
the
four
key
software
dev
software
delivery
performance,
metrics
from
that
security
book,
such
as
like
lead
time
deployment
frequency
mean
time
to
change.
Things
like
that
and
being
able
to
get
some
of
these
insights
then,
can
help
the
organization
be
able
to
influence
future
decisions
or
choices
and
adjustments
that
are
needed
to
be
able
to
deliver
your
software
safely
and
quickly
to
your
users
yeah.
B
A
Yeah,
no,
I
think
those
are
great
points.
Love
love,
the
four
key
metrics
as
well.
Nice
shout
out
to
those
yeah,
but
let's
go
to
observability,
because
I
think
when
you
touched
on
that
and
jarop
raised
some
good
points
about
observability
and
it's
not
something
that
was
even
like
a
term
a
few
years
ago.
But
where
does
that
feature
in
your
level
of
concern?
And
how
are
you
tackling
the
whole
observability
part
of
your
stack.
C
C
C
Telemetry
is
a
good
example
which
covers
some
of
that,
and
while
that's
how
I
would
tend
to
break
down
language,
if
I'm
talking
an
audience
such
as
this,
when
I
actually
talking
to
engineers
a
lot
of
the
time,
particularly
software
engineers,
those
boundaries
aren't
just
click
up
infrastructure
metrics.
They
have
as
a
model
so
there's
stuff
about
infrastructure
like
sql,
cpu
usage
and
there's
logs
from
the
application,
and
maybe
yes,
traces,
and
so
one
of
the
things
I
found
is
you
have
to
do
a
big
education
piece.
C
First
of
all
around
what
modern
observability
can
look
like,
and
by
that
I
mean
the
ability
to
actually
follow
a
journey
through
the
application.
So
you
want
to,
in
an
ideal
world,
be
able
to
follow
a
user
from
logging
in
say
for
your
front-end
service,
maybe
that's
influenced
as
a
bff
all
the
way
through
to
their
interactions
with
any
services.
In
the
back
end.
For
us,
we
want
to
be
able
to
follow
our
command.
Scheduler
and
that
takes
over
and
it
goes
from
a
command.
C
We
ideally
want
to
be
able
to
trace
that
at
the
code
level
throughout
the
different
microservices,
ideally
on
the
network
level,
but
also
look
into
what
kind
of
impact
that's
having
on
the
infrastructure
as
well.
So
are
we
doing
something
which
is
causing
xsdb
load
and
how
does
that
map
to
the
path
in
the
code
which
is
being
taken,
and
that's
a
really
powerful
thing
to
achieve
if
you
can
get
there,
particularly
if
you
can
put
that
level
of
observability
into
your
developers
hands
from
day
one
from
sorry
from
local?
C
So
if
it's
something
which
isn't
thought
about
as
an
after
for
but
it's
something
which
is
built
in
so
looking,
we've
actually
ended
up
using
new
relic.
For
this
we
were
originally
looking
at
running
an
open
source
version,
but
small
team.
We
decided
that
actually,
given
the
size
of
our
team,
the
complexity
of
this
looking
at
sas
options
is
right
way
to
go.
C
C
Being
able
to
trace
the
code
in
a
fairly
native
way
from
a
dot-net
perspective,
initially
just
dropping
in
through
agent
containers
and
then
working
with
developers
to
actually
add
that
in
a
way
they
were
familiar
with,
plus
the
integrations
we're
getting
to
that
point.
Where
we've
got
that
kind
of
full
stack
observability,
but
so
much
of
it
is
a
language
choice
and
if
new
relic
hands
had
strong
support
for
net,
we
would
have
had
to
have
looked
elsewhere.
C
C
A
lot
of
training
people,
because
initially
the
dialogue
we
were
having
was
to
the
same
set
of
vocabulary,
but
two
very
different
perspectives
on
it.
So
there
was
an
initial
stage
which
was
teaching
people
about
what
we
were
looking
for
and
what
we
meant
when
we
talked
about
traces
and
events
and
when
we
met
when
we
talked
about
that
level
information
so
that
we
could
then
have
the
conversation
about
the
requirements
before
we
actually
look
at
implementing
something.
C
Very
much
so
and
that
that
can
be
it's
a
really
powerful
thing
which
we're
seeing
in
the
industry
around
the
line
between
what
was
traditionally
a
software
engineer,
concern
and
infrastructure
concern,
because
it
is
now
becoming
a
software
engineer,
concern
you
have
software
engineers
who
potentially
specialize
in
the
infrastructure
side.
You
do
still
have
some
sysadmin
functionality
and
you
have
your
software
engineers
who
are
focusing
on
the
feature,
development
and,
while
that's
incredibly
powerful,
everyone
is
coming
with
their
own
vocabulary
from
their
own
specializations.
B
Yeah
I'd
like
to
mention
what
you
said
about
stepping
through
and
walking
through.
The
patch
is
quite
recall,
and
one
exciting
feature
that
we
just
introduced.
Detection
that
probably
should
share
here
is
debug
mode,
so
other
features
are
stable
sticks,
but
I
feel
like
that
is
one
differentiator
in
tecton,
where,
like
you,
can
actually
debug
your
continuous
delivery
pipelines.
So
in
a
task
you
can
specify
like
at
this
position.
B
I
want
you
to
stop
and
then
you
can
step
through
it
and
see
how
how
that's
working
just
want
to
point
out
that,
like
that's,
also
one
thing
that
going
beyond
being
able
to
step
through
within
your
application
itself,
but
also
being
able
to
step
through
within
your
pipeline,
is
something
that
we
are
now
enabling
or
making
progress
towards.
I
think
it's
actually
really
released,
but
yeah,
hopefully
we'll
also
be
including
our
view
and
reviews
coming
later
next
year.
C
Bugs
in
that
pipeline,
missing
steps
in
that
pipeline
can
cause
production
level
issues
if
things
are
getting
through
your
process
so
being
able
to
instrument,
that's
really
really
important
and
also
being
able
to
match
back
deployments
to
application
code
and
application
versions.
So
I
know
you
know
tools
like
I'll.
Tell
you
so
looking
at
that
from
the
overall
release
process.
How
do
you
actually
map
those
kind
of
services
to
a
version
to
a
set
of
changes,
and
I
think
that's
something
which
we're
seeing
becoming
quite
really
important
with
larger
modern
software,
snacks.
A
C
A
C
Previously,
I've
worked
on
larger
teams,
but
what
I
found
quite
interesting
with
team
size
is,
you
can
achieve
a
lot
of
team
around
five
people
and
enough
people
to
kind
of
deal
with
the
operational
stuff
and
also
do
some
of
the
development
on
upcoming
work.
When
you're
very
small,
you
really
need
to
look
at
more
sas
providers
when
you
get
to
about
five
six,
you
kind
of
have
a
bit
more
bandwidth,
a
lot
of
time
to
deal
with
operational
and
actually
looking
forward
as
it
grows
beyond
that.
A
C
One
of
the
things
I'm
excited
about
with
tetron
as
well
is
the
potential
for
taps
wanting
to
be
a
platform
for
other
tooling,
so
we're
looking
at
you
know,
there's
puppet
relay
out
there,
which
is
built
on
top
of
tact
on
there
x,
which
is
built
under
techron.
It's
a
really
interesting
platform
as
far
as
a
set
of
primitives,
which
can
be
built
on
top
and
for
us
we
are
actually
one
of
the
biggest
pains
I
have
at
the
moment
is
with
our
release
tooling.
C
So
we're
using
is
all
devops,
which
comes
from
quite
a
traditional
background.
I
think
it
used
to
be
a
team
foundation
server,
something
along
those
lines.
Only
recently
in
the
last
few
years
got
yammer
support
pipelines
prior
to
that
it
was
all
ui
based,
which
is
another
big
technology
choice
you
have
to
make
particularly
nowadays
is
we
want
as
much
as
code
as
possible.
We
want
as
much
of
every
step
of
what
we're
doing
to
be
able
to
go
through
the
same
process
of
code
review
and
analysis
and
test
written
against
it.
C
But
it
is
something
we
will
evaluate
as-
and
this
is
one
of
the
things
which
will
probably
be
next
year-
we'll
go
through
the
process,
keep
it
relatively
lightweight,
but
do
an
initial
architectural
decision
record
of
some
kind
on
what
we've
considered
and
what
the
pros
and
cons
are
and
try
and
keep
that
process
lightweight,
but
enough
to
kind
of
say
yeah.
We
have
looked
at
this,
and
this
is
why
we
didn't
at
this
moment
in
time,
but
maybe
review
it
later
download.
C
I
personally
am
very
excited
by
tacton
I,
but
I
think,
there's
still
a
challenge
there
when
it
comes
to
delivering
it
to
an
organization
which
is
one
quite
small
and
two
is
used
to
a
lot
more
of
the
kind
of
high
level
abstractions
on
top
of
their
build
pipelines.
As
far
as
the
interface
goes
as
far
as
the
management
of
it
goes,.
B
So
there's
a
lot
of
effort
in
the
dashboard
to
get
it
up
to
speed
like
I
use
expectations
and
also
without
getting
started
documentation
and
getting
new
people
ramped
up
on
the
project,
as
I
mentioned
earlier,
we're
working
towards
our
v1
release,
hopefully
for
early
next
year
and
definitely
will
come
through
our
docks
and
make
sure
that
we
have
that
full
experience
provided
to
our
users
to
get
people
up
to
speed
quickly.
But
I
really
appreciate
you
sharing
your
experiences
using
trekton
so
far.
Thank
you.
C
C
Similar
to
the
observability
piece,
though,
it
doesn't
really
work
out
that
way
and
found,
and
particularly
when
we're
talking
about
things
like
kubernetes
when
we're
talking
about
modern
cloud
practices
and
infrastructure
as
code
when
we're
talking
about
potentially
tallning
like
techton,
a
lot
of
the
people
who
I
speak
to
from
a
software
engineering
perspective,
don't
necessarily
know
what
they're
missing.
They
know
that
there's
frustrations
with
local
development
environment,
but
quite
often
it's
something
which
has
become
accepted,
there's
workarounds
in
place.
C
There's
you
know
cumbersome
processes
which
are
trying
to
try
and
bypass
or
they'll.
They
won't
be
aware
of
the
potential
there.
So
just
starting
from
a
hey.
Could
you
tell
me
what's
wrong?
It
doesn't
work
because
a
lot
of
the
time
it's
become
so
ingrained
that
we're
not
even
necessarily
thinking
about
it
on
a
day-to-day
basis.
C
Even
if
that,
for
me,
it's
not
necessarily
a
core
part
of
the
job,
but
actually
making
that
time
to
have
a
chat
with
people
to
see
what
they're
doing
to
let
them
approach
me
and
my
team
about
things
which
are
definitely
not
in
our
wheelhouse.
But
at
this
point
point
in
their
journey,
it's
actually
really
critical.
They
can
do
that
because
they
will
approach
us
about
things
which
can
go.
Oh,
we
can
improve
that
we
can
create
a
ticket
on
the
backlog
and
dig
into
that.
C
So
we
kind
of
need
that
level
of
information
right
now.
One
of
the
other
big
bits
which
I
touched
from
there
was
where
possible,
dog
fooding
what's
happening
so
for
us.
We
make
sure
that,
although
we're
not
working
on
the
features
which
are
going
towards
the
customer,
we
make
sure
that
any
infrastructure
is
code,
any
pipelines
any
and
custom
tooling
we're
writing
goes
through
the
same
process.
It
all
has
to
go
through
the
same
kind
of
environment
release
process.
C
It
has
to
go
through
the
same
static
analysis,
so
we
kind
of
we're
experiencing
it
as
much
as
we
can,
and
the
final
big
thing
is,
I
found
pairing
with
people
is
really
powerful.
So
if
we
know
that
there's
a
feature
which
is
going
to
be
coming
up,
which
is
going
to
like
we
had
one
recently
about
introducing
a
kubernetes
operator
to
help
scale
up
some
of
our
environment.
C
So
we
were
writing
the
operator
code
because
we
were
really
familiar
with
that
feature:
team
we're
working
on
the
net
code
and
we
also
have
some
new
infrastructure.
We
had
to
bring
as
part
of
this
so
actually
pairing
on
that
really
closely
exposed,
so
much
pain
such
as
simple
one.
How
do
I
write
and
test
against
the
kubernetes
api
locally?
C
Well,
there's
so
many
options
you
can
use
for
doing
that
from
you
know,
mocks
of
it
all
the
way
through
to
running
a
full
kubernetes
environment,
locally
and
so
actually
being
able
to
capture
that
information
has
been
the
biggest
part.
Now,
we've
kind
of
beginning
to
get
information.
We've
got
that
very
close
relationship
with
the
software
engineers
which
we
work
with.
C
We
can
now
collaborate
on
improving
it.
So
I
know
one
of
the
senior
software
engineers
is
really
looking
at
using
scaffold
and
kind
at
the
moment
to
improve
the
local
developer
experience,
which
is
something
we've
experimented
with
previously,
but
there
wasn't
enough
familiarity
in
the
wider
team
and
to
make
it
work
so
he's
now
taking
that
on
board
of
something
he's
working
on
and
that's
great,
because
we
can
collaborate
on
that
and
it's
not
necessarily
us
owning
that
whole
process
and
then
trying
to
throw
it
over
the
wall
or
trying
to
teach
them.
C
It's
actually
something
we
can
do
in
peril
and
I
think
that's
one
of
the
biggest
things
when
you
actually
do
start
improving
the
local
dev
experiences,
finding
developers
who
can
or
finding
teams
who
can
be
kind
of
evangelists
for
what's
coming
in
and
will
really
adopt
it
and
really
will
help
drive
it
in
a
wider
community
as
well
by
being
involved
in
it
and
showing
it
to
people.
So.
A
B
B
But
even
the
new
project
like
check
on
chains,
which
is
the
one
that
signs
releases,
for
example
like
tektron
chain
signs,
its
own
releases
using
touch
and
chain
so
like
having
that
kind
of
folding
and
getting
feedback
back
from
using
your
own
software,
has
been
really
helpful
in
our
use
case.
As
a.
A
B
A
B
A
few
times
like,
if
they're
like
a
new
contributor
who
needs
guidance
on
something
they're,
not
familiar
with
a
particular
part
of
the
stack
and
therefore
can
reach
out
to
one
of
us
owners
of
any
of
the
tech
trend,
projects
to
get
guidance,
or
at
least
some
help
to
like
get
a
jumping
point
off
where
they
can
continue
to
make
their
contributions.
So
many
of
the
times
that
I've
seen
pairing
work.
A
C
So
it's
not
something
we
I'd
say,
not
something
we
do
to
a
great
deal
at
the
moment,
although
I
have
seen
success
with
it
in
other
organizations-
and
you
know
I
know-
we've
had
chats
through
the
end
user
council
around
other
places
which,
using
its
great
success,
what
we
have
been
exploring
at
the
moment-
and
this
has
come
from
being
driven
by
one
of
our
senior
software
engineers.
Who's
also
kind
of
taking
ownership
of
more
of
a
software
architecture
is
leveraging.
C
Some
net
features
around
doing
api
testing,
so
spinning
up
a
kind
of
shim
of
the
api.
In
order
to
do
testing
again,
I
think
that
would
be
very
powerful
for
what
we're
looking
to
do
at
this
moment
in
time.
But
this
whole,
the
actual
testing
piece,
gets
really
interesting,
because
you
know
standard
mocking
can
be
very
powerful.
You've
also
been
got
contract
testing,
which
some
people
looking
to
utilize,
particularly
microservices
for
creating
those
contracts
between
them
and
being
able
to
have
those
kind
of
independent
releases,
but
it
is.
C
It
is
a
time
sync
and
I
think
it's
very
important
time
thinking
a
very
valuable
one,
but
trying
to
trying
to
understand
where
to
invest
testing
effort.
I
think
be
quite
difficult
because
you
do
run
the
risk
of
having
a
large
amount
very
time,
time-consuming
tests
which
don't
necessarily
actually
provide
you
much
insight
into
what's
happening
in
the
code.
C
C
But
that's
one
of
the
big
things
is
for
me.
A
successful
testing
strategy
has
to
enable
it
to
be
done
locally.
You
might
run
a
more
intensive
version
of
that
as
part
of
a
release
process
you
might
instead
of
using
mocks
or
simulators,
you
might
use
actual
services
and
physical
hardware
during
that
process.
But,
ideally
you
want
as
much
of
that
to
be
able
to
run
locally
so
that
developers
can
have
all
software
engineers
can
have
a
sense
of
ownership
of
it.
They
can
work
on
the
test,
while
they're
working
on
the
code.
C
They
can
work
with
if
they've
got
qa
functionality
on
having
the
higher
level
tests
live
alongside
that,
and
they
can
run
through
it
locally
when
there
is
an
issue.
This
becomes
particularly
important
from
my
view,
for
if
you
run
into
problems,
things
like
being
able
to
use,
get
bisect
to
be
able
to
run
through
a
set
of
commits
and
be
able
to
run
a
test
suite
against
it
locally
and
can
become
really
powerful
as
a
way
to
kind
of
debug
where
something
was
introduced.
A
Okay
and
I'm
gonna,
maybe
switch
stack
a
bit
and
just
tackle
the
big
aspect
of
technology,
debt
or
legacy,
and
it
fails
like
these
days.
Things
are
moving
so
fast,
like
people
are
building
amazing
platforms
like
techton,
and
even
if
you
stand
still,
you
end
up
falling
behind,
because
everything
is
changing
like
it
feels
like
everybody
has
to
get
really
good
at
constantly
refreshing
their
platforms
and
improving
that,
and
how
do
you
go
about
like?
Do
you
have
a
strategy
for
reviewing
those
architectural
decisions
looking
at?
A
C
Today,
yeah,
I
I
I
think
you
can
come
up
with
a
lot
of
strategies
for
it,
but
it
depends
on
what's
driving
it
ideally
and
what
we've
kind
of
got
at
igs,
which
I
think
is
going
to
be
successful
for
a
time
at
least
we'll
see
if
it
is
still
successful.
If
we
get
larger
people
being
very
open
when
there's
problems
so
we'll
review
technology,
not
necessarily
on
we've
made
some
decisions,
we
want
to
change,
but
we
are
building
kind
of
a
list
of
known
pain,
points
of
loan
snags.
C
We
have
tickets
in
the
backlog,
for
I
think
we
changed
the
name,
but
essentially
engineering
pain
points
would
be
the
short
version
of
it
and
we
have
regular
architectural
reviews
where
we
go
through
things
like
the
adrs
and
if
ones
need
to
be
reviewed
or
need
to
be
superseded.
We
can
mark
that
in
a
very
lightweight
way.
These
are
all
just
very
simple
text
documents
and
more
generally,
though,
if
you're
in
that
position,
it
can
be
really
powerful
because
you're
able
to
drive
okay,
we
know
we've
got
these
pain
points.
C
We
know
it's
kind
of
having
this
kind
of
impact.
On
us,
let's
start
doing
a
review
and
see
what
else
is
out
there
and
that's
the
best
position
I
think,
they're
being
is
just
continually
look
at
what
your
pain
is.
If
you
can,
then
it's
open
source
work
with
the
open
source
community
either
contribute
to
it
or
raise
it
as
an
issue.
Try
and
work
with
them
to
extend
it.
C
But
what
you
often
see
is
things
have
gone
years
without
being
reviewed,
things
have
got
quite
large.
There
is
sometimes
maybe
a
lack
of
direction,
or
maybe
a
lack
of
insight
into
what's
happening
and
in
most
situations,
you're
often
a
position
where
you
have
to
fight
for
review,
and
that
tends
to
be
more
batch.
So
you
know
every
five
years
or
so
you'll
see
some
kind
of
big
digital
transformation
or
some
kind
of
refresh,
and
that's
not
necessarily
a
terrible
thing.
C
When
organizations
get
to
a
certain
size,
particularly
non-technology
focused
ones,
that's
how
they
do
it,
that's
how
they
budget
for
it
and
that's
how
they
plan
around
it.
But
in
that
situation,
it's
more
important
to
coming
into
that
know
what
you
want
to
address
and
be
able
to
like
pull
people
and
get
an
idea
of
okay.
What's
our
pain
points
across
the
board,
we're
going
to
be
doing
a
lot
of
changes
and
once
maybe
getting
contractors
to
help?
C
How
do
we
at
that
point
put
in
a
vision
so
that
we're
going
to
be
content
and
happy
for
the
next
years
and
we
can
make
small
incremental
improvements
to
it.
So
I'm
quite
lucky
that
that's
not
where
I'm
at,
because
that's
always
challenging
to
deal
with
and
both
of
them
have
their
kind
of
pain
points
and
also
their
advantages
as
well.
A
Awesome
and
I
think
yeah,
just
from
our
perspective
as
the
continuous
delivery
foundation,
I
think
we
see
that
as
our
role
to
just
try
and
get
the
information
out,
have
people
like
yourself
come
along
and
share
their
stories,
so
there's
opportunities
for
people
to
pick
up
how
people
are
approaching
it.
It
looks
like
drop,
come
and
talk
about
all
the
great
things
happening
in
techton,
so
at
least
we
build
up
that
awareness
of
where
things
are
headed
and
what
exists
out
there
so
yeah
now.
A
This
has
been
a
really
great
discussion
and
yeah
thanks
everybody
for
joining
us.
We
do
have
a
lot
of
different
communities
which
you
can
stay
part
of.
We
have
the
end
user
council
that
discusses
specific
stories.
We've
got
tekton
communities
and
also
efforts
around
interoperability
with
the
special
interest
group
on
interoperability,
so
just
to
wrap
up.
B
So
in
this
case
like
what
is
environment,
what
are
the
tools
that
you
need
and
like?
How
do
they
all
work
together
to
sell
for
your
customers
based
on
their
needs,
so
yeah,
so
one-size-fits-all
is
a
practical
and
interpret.
Interoperability
is
quite
key
in
the
in
the
modern
technology
choices
that
you
make.