►
From YouTube: Beaming Ortelius- Trends in CD
Description
Brian Dawson joins the Ortelius team to discuss new trends in continuous delivery.
A
So,
thank
you,
everyone
for
joining
us
today
on
the
hoteliers
podcast
and
today
we
are
talking
about
cicd
trends
and
thank
you
very
much
sasha
for
joining
me
today
and
thank
you
very
much
brian
for
also
for
joining
me.
So
we
are
living
in
a
different
part
of
the
world.
I
am
living
in
the
salamat,
pakistan
and
sasha
in
the
cape
town
and
brian.
Tell
us
where
you're
from.
B
A
Yes,
absolutely
so
let
me
introduce
myself
to
my
audience.
First,
my
name
is
sam
softer
and
I'm
a
developer
advocate
at
van
clouds
recently
joined
the
company
and
also
a
traffic
ambassador
and
the
cdf
foundation
ambassador
and
recently
I
they
gave
me
this
title.
I'm
really
excited
about
that
and
now
sasha
it's
your
turn.
Introduce
yourself
now.
C
B
Yes,
yes
and
sasha.
Thanks
for
that
introduction,
you
probably
have
no
shortage
of
people
that
need
your
services
at
this
time.
So
so
I've
recently
moved
over
from
the
linux
foundation
to
join
a
company
called
ripple
where
I'll
be
helping
work
with
partners
to
drive
new
ca
use
cases
around
blockchain,
cryptocurrency
and
tokenization.
B
A
Yes,
absolutely
absolutely
that's
a
wonderful
guest
today,
if
we
have
so,
we
can
also,
as
as
one
of
the
question
as
we
as
we
have
in
the
mind,
and
it's
first
of
all.
Thank
you
very
much
for
joining
me
because
some
of
them
people
are
so
early,
some
of
those
I'm
so
late.
So
we
are
living
in
the
time
zone,
challenges
and
it's
been
very
difficult
for
most
of
the
time.
A
But
let's
drive
the
conversation
forward
like
tell
us
about
the
cic
retrend
like
when
I
joined
in
2016
in
the
company
called
in
here
in
pakistan.
So
there
is
a
trends
going
on.
You
just
build
out
the
code
in
your
in
your
machine.
Then
you
push
it
up
to
the
next
stage.
That's
called
the
testing
stage
and
then
you
eventually
move
the
deployment
stage
and
that's
actually
another
machine.
A
So
with
the
machine
challenges
you
have
built
your
corner,
your
own
laptop
and
when
you
test
it
out
to
the
develo
testing
team,
there
are
so
many
weird
things
happening
and
you
are
trying
to
fight
with
each
other.
Is
that
this?
My
fault?
Isn't?
This
is
yes
fault,
it's
actually
responsible
for
that
fault,
and
also
when
you
deploy
to
the
production.
It's
actually.
Another
thing
is
another
machine
and
that's
I
have
grown
up
so
tell
us
about
how,
because
you
have
a
wonderful
experience.
It's
been
in
this
industry.
B
B
Integrating.
I
was
off
on
on
a
bunch
of
other
things.
I
maybe
traveled
to
consult
with
the
developer,
started
on
a
new
coding
project
and
then
the
process
of
trying
to
work
through
his
integration
issues
when
he
tried
to
bill
and
compile
the
code
took
significantly
more
time,
because
my
mindset
I
was
out
of
context,
I
didn't
have
history
to
what
I
was
doing.
B
Let's
use,
centralized
shared
and
automated
build
processes
to
find
problems
in
code,
whether
that
be
quality
issues,
security
issues
or
other
unintended
implementations,
as
close
as
possible
to
when
they
were
introduced,
because
when
we
do
that
the
cost
of
fixing
them
is
extremely
cheaper
and,
let's
just
simply
say,
and
of
course,
sasa
time
you
I
I
know
you
know
this,
but
you
know
that
establishing
of
a
feedback
loop
in
the
continuous
integration
are
strictly
build.
Process,
find
problems
fast,
closer
to
introductions.
You
can
fit
some
more
cheaply
with
cd.
A
C
A
The
deployment
phase,
the
testing
team,
is
ready
to
move
the
code
into
the
production
and
the
production.
The
automation
engineer
is
actually
using
the
languages
that
actually
developer
and
testing
team
don't
know.
So
I'm
wishing
on
that
time
like
if
we
have
a
universal
something,
a
universe
that
we
can
speak
up
to.
B
I
think
we're
starting
to
get
there.
You
know,
I
look
if
I
think,
if,
if
some
of
us
software
vendors
stop
fighting
to
make
markets
and
introduce
new
terms-
maybe
it's
stabilized,
but
you
know
I
do
think
continuous
integration
and
continuous
delivery
and
some
of
the
terminology
and
and
and
and
sort
of
idioms
built
around
that
do
start
to
set
a
stage
for
common
language
right.
B
I
think
I
think
we
we
how's
it
going
to
say
it
is,
but
we
also
have
to
kind
of
tear
down
some
organizational
and
cultural
barriers,
and
I
think
we're
starting
to
see
that
happen.
Really
continuous
integration
and
continuous
delivery
focused
on
a
shift
left
and
was
very
much
a
developer
delivering
process
right.
I
speak
to
operations
and
qa
professionals
that
that
say
we're
talking
about
cd
and
we're
talking
about
devops,
but
the
team
never
involved
us
in
the
discussion
now.
B
B
We
can't
just
assume
we're
going
to
reliably
push
that
from
a
developer's
seat.
We
have
to
start
to
engage
the
downstream
teams
early
on
and
you
know
risk
to
throw
it
say.
So
we
can
meet
our
goal
of
delivering
quality,
secure
software
rapidly
reliably
and
repeatably,
and
you
cannot
do
that
at
scale
simply
sitting
in
a
developer's
seat.
C
B
C
I
wanted
to
just
kind
of
spin
off
what
you
were
saying
there,
because
we're
outsourced
to
a
client
who's
going
down
this
going
on
this
journey
right
and
it's
the
biggest
challenge
is:
how
do
you
change
this
culture?
How
do
you
educate
the
people
that
you
interact
with
every
day
from
the
developers
to
the
guys
who
are
building
the
platform
to
the
guy
to
the
business
people?
Who
are
the
managers
or
your
project
managers?
C
Where
what
would
you
recommend
a
good
starting
point
is
to
to
help
a
company
use
embarking
on
this
journey?
You
know
to
start
a
good
place
to
start,
because
I'm
finding
the
communication
thing
and
trying
to
get
everybody
aligned
is
the
biggest
challenge
and
giving
sort
of
an
estimation
of
how
long
things
could
take
right.
B
C
B
No
I'll
answer,
look
you
really
you
I
mean
you
said
it.
You
wrapped
the
answer
in
there
you
you,
you
start
and
I
can
be
more
specific,
but
generally
you
you
start
with
a
base
level
of
knowledge
building
and
a
base
level
of
team
building,
right
and
oftentimes.
I
talk
about
this
devops
trinity,
people
and
culture
process
and
practice
tools
and
technology
right.
You
will
not
be
successful
in
delivering
rapidly
reliably
repeatably
at
scale
unless
you
dress
all
of
those
areas
and
so
yeah.
B
I
think
you
have
to
train
people
on
the
technology
that
they're
going
to
be
using.
You
have
to
begin
to
bring
people
into
the
the
kind
of
education
of
and
definition
of
the
process
of
practice,
and
you
have
to
take
some
steps
to
build
sort
of
a
true
culture
and
like
we
like,
you
know,
we
focus
on.
Do
it
iteratively?
B
It
won't
be
big
bang,
but
you
do
need
to
be
thinking
about
all
those
things
and
I
would
beg
to
say
that
managers,
engineering
leaders
and
product
managers
also
need
to
be
aware
that
if
they
account
for
some
of
those
steps
up
front
which
may
cost
some
time
they're
going
to
be
able
to
move
faster
later,
that's
you
know
my
opinion
and
it.
I
know
you
guys
have
a
similar
level
of
experience.
A
Yes,
absolutely,
I
think
you
drive
the
wonderful
conversation
forward
here
for
us
like,
like
I'm
like
the
communication,
is
one
of
the
hardest
challenge
like
as
we're
telling
like.
First,
you
have
to
understand
what
are
they
communicating
with
like
with
the
rise
of
the
container?
We
actually
come
up
to
the
point
where
everybody
able
to
understand
what
actually
they
are
talking
about,
like
the
project
manager
is
actually
talking
about
that.
A
We're
talking
about
containers
like
also
we're
talking
about
in
the
the
development
team,
the
testing
team,
the
devops
team,
the
automation
team,
they're
all
talk
that
they
know
the
language
they
are
using
at,
but
and
you
have
previously,
you
want
to
have
a
t-couple
system,
not
everything
with
an
init,
because
it's
it's
a
year
of
refactoring.
If
you
do
that,
and
people
are
now
moving
to
the
microservices
architecture,
and
that
is
actually
because
of
the
container
ecosystem
that
is
very
simple,
very
easy
to
deploy
with
and
the
same
language
construct
we
are
using
at.
A
A
That
the
container
is
actually
a
part
of
the
linux
ecosystem,
you
have
to
be
comfortable
learning,
linux
and
linux
has
other
languages
and
windows
have
other
languages
called
code
construct.
So
you
need
to
be
able
to
understand
how
the
linux
work,
how
the
container
ecosystem
evolve
and
also,
I
think,
when
we
move
forward
like
now
as
a
trend
is
actually
the
container,
but
previously
we
don't
able
to
talk
about
pull
and
pushes
push
pull
push
pull.
A
A
To
understand
about
it,
so
I
think,
because
I
think
sasha
and
for
you
I
think
you
have
a
broader
experience,
really
relative
to
mind
so
tell
us
about
like
we
have
tools,
we
have
technologies,
we
have
everything
set
up
like
learning
resources
amount
of
the
learning
resources
right
now
we
have,
we
don't
have
in
the
previous
time.
That
is
another
good
point.
Also
there
are
foundations
open
source
projects
like
we
have
a
rotaries
community
that
working
with
the
microservices
and
these
kind
of
stuff.
So
I
think
right
now
is
the
collaboration.
A
The
communication
is
each
rather
than
is
easy
right
now,
rather
than
it's
more
complex
or
difficult
to
have
hurdles
communicating
with
the
people,
so
I
think
we're
moving
in
a
good
direction,
but
I
think
it's
need
to
be.
We
have
to
be
stay
consistent
because
we
don't
have
consistency,
it's
really
tougher
hill
to
climb
about
it
and
also
tell
us
about
like
where
some
of
the
mic
some
of
the
organization
that
came
up
to
the
devops
time
on
the
time
that
just
thinking
about
the
devops-
and
there
are
two
three
new
terminologies
come
into.
B
Well,
yeah,
it's
it's!
Oh
god,
there's
there's
so
much
they're!
Saying
first
I'd
say
you
you
you!
We
are
one
of
the
thoughts
you
had
there
that
that
really
kind
of
is
the
challenge
of
of
monoliths
or
highly
coupled
systems.
Is
it's
almost
like
trying
to
work
one
of
those
tile
games
where
to
move
a
tile
over?
You
have
to
slide
another
or
think
a
rubik's
cube
right
every
time.
I
turn
one
to
get
a
square
in
another
place,
I'm
affecting
something
else,
and
you
get
this
cyclical
effect.
B
B
The
rubik's
cube
comes
back
in
right,
because
now,
when
I
implement
a
new
tool
or
modernize
on
the
left
hand,
side
that
may
have
a
downstream
impact
on
what
we're
doing,
in
terms
of
our
deployment
automation,
how
we're
deploying
our
containers
now
I'll
kind
of
get
to
the
the
technologies
and
how
they
help
a
bit
more
of
that
in
a
minute.
But
again,
you
know
like
a
rubik's
cube.
B
Look
tools
are
going
to
change,
technologies
are
going
to
change,
process
is
going
to
change,
and,
yes,
we
have
solutions
like
immutable
environments
right
in
containers
and
ways
that
we
can
sort
of
democratically,
arguably
orchestrate
our
cloud
native
deployments
with
kubernetes,
but
that
does
not
negate
the
need
for
tight
coordination
between
the
participants
in
the
software
development
and
delivery
life
cycle.
I
think
I
missed
your
questions
about
trends
there.
A
No,
no,
I
think
it's
a
good
job.
Wonderful,
but
like
I'm
just
talking
about
like
some
of
the
organization
they
just
heard
about
the
term
devops
and
when
they
try
to
implement
devops,
they
see
the
new
language
came
into
the
picture
like
the
container
get
offs
orchestration
and
they
are
figuring
out.
How
do
we
able
to
understand
all
those
in?
Is
there
a
way
to
overcome
this
challenge?.
B
Kind
of
talk
that
I
used
to
give
is
understand
where
you
are
figure
out,
where
you
want
to
go,
then
figure
out
how
to
get
there.
That's
where
you
determine
does
application
of
scrum
principles
or
application
of
microservices
architectures
get
ops
principles
for
the
delivery?
Do
those
make
sense,
but
let's
also,
as
those
trends
emerge,
not
just
evaluate
and
discover
on.
Where
are
we?
Where
do
we
want
to
get?
How
do
we
get
there
alone,
but
do
it
with
your
other
stakeholders?
Do
it
with
the
operations
team,
do
it
with
your
sres
and
so
yeah?
B
That
would
be
my
take
they're
all
important
trends
in
the
market,
the
ones
we've
leaned
on
microservices
cloud
native
kubernetes
using
containers
but
they're,
not
necessarily
not
necessarily
every
single
one
of
them
is
applicable
to
what
your
problem
space
is.
So
don't
assume
that,
as
we
here
talk
about
trends
in
devops
that
it
automatically
means
it's
something
you
need
to
go
out
and
apply
to
your
team.
A
A
A
B
Is
there
a
standard,
any
standard
for
what
tools
to
include
in
the
ci
cd
process?
That's
interesting.
What
what
I
tend
to
do
is
manage
and
you're
starting
to
see
this
with
platform
teams
is
manage
your
ci
cd
tool
selection,
almost
as
you
would
manage
product
requirements
right,
so
even
if
you're
the
consumer,
building
it
out
you're
in
an
organization
where
now
the
term
we're
using
to
introduce
new
emerging
terms,
is
your
platform,
ops,
team
and
they're
going
to
making
a
decision
is
you're
always
gonna
have
to
rank
some
trade-offs
against.
B
B
If
this
person
making
this
request
was
in
the
dev
team,
well
think
about
how
it's
going
to
impact
downstream
people,
your
selection
of
ci,
cd
gather
their
requirements,
put
them
in
a
matrix,
identify
what
I
would
say
proven
tools,
if
not
also
popular
tools,
tools
with
it
with
a
with
a
with
a
couch.
An
open
source
are
going
to
offer
you
a
lot
of
favors
and
then
just
go
through
the
analysis
right.
But
what
I
will
say
is
put
a
time
limit
on
it,
because
you're
never
going
to
find
everybody's
perfect
solution.
B
Okay
and
I'd
like
to
be
able
to
say
that
you
know,
thankfully,
because
microservices
have
inherent
decoupling,
that
constant
stream
of
multiple
highways
going
to
the
same
destination
mitigates
your
risk
for
failure
and
yeah
what
it
does
is
it
isolates
it
right.
It
doesn't
necessarily
mitigate
it.
You
know
yes,
a
broken
component
is
less
likely
to
bring
down
the
whole
system,
but
you
could
use
a
little
critical
service.
So
one
is
I
I'd
say
going
back
to
the
earlier
question:
is
that
is
going
to
help
drive
your
tooling
choices
right?
B
You
have
distinctly
different
needs
for
what
your
tooling
capabilities
are
when
you're
managing
10
20
50
different.
You
know
in-house
services
that
compose
your
system
or
application
plus
others.
So
you
know
the
the
the
the
and
I
guess
it
would
get
too
detailed
to
get
into
specific
practices,
but
I
would
say
one:
you
should
be
looking
at
a
way
to
dynamically
capture
and
track
a
canonical
record
of
your
micro
services
and
the
status
of
those
services.
B
You
should
be
able
to
integrate
some
level
of
of
common
ci
and
cd
across
those
systems,
so
at
any
given
time
it's
easy
to
see
where
they
are
in
the
delivery
process,
track
versions,
track
deployments
understand
where
they're
used
I'd
say
you
know
again
using
a
a
bit
of
a
cliche
term
now
is.
Is
it?
Is
that
much
more
important
when
you
have
those
multiple
micro
services
to
have
a
macro
view
of
your
software
supply
chain?.
A
Yes,
absolutely
absolutely
wonderful
points
learned
a
lot
due
to
the
discussion
and
also,
I
think
the
point
you
raise
here
like
people
are
working
on
some
set
of
core
technologies,
and
you
don't
have
enough
time
to
see
what
people
or
other
talking
in
the
ecosystem,
that,
where
community
and
crowd
and
learning
in
public
means
comes
in,
like
you
were
talking
about
just
one
tool
and
the
community
is
talking
about
the
kubernetes
orco
cd,
the
githubs.
But
you
are
just
into
the
market
of
devops.
A
I
think
for
the
people
who
are
just
in
the
market
they
can
do,
is
they
can
go
to
the
communities,
the
open
source
communities
where
they
can
learn
more
more
cloud
native
or
github's
languages
or
the
strands
languages?
I
would
rather
call
it
and
that's,
I
think,
hoteliers
open
source
project
is
like
one
of
our
constructors
to
learn
and
educate
the
community
around
the
new
open
source,
tooling,
the
micro
services
architecture,
the
cicd
systems,
and
I
think
anybody
who
are
listening
or
watching
us.
A
There
is
a
git
up
link
available
for
you
on
the
screen,
go
ahead
and
join,
join
our
community
or
the
discord
server
with
sasha
me.
We're
always
talking
about
it,
one
of
our
other
friends
from
the
ortelius
office
hour.
Sergio
is
also
joining
thanks,
sergey
for
joining
us
today,
and
we
can
talk
about
all
these
things.
We
want
to
have
your
question
going
and
we
can
make
your
life
easier
as
a
ci,
cd
or
the
automation
engineer,
automation,
expert,
so
I
think
it's
been
living
in
the
public
and
asked
question.
A
B
Yeah
well,
we
are,
I
heard
two
questions
in
there
right.
What's
going
to
happen
next
and
I
do
think
look.
There
are
multiple
components
of
kind
of
modern
software,
development
and
delivery.
We
mentioned
some
of
those
process,
get
ops,
architecture,
micro
services
right
some
practices,
observability
right.
All
of
these
things
are
going
to
kind
of
continue
to
progressively
mature.
So
we're
not
done
with
the
maturation
of
of
any
of
this.
B
But
what
I
really
see-
and
I
see
the
ortelius
project-
doing
as
well
as
a
number
of
people
in
the
microservices
and
observability
space-
is
we
still
have
to
complete
the
promise
of
a
continuous
feedback
loop
end
to
end
right,
I
think
oftentimes.
When
we
talk
about
ci
cd,
we're
doing
local,
optimization,
localized,
optimization,
we
establish
a
feedback
loop
within
dev
between
dev
and
test.
B
We
bring
in
the
sre,
that's
supposed
to
kind
of
establish
a
feedback
loop
kind
of
in
between
the
groups,
but
we
still
strive
to
get
a
continuous
view
on
what
we're
making
where
it
was
used,
how
it
was
deployed
who
used
it,
how
it
performed.
So
we
can
bring
that
back
and
collectively
improve.
So
with
all
of
that
I'd
say,
I
see
a
continued
growth
of
microservices,
especially
enterprise
adoption,
where
it
can
be
particularly
hard,
but
where
it
also
has
a
particular
level
of
value.
I
see
our
competency
increasing
there.
B
But
we're
going
to
start
to
see
with
that
tooling
is
observability
is
going
to
start
to
focus
more
on
what
the
user
experience
is.
Meanwhile,
we're
going
to
start
to
surface
the
intelligence
and
analytics
of
observability
more
to
the
developer
right,
and
I
think
this
also
speaks
to
what
ortilius
is
doing
right.
We
need
to
understand
what
our
services
supply
chain
looks
like
right,
what
our,
what
our
health
is-
and
it's
not
just
your
sre-
it's
not
just
your
architect.
B
It
helps
for
the
for
the
for
the
engineering
leads
and
developers
building
those
services
and
the
systems
that
use
them
to
have
that
same
view.
So
long
story
short.
We
have
to
continue
to
build
that
continuous
feedback
loop.
I
would
recommend,
like
we,
like,
we
said,
go,
spend
time
in
the
artillious
community.
Go
look
at
some
of
the
landscapes
out
there
with
cncf
or
with
open
software
security
foundation,
where
they're
kind
of
looking
at
supply
chain
also
been
working
with
and
recently
had.
B
C
Such
a
good
discussion
and
I've,
I
mean
I've
learned
so
much
myself.
I
mean
all
the
things
that
you
spoke
of.
Brian,
are
the
challenges
that
I
I'm
facing
in
my
in
my
own
work.
You
know
and
wow
I've
got
such
pills
of
wisdom
there.
So
thank
you.
So
much
and
oh,
it's
been,
it's
been
an
awesome.
Awesome
chat
so
far.
I
hope
we
can
do
this
again.
C
C
A
A
Server,
go
to
the
hoteliers.io
website
and
join
in,
like
we
have
all
day
all
along
this
discussion
going
on,
and
I
learned
a
lot
like
brian
is
first
time
I
I
talking
to
you
on
the
podcast
hope
to
have
you
again
in
the
future
as
well,
because
the
lesson
I
learned
is
so
it
has
so
many
values
in
it,
and
I
want
to.
I
want
to
establish
a
learning
and
consistent
way
of
learning
the
new
technologies,
a
challenge
like
I.
A
So
in
this
point
I
think
people
who
are
watching
or
listening
to
us
get
a
valuable
insight
from
the
brain
and
if
you
need
any
other
discussion,
we
want
to
see
what
next
we
covered
in
the
hotelier
support.
Course,
in
the
in
the
discussion
like
do
let
us
know,
and
we
will
we
will
continue
some
monetary
chat
and
we
will
definitely
avail
to
go
on
this
broadcast
in
the
future.
So
thank
you,
everyone
for
joining
us
and
on
the
rotaries
podcast.