►
From YouTube: GitOps keeps focus on product, not on infrastructure | Jakarta Tech Talks | April 13, 2021
Description
Development teams spend time on a lot of things other than their product. They manage infrastructure, DevOps and integrations, and even create staging servers so that an external agency can test out your sweet new redesign. Maybe it’s not even just one site to worry about, but a whole fleet of applications that need to be kept in-sync, secure, and up-to-date, all while sticking to a release schedule.
No one has that much attention or experience to manage it all, and it’s a lot to ask of them to keep up with.
In this demo you’ll get a view of how the same team solves these problems when their project is hosted on Platform.sh. In short, they don’t need to think much about them. The project didn’t move anywhere - it’s in the same GitHub repository the team is used to working with - but now it’s got some new tools and assurances that weren’t there before with only a few short files needed to configure it all. We’ll cover:
Infrastructure-as-code: committed and clear infrastructure for all collaborators, where new services and upgrades are single character commits.
CI: pull requests become live environments as soon as they’re opened, even for upgrades to infrastructure.
Production data: a staging server for every proposed change, that’s not just a clone of production code, but also infrastructure and production data that the application really needs to have available for reliable testing prior to merges.
Access: collaborators can test on isolated copies of production as easily as branching.
One or many: control extends from a single application to a full fleet just the same.
Presented by Chad Carlson
Get Social!
Website: jakarta.ee
Subscribe: https://www.youtube.com/user/EclipseF...
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE
Want more great Eclipse Community webinars? Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtalks
A
Hello,
everybody
welcome
to
another
jakarta
tech.
Talk
joining
us
today
is
chad
carlson
from
platform.
Sh
presenting
git
ops
keeps
focus
on
product,
not
on
infrastructure.
Chad
is
a
devrel
engineer
from
platform
sh
and
an
all-around
experimenter
outside
of
work.
You
can
find
him
writing
cooking
or
trying
to
learn
yet
another
programming
language
without
any
further
delay.
Let's
turn
it
over
to
chad
and
discuss
how
to
spend
more
time,
developing
products
and
less
time
managing
complex
infrastructure
chat.
It's
all
yours.
B
Thank
you
very
much.
Hi
everyone
yeah,
my
name
is
chad
carlson.
Thank
you
very,
very
much
for
having
me
title
of
my
talk
is
get
up,
keeps
focused
on
product
and
not
on
infrastructure,
I'm
hoping
to
get
across
some
of
what
we
do
with
platformer
stage
and
how
it
might
help
you
with
your
java
product
projects.
B
B
B
So
if
we
have
a
project,
we
want
the
code
describing
that
application
to
be
committed.
Obviously
we
want
to
leverage
git
and
everything
that
we
do,
but
another
component
of
that
is
leveraging
git
that
we're
already
using
to
define
things
like
what
does
our
infrastructure
look
like
and
can
that
be
version
controlled
and
environment
and
branch
dependent
in
the
same
way
that
a
piece
of
code
can?
And
so
that's
what
we
try
to
apply
at
platform
where
a
platform
is
a
service
provider?
B
You
don't
have
to
deal
with
the
configuration
on
some
of
these
big
infrastructure
service
providers
and
we
provide
a
a
level
of
abstraction
by
which
you
can
abide
by
this
infrastructure
as
code
idea
to
include
definitions
of
your
infrastructure
as
part
of
your
code
base,
along
with
the
code
itself,
all
the
definitions
of
your
dependencies,
so
that,
as
you
create
new
environments
and
you
go
through
whatever
pipeline,
you
define
you
have
this
final
build
image
that
is
defined
for
that
environment.
It
can
be
passed
around
to
production
when
you
perform
your
merges.
B
So
it's
a
lot
of
extra
visibility
and
it's
a
lot
of
increased
dependability
and
repeatability.
That
comes
from
this
approach
and
something
that
we
like
to
address
is
at
the
end
of
your
build,
which
I'll
show
in
a
little
bit
here,
because
we
have
infrastructure
code
base
and
dependencies
all
defined
into
this
final
build
image.
When
we
merge
something
into
production,
it's
going
to
be
that
identical,
build
image
that
you're
actually
deploying
to
your
live
site
into
your
domain.
B
B
So
obviously,
you're
going
to
have
some
commit
history,
where
you
can
see
exactly
who
made
what
change
where
and
when
for
which
commit.
But
we
can
extend
that
same
concept
as
we
use
it
to
build
out
our
pipeline
to
do
things
like
who
triggered
which
activity
when
which
can
be
a
push,
or
it
can
be
a
environment
variable
setting
events.
All
of
these
things
get
tied
into
hooks
and
an
assortment
of
other
tools
built
on
top
of
git
that
we're
already
all
using
we'll
come
back
to
this
a
lot.
B
We
have
a
number
of
java
runtimes
php
node
go
whatever
it
is
that
you
might
need
whether
it's
for
your
principal
app
or
you're,
trying
to
create
something
a
little
bit
more
microservices
oriented
you
have
this
wide
selection
of
runtimes
for
it,
and
in
this
case
let's
say,
I'm
running
a
wordpress
agency,
but
some
kind
of
agency,
and
I
have
lots
of
sites
and
I'd
like
to
handle
a
lot
more.
Obviously
I
want
to
build
my
business
as
much
as
possible.
B
B
I
need
to
have
strong
testing
as
a
part
of
my
pipeline
for
each
of
this
each
of
these
sites,
and
I
want
to
be
able
to
quickly
test
changes
that
adding
or
updating
a
dependency
or
to
as
we'll
see
here
with
platform
changes
to
my
infrastructure
will
make
on
all
those
sites,
and
I
need
a
quick
way
to
create
new
environments
for
both
internal
and
external
collaborators.
It
makes
sense
that
I
want
to
be
able
to
delegate
a
an
environment
for
one
of
my
developers.
B
B
B
In
order
to
run,
I
need
to
be
able
to
sort
of
manage
them
on
on
a
larger
scale
of
of
directing
and
controlling
how
this
fleet
operates.
So
how
do
I
do
that?
I
could
learn
the
configuration
and
build
up
this
large
devops
tooling
around
this
problem
set
using
things
like
kubernetes
and
docker
swarm
and
circle
ci,
and
a
lot
of
integrations
to
get
pretty
close
to
this
ideal.
B
So
you're
going
to
have
potentially
expensive
developers
that
you're
going
to
need
to
hire,
who
are
very
knowledgeable
on
one
of
these
and
hopefully
extremely
knowledgeable
on
all
of
them,
so
that
you
can
keep
your
workflow
going
and
nobody
gets
in
anybody's
way
that
it's
not
a
difficult
task
to
apply,
updates
to
one
or
n
sites
across
that
fleet.
Or
for
you
to
do
like.
B
B
So
we
allow
git
to
control
how
environments
are
created
and
destroyed,
and
it's
where
we
observe
changes
in
in
our
infrastructure
and
we'll
see
some
examples
of
what
that
configuration
looks
like
in
a
second.
But
everything
gets
committed
alongside
the
application
itself
inside
the
repository,
because
it
becomes
just
as
much
a
part
of
the
app
as
the
code
itself.
So
this
is.
B
Let
me
minimize
this
quick.
We
have
a
post
on
our
blog
that
I'd
be
happy
to
share
the
link
with
in
the
chat
from
my
colleague,
larry
garfield,
about
this
topic
that
I
would
really
recommend
taking
a
look
at
if
you're
interested
in
what
our
approach
is
in
particular
and
there's
any
gaps
that
are
still
left
over
from
this
talk.
B
But
the
end
result
of
all
of
this,
the
desired
result
is
folding
all
of
the
buttons
and
dials
and
switches
and
know-how
to
control
the
application,
the
environments
and
even
scaled
up
more
to
this
fleet
of
site
to
make
a
change
on
git
on
a
branch
commit
and
push,
and
everything
is
sort
of
taken
care
of
with
a
reasonable
level
of
visibility
that
comes
with
it.
So
you
don't
have
to
build
any
of
this
pipeline
yourself.
B
Let's
see
what
that
looks
like
in
practice,
so
here
I
have
a
wordpress
site
again
that
is
on
my
own
github
account
is.
This
repository
is
tied
to
a
project
on
platform
at
sage,
so
on
that
repo,
we
only
have
a
master
branch
on
the
project.
We
have
only
a
master
environment
that
shows
that
front-end
site
right
there
shows
my
wordpress
site,
and
so
it's
mirrored
on
that
production
environment.
B
B
So
it's
going
to
be
an
exact
copy
on
this
new
environment,
and
so
what
this
environment
really
is
is
a
a
an
exact
copy
of
what
we
had
in
production,
but
it's
going
to
be
an
exact
copy
of
our
infrastructure
in
a
totally
isolated
environment
from
master
or
any
other
branch
or
pull
request.
That
happens
to
be
open.
B
So,
let's
take
a
look
at
some
of
this
configuration
file
because
it
can
be
a
little
bit
more
clear
when
you
see
that,
so
what
I'm
building
is
a
collection
of
containers
that
define
a
a
virtual
cluster
for
my
final
site.
It's
a
wordpress
site,
so
I'm
gonna
have
a
php
container
will
which
php
in
this
platform
at
file,
I'm
going
to
define
everything
that
has
to
do
with
that
php
container.
B
It's
going
to
have
a
name
that
allows
me
to
define
how
traffic
comes
into
that
container
and
how
other
containers
in
the
cluster
communicate
with
it
and
what
they
can
see.
If
anything
of
that
of
that
application.
Internally,
I'm
going
to
say
what
runtime
it's
going
to
use.
So
in
this
case
it's
php
74,
but
this
could
be
like.
I
said,
pretty
much
anything.
If
you
go
to
our
java
documentation,
you
would
simply
substitute
that
type
key
with
a
java
colon
14.
B
B
We
even
have
an
elixir
container
and
then,
after
that,
we
are
going
to
define
how
the
application
in
this
container
is
going
to
be
built
and
deployed.
So
this
is
a
a
fairly
simple
appeamo
file.
There's
not
much
included
in
its
build
step,
because
we
are
relying
on
the
dependency
definition,
so
in
php
we're
going
to
rely
on
composer
as
our
package
manager,
and
so
our
containers
automatically
detect
that
there's
a
composer
lock
file
inside
our
code
base
and
so
as
its
first
step
in
build.
B
B
B
I
think
that
that's
all
I
have
on
here.
We
can
go
back
to
that
sample
in
a
second,
but
I
think
you
could
probably
see
at
this
point
that
this
is
where
we
start
building
a
lot
of
the
assurance
of
our
builds
being
completely
repeatable
across
environments,
because
our
infrastructure
is
a
committed
thing,
just
like
the
rest
of
our
code
base.
So
any
branch
I
make
is
going
to
continue
to
have
a
php
74
or
a
java,
14
runtime
on
it.
B
B
B
B
B
Alternatively,
when
I
create
a
new
branch,
I
was
saying
that
you
get
all
of
your
infrastructure
configuration
and
your
code
base
in
any
of
these
child
branches,
but
we
treat
data
as
going
in
the
other
direction
in
this
case,
as
sort
of
an
extra
piece
of
tooling
on
top
of
git,
so
yeah
you
inherit
infrastructure
and
code.
You,
you
inherit
everything,
that's
committed,
but
you're
also
going
to
inherit
all
this
production
data
which
can
come
in
real
handy.
B
B
Here
is
exactly
what
I
was
talking
about
that
if
I
change
something
on
a
branch
inside
that
repository,
I
have
code
infrastructure,
configuration
and
dependencies
that
all
become
a
final,
build
image
associated
with
the
tree
id
for
git,
and
so
what
we
end
up
being
able
to
do
is
any
time
that
we
merge
something
into
production.
We
essentially
reassign
that
tree
id
to
master
and
reuse
the
build
that
we
already
made.
There's
no
new
thing
that
can
be.
B
They
can
act
unexpectedly
when
we
finally
merge
into
production-
and
I
think
that
this
is
where
expecting
a
read-only
file
system
really
becomes
an
important
point,
because
we
have
generated
lock
files,
we
have
infrastructure
committed.
We
have
all
these
things
that
that
rely
on
us
trying
to
to
to
put
together
this
final
environment
independent,
build
image
that
we
can
kind
of
pass
along
and
and
maintain
the
sort
of
assurance
on
top
of
git.
B
That
is
how
we
do
configuration
for
application
containers,
so
every
project
sort
of
gets
these
three
main
files.
This
app
yaml
file
a
root
cmo
and
services,
yaml
file,
so
the
same
way
that
we
define,
which
version
of
php
that
we
want.
We
can
define
the
exact
major
version
of
mariadb
that
we're
going
to
use
as
our
primary
database
in
this
services
yaml
file,
and
we
can
determine
how
much
disk
it
gets
allocated
to
it.
And
if
you'll
see
we
give
it
this
service
name
db,
it
becomes
how
our
wordpress
application.
B
You'll
see
right
here,
we
have
something:
that's
called
a
relationships
block
that
defines
the
internal
network
of
our
final
project,
so
while
everything's
committed
this
is
where
we
can
actually
do
some
communication
between
our
services.
So
here
here's
our
db
service
and
to
our
application.
It's
going
to
be
accessible
from
this
database
name
this
database
key
here
and
everything
ends
up
being
isolated
and
but
also
environment
independent,
like
I
said
so,
we
have
this
generic.
B
So
in
this
screen
capture
here,
all
I'm
showing
is
hey.
We've
created
a
new
branch.
We
want
to
test
the
new
version
of
mariadb.
I
can
go
into
this
services.
Yaml
file,
change
that
single
character
from
four
to
five
push
it
up
into
a
new
branch
and
open
a
pull
request,
and
I
get
a
brand
new
environment
that
can
test
out
that
change.
It's
isolated
with
this
byte
level
copy
of
all
of
our
production
data.
So
it's
actually
going
into
that
new
version
of
the
database,
so
that
I
can
verify
that.
B
Hey
things,
look
good!
I'd
like
to
be
on
the
newest
version:
mariadb!
Our
real
data
is
inside
of
it
it's
past,
all
of
our
build
tests
and
working
with
that
data
feeling
pretty
confident.
So
I
think
here
in
this
screen
capture,
I'm
just
showing
that
I
have
a
generated
url
for
master
on
the
left
and
now
this
pull
request
that
I
just
opened
that
contains
the
same
content
that
was
stored
in
the
database
between
my
two.
B
Environments,
so
that
comes
in
handy
when
we're
doing
all
the
tests,
and
so
this
services
yaml
file
can
be
extensible
to
continue
to
build
out
our
virtual
cluster.
So
I
have
just
a
database
here
now,
but
I
can
add
redis
with
just
a
new
service
name
here
at
6-0
and
that's
a
nice
one.
I
think
it's
elastic
search
yeah.
B
So
I
can
add
an
elastic
search
service
too,
and
it
just
adds
another
container
to
our
cluster
and
so
long
as
we
define
a
relationship
in
our
our
appian
file
in
our
application
configuration
each
of
these
services
now
become
accessible
so
that
we
can
modify
our
application
code.
Our
actual
code
base
for
the
site
to
start
using
these
services
very
quickly,
there's
no
add-on
process
or
anything
like
that.
It's
just
simply
branch
do
the
services
yaml
and
it
becomes
a
part
of
our
commit
history.
Just
like
any
changes
in
our
code.
B
B
Think,
what's
the
I'm,
I've
always
been
curious?
What's
the
prevalence
of
like
this
decoupled
conversation
in
in
the
java
space?
I
know
when
I
become
more
where
I've
been
more
familiar
with.
It
obviously
is
it's
a
javascript
type
of
thing.
People
are
really
interested
in
doing
a
javascript
front
end,
but
it's
a
lot
of
php
applications
on
the
back
end.
You
know:
are
there
any
real
popular
java
cmss
that
people
are
interested
in
doing
this
to
coupled
pattern
with?
B
If,
if
anybody
does
know,
please
just
leave
it
in
the
chat,
but
one
thing
that
we
can
kind
of
build
on
this
idea
of
adding
additional
service
containers
in
this
way
in
our
services
yaml
file,
we
can
do
the
same
thing
with
the
structure
of
our
code
base
itself,
so
I
can
take
that
addition
that
original
wordpress
site
and
I
can
place
it
inside
its
own
subdirectory.
It
still
has
its
app
yaml
file
for
configuration
and
then
I
can
add
a
new
app
container
to
that
cluster.
That's
a
gatsby
site.
B
That's
then,
going
to
evolve
alongside
wordpress,
as
my
developers
are
making
making
changes
to
it,
but
it
exists
in
its
own
container.
In
this
case,
I'm
gonna
add
I'm
gonna
edit.
This
name.
Oh,
I
guess
I
guess
I'm
not
in
this
case,
I'm
going
to
give
it
a
new,
unique
name:
that's
not
app
something
like
gatsby.
It's
got
its
own
node.js
runtime,
it's
its
own
method
of
using
yarn
for
installing
dependencies,
its
own
build
hook
and
its
own
way
of
serving
its
file
built
html,
the
one
oh
yeah.
I
guess
so.
B
This
can
go
for
as
large
of
a
microservices
sort
of
configuration
that
you
want
multiple
java
apps,
a
large
variety
of
different
runtimes
as
many
different
services
as
you
want.
We
actually
have
an
example
project
that
essentially
connects
all
of
our
runtimes
and
all
of
our
services,
just
so
that
we
can
provide
live.
B
Live
code,
examples
for
let's
say
java,
interacting
with
elasticsearch
in
an
application,
so
we
can
sort
of
have
our
own.
We
can.
We
can
make
ourselves
feel
a
little
bit
better
that
we're
providing
an
example
inside
our
documentation,
that's
actually
running
on
a
site.
That's
gone
through
all
these
same
assurances
and
tests
that
I've
described
here,
but
I
think
that,
right
after
this.
B
B
So
in
this
case,
this
is
when
we
get
into
things
like
access,
control
and
secrets
management,
and
so
a
lot
of
that
has
to
do
with
how
we
define
the
environments
and
then
how
we
define
environment
variables-
and
I
mentioned
a
little
bit
about
that
already
when
it
came
to
giving
access
to
services
in
the
cluster
database,
doesn't
have
a
password
that
anybody
needs
to
know
about.
You
just
point
to
the
environment.
Variable
you
point
to
the
generic
internal
network,
location
and
everything
gets
kind
of
abstracted
away
at
that
level.
B
So
if
I
have
a
developer,
that
adds
a
new
feature
on
a
pull
request,
I,
as
the
admin,
can
add
that
person
as
a
developer
to
my
platform
project
that
gives
them
a
little
bit
more
access
to
debugging
information
about
the
environment,
tied
to
this
pull
request.
But
then
they
don't
have
any
access
to
any
of
the
other
environments.
B
So
if
I
do
have
a
ultra
secret
ultra
secret
api
token
for
my
payment
gateway
that
only
exists
on
the
production
site,
I
can
set
it
up
so
that
every
child
environment
has
no
access
to
it
to
begin
with,
but
also
that,
if
there's
any
other
variables
that
I'd
like
to
I'd
rather
keep
secret.
This,
I
think
I
have
it
here-
is
an
external
design
agency.
B
So
this
is,
I
don't
know,
in
my
opinion,
it's
pretty
pretty
nice,
like
I
I'll
be
honest
that
when
I
started
with
my
company,
my
web
development
experience
was
pretty
minimal.
I
came
from
a
python
programming
background
in
academia,
so,
coming
to
this
way
of
working,
I've
always
been,
maybe
surprised,
but
like
a
lot
of
validation
that
comes
with
our
platform.
B
B
All
of
that
being
like
really
highly
visible
and
kind
of
at
the
the
right,
low
level
of
abstraction
has
been
really
nice
to
play
with,
and
the
next
thing
that
become
has
become
really
interesting
for
me
is
when
we
get
back
into
what
I
talked
about
before
this
this
fleet
conversation.
So
I
have
a
a
100
java,
apps
100
wordpress
apps
out
there.
What
do
I
do
to
kind
of
let
like
with
some
bulk
tests?
B
I
have
a
developer,
who
needs
access
to
a
particular
environment
on
every
single
one
of
these
sites
or
more
commonly.
I
need
some
machine
user
to
have
access
on
each
one
of
these
environments
on
each
one
of
these
sites
to
run
some
action
like
getting
updates
on
my
dependencies
like.
How
do
I
do
that
in
an
efficient
way?
B
You
know
if
I'm
building
a
site
as
an
agency
for
one
of
my
clients,
it's
great,
to
be
able
to
control
when
things
redeploy
when
updates
happen,
dependencies
or
otherwise
or
infrastructure,
or
getting
new
features
that
one
of
my
developers
has
done,
adding
elastic
search
to
the
upstream.
So
now
it's
on
all
clients
and
that's
great
for
this
really
widespread
control,
but
our
projects
are
still
isolated
as
far
as
the
api
is
concerned.
So
if
that
client
has
a
developer
of
their
own,
that's
going
to
be
working
on
that
project.
B
They
can
still
open
a
branch
and
make
changes
to
that
site
and
not
really
break
any
of
this
control.
That's
happening
right
here
and
that
to
me
seems
to
be
the
interesting
thing
of
something
I
really
wouldn't
want
to
try
to
re-engineer
myself
with
some
of
these
other
git
ops
tools
to
to
build
up
a
process
like
this,
and
so
that's
what
we
have
at
platform
pass
this
graphic.
B
Maybe
so
I
have
that
same
repo
that
I
was
showing
you
before
with
pull
request,
but
this
now
becomes
the
upstream
code
base
that
I
can
see
hundreds
of
other
projects
out
there
in
the
world.
For
my
clients
from
I
can
open
branches
on
this
particular
repository
and
make
changes,
but,
like
I
said
so,
can
they
on
their
individual
project
and
not
really
run
into
each
other.
B
They
still
can
have
a
pretty
customizable
experience
there
and
the
way
that
we
open
that
up
through
our
api
is
we
have
this
relatively
newer
feature
called
source
operations.
So
it's
here
where
I
can
do
things
like
pull
from
that
upstream
code
base.
So
this
is
now
a
committed
command
on
my
application
container
that
essentially
creates
a
new
endpoint
in
addition
to
our
existing
platform.
B
Api
that
can
do
things
like
get
pull
from
that
upstream
and
merge
into
a
development
environment,
run
all
my
tests
and
then
alert
me
that
that
upstream
update
occurred,
and
I
can
go
into
that
environment
and
test
it
before
I
merge
the
production,
or
in
this
case
I
created
this
update
depths
endpoint,
that's
again
because
this
just
happens
to
be
wordpress.
I
can
run
composer
update
and
then
commit
to
that
project,
and
that
becomes
an
important
thing,
because
any
activity
on
a
project
is
entirely
tied
to
these
commits.
B
B
I
was
going
to
say
or
on
your
production
environment,
but
I
probably
wouldn't
recommend
putting
this
endpoint
as
having
any
access
to
your
production
environment,
but
we
still
have
checks
that
can
run
on
this
command,
like
you
can
have
an
if
statement
that
checks,
an
environment
variable
that
we
have
in
all
of
our
application
containers,
it's
called
platform
branch
to
say
if
this
branch
isn't
master
or
if
this
branch
is,
you
know,
update,
it's
called
update
depths
and
it's
a
dedicated
environment.
Just
for
this
action.
B
Sites,
oh
so
here's
the
example
of
exactly
that.
So
this
would
be
another
endpoint
here
that
updates
the
upstream.
So
I
have
another
environment
variable
that
I
can
initialize
on
any
project
that
I
defined
that
might
be
in
this
fleet
of
java,
apps
or
whatever
it
would
would
be.
It's
called
upstream
root
and
periodically
or
every
time
I
trigger
it
from
some
major
control
board.
I
can
trigger
this
update
upstream
operation
and
control.
What
that
final,
build
image
looks
like.
B
And
yeah,
I
hope
I
didn't
go
too
fast.
That's
kind
of
what
all
I
wanted
to
go
through
demo
wise.
I
have
a
few
windows
open
here
of
a
pair
of
project
running
some
links
that
I
can
share
with
you
guys,
but
that's
really,
the
quick
look.
I
wanted
to
give
you
on
git,
ops
and
platform
sage
and
a
lot
of
the
tooling
that
we
built
on
top
of
git.
B
But
you
know
we
come
out
with
a
new
version
of
java
or
of
redis
and
solar.
You
can
branch
and
try
out
that
new
major
version
on
one
of
the
new
branches
and
it's
not
a
difficult
task
to
communicate
to
somebody
you're
working
with
of
how
to
do
that,
change,
a
character
on
new
branch
and
test
it
out
so
yeah.
Thank
you
very
much
for
listening
happy
to
stick
around
for
any
questions
and
I'm
happy
to
share
any
resources
that
you
guys
are
interested
in
getting
about
platform
and
what
we
do
with
java.
There.
A
Awesome
well,
thank
you,
chad,
for
that,
and
if
people
have
questions
just
while,
we
wrap
up
here
I'll
go
ahead
and
do
the
housekeeping
items
now,
and
that
will
give
you
a
little
bit
of
extra
time
to
get
your
questions
in
in
the
chat
and
we
can.
We
can
ask
chad
but
yeah.
Thank
you.
Chad.
For
that
presentation,
platform
sh
certainly
does
seem
to
offer
some
great
tools
to
make
it
easier
to
configure
and
improve
project
infrastructure,
and
just
so
people
know
for
housekeeping
items.
A
That
is
the
third
link
I
posted,
and
so
at
this
point,
if
no
one
else
has
any
questions
for
chad,
chad.
Thank
you
and
I'll.
Give
you
a
minute
for
any
final
remarks,
but
yeah
thanks
everybody
for
joining
us
and
if
you
have
any
feedback
on
how
you
like
the
jakarta
tech,
talk
by
all
means
feel
free
to
fill
out.
The
survey
by
clicking
the
green
button
chad
back
over
to
you
for
some
final
words.