►
From YouTube: The modern mainframe: GitHub for social coding and mainframe app development - GitHub Universe 2019
Description
Rumors of the mainframe's demise have been greatly exaggerated. In fact, mainframe workloads are growing in many Enterprises. Until recently mainframe tooling and development processes have been static - stuck in earlier eras. Non-mainframe developers favor Git and GitHub for their decentralized nature, collaboration, and workflow flexibility. As seasoned mainframe programmers leave the workforce many developers are being hired to enhance, modernize, and manage mainframe applications. This makes the need to provide familiar tools and processes more important than ever.
This session covers how businesses can modernize their mainframe development experience with tooling including Git, GitHub, and Jenkins, making it easier for a new generation of developers to support growing mainframe workloads.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
B
A
A
That
businesses
depend
upon
each
day
and
you
know
there's
always
hype
in
any
sort
of
new
technology
era,
and
that
technology
is
really
that
this
new
deployment
architecture
and
this
new
pattern
is
gonna
completely
displace
the
prior
pattern.
And
so
we've
seen
that
in
history
over
time.
At
first
it
was
that
distributed
servers
and
then
desktops
were
going
to
replace
the
mainframe.
But
they
didn't
completely.
Do
that
and
then
containers
were
supposed
to
kill,
distributed
servers
that
hasn't
happened
either
and
then
of
course,
server
lists
have
came
around
to
kill
it
all.
A
B
So
I
guess
you
know
the
obvious
question
why
mainframe
and
I'd
like
to
think
of
it
as
why
not
mainframe
right,
it's
been
there
for
ages
and
it
you
know
the
qualities
of
surface
that
that
mainframe
actually
provides
in
terms
of
the
throughput
scalability
security,
reliability,
that's
unmatched
right
and
then
the
key
thing
here
is
mainframe
continues
to
serve
as
the
backbone.
For
you
know,
retail
airline
finance
insurance
government
industries
today.
So
there
are
some
statistics
in
here
that
that
actually
proved
the
relevance
of
mainframe
and
the
importance
of
mainframe
in
the
current
industry.
B
A
They
are
challenges
around
the
processes
that
are
involved
in
actually
getting
code
from
the
point
that
it's
written
through
testing
and
into
production,
the
technological
challenges
of
getting
it
through
that
process
and
then,
of
course,
the
human,
the
cultural,
the
people
challenges
of
adapting
to
new
workflows
and
new
technologies.
So,
as
we
start
looking
at
some
of
those
challenges,
one
of
the
more
obvious
ones
is
a
people
challenge,
and
that
is
that
most
mainframe
developers
out
there
are
seasoned
developers,
but
that
code
isn't
going
anywhere
and
there
need
to
be
people
to
maintain
that.
A
Then,
cotton,
doll
of
those
core
business
systems
that
we
rely
on
day
to
day
for
credit
card,
transaction
processing,
Airport
airline,
ticketing.
All
these
other
systems
and
a
lot
of
teams
are
building
things
on
top
of
those
core
business
functions,
whether
that
be
a
mobile
application
that
allows
you
to
perform
your
financial
transactions
or
your
Airlines
mobile
application
that
allows
you
to
interact
with
the
ticketing
system,
they're
all
moving
at
the
pace
of
agile
rapid
workflows
and
are
often
dependent
upon
changes
to
that
underlying
mainframe
system.
B
Then
you
know,
last
but
not
least,
is
the
tools
right,
so
how
many
people
are
actually
familiar
with
those
those
screen
caps
up
there?
Okay,
these
are
the
traditional
ispf
green
screens,
and
is
everybody
sitting
believe
it
not?
That
is
the
primary
IDE
today
in
2019,
when
it
comes
to
mentoring,
organizations
and
I'm,
not
kidding
okay.
So
that's
the
state
of
tools
now
I'm
not
saying
this
is
a
good
or
a
bad
thing.
That's
how
the
the
mainframe
industry
has
evolved
over
a
period
of
time
right
because
of
the
heritage
and
the
legacy.
B
That's
been
there
over
the
last
50
60
years.
You
know
the
tools
that
people
have
been
using
at
that
particular
time
which
were
great.
You
know
they
built
up
the
muscle
memory
right
and
they
are
really
productive
and
it's
amazing
how
productive
they
are,
but
that's
the
state
of
the
the
the
current
affairs
and
then
you
know
so
in
order
to
modernize
some
of
that
stuff.
Eclipse
tools
were
born
and
you
know
they
took
a
stab
at
modernizing
those
green
screen
interfaces.
B
A
lot
of
vendors
have
actually
provided
the
plugins
to
and
then
the
child
challenge
always
existed
because
because
of
the
history
right,
the
30
40
50
year,
history
organizations
have
tried
to
solve
the
problem,
which
means
they
have
built
proprietary
tools
around
it.
So
the
integration
of
those
proprietary
tools
and
bringing
them
into
you
know
the
fold
became
a
problem
when
it
comes
to
tools
and.
A
The
new,
tooling
everything
that's
involved
with
that
which
is
markedly
different
than
probably
anything
you've
ever
touched
as
a
developer
before
this
creates
a
problem
recruitment
because
who
wants
to
go,
learn
thirty-year-old
technology
and
process
in
order
to
get
the
job
running
and
who
wants
to
have
to
deal
with
that
constant
context.
Switching
if
they're
gonna
be
maintaining
mainframe
code
part-time
and
then
have
to
switch
over
to
distributed
code
or
code
for
mobile
other
desktop
applications.
A
So
that
really
this
kind
of
begs
the
question.
What
other
platform
out
there
requires
this
much
specialization
and
the
fact
is
right
now:
it's
none!
All
of
those
other
deployment
targets
are
used
pretty
much
the
same
tooling
and
process
in
order
to
get
the
code
through.
That
doesn't
have
to
be
the
case
for
mainframe
anymore
and
modernization
isn't
new
on
the
mainframe.
A
Modernization
has
continued
to
occur
over
and
over
again,
as
mainframes
have
supported
things
like
virtualization
and
containerization,
and
scalability
and
persistent
encryption
for
a
number
of
years.
But
what
hasn't
modernized
as
of
yet
is
that
process
and
we're
up
here
today
to
talk
about
how
the
that
is
no
longer
the
case
with
the
tools
that
are
present
and
the
first
step
in
that
was
honestly.
It's
a
port
forget
so
rocket
Software
a
couple
of
years
back
created
an
open-source
port
of
get
to
run
natively
on
z/os.
A
This
is
what
starts
to
enable
branch
based
work,
close
and
more
modern
iterative
development
on
mainframe
application
and
with
code
in
git.
We
can
then
start
integrating
other
more
modern
tools
and
processes
and
start
strict,
removing
a
lot
of
those
from
those
mainframe
specific,
antiquated
tools
into
a
more
modern
framework,
and
this
really
gets
at
that
pressing
need
to
modernize
that
application
stack,
modernize,
the
development
tooling,
so
that
organizations
can
more
easily
bring
people
into
the
mainframe
development
fold
and
continue
to
maintain
those
work
floats
that
everyone
depends
upon
and.
B
Talking
about
open
source
right,
one
of
our
philosophies
at
comm
internally,
as
well
as
what
we
are
actually
telling
our
customers
is,
you
know
mainframe
can
actually
embrace
open
source
and
we,
along
with
IBM
and
rocket
software,
actually
created
a
consortium
called
Zoe.
It
is
the
first-ever
mainframe-based
open
source
project,
it's
under
the
open
mainframe
under
the
the
Linux
Foundation.
B
So
the
goal
here
is
to
actually
make
mainframe
be
like
any
other
platform
right
in
this
current
day
and
age.
You
know,
mainframe
has
been
siloed
for
a
very
long
time.
It
has
been
considered
as
oh,
my
god.
This
is
you
know
this
antiquated
machine.
You
know
using
antiquated
languages,
and
things
like
that
that
has
been
kind
of
kept
away
from
from
the
normal
flow,
but
with
the
current
change
and
trends
in
the
industry,
organizations
wanna
standardize
on
a
common
stack
right,
mobile
mainframe
is
is
a
reality.
B
It
is
there
today
so
from
an
enterprise
point
of
view.
They
would
like
to
have
a
consistent
set
of
tooling
and
processes
and
workflows
across
the
board,
whether
they're,
actually
developing,
mainframe
or
mobile,
right
and
zoe
is
an
open
source
project.
That
is
actually
opening
up
the
doors
you
know
for
open
source
2
to
2
mainframe.
So
one
of
the
key
components
of
Zoe
is
a
CLI.
So
on
this
picture
pretty
much
paints
the
picture
right.
It's
it
says
the
story
for
you.
B
So
today
you
can
see
you
know
developers
actually
using
CLI
to
interact
with
AWS
sure
right.
Why
can't
we
have
the
same
thing
for
mainframe
right?
Why
should
mainframe
be
different,
so
Zoe
CLI
actually
enables
that
kind
of
capability
to
interact
with
mainframe.
Now
one
of
the
key
things
that
Zoe
is
also
driving
from
a
modernization
perspective
is
for
it
of
for
anybody
to
actually
use
the
CLI.
You
know
there
are
picture,
shows
you
some
some.
You
know
mainframe
related
technologies.
Some
are
basically
infrastructural
pieces.
B
Some
are
actually
the
middleware
software,
that's
actually
running
there,
but
in
order
to
actually
leverage
CLI
right,
what
it
force
it
is
everybody
to
think
about
API,
a'f
occation.
So
all
of
those
infrastructure
pieces
middleware
software
now
have
REST
API.
That
can
be,
you
know,
involved
through
a
CLI
interface,
and
the
idea
of
CL
is
anything
that
you
can
renounce.
Yell
I.
Can
be
scripted,
which
means
you
can
actually
automate
it.
A
So
one
option
is,
of
course,
to
take
all
the
code
that
exists
in
your
existing
mainframe
SCM
and
bring
it
directly
into
get
and
use
git
natively
going
forward
depending
upon
how
much
heritage
and
how
much
mainframe
code
you
have
and
how
many
decades
of
processes
are
built
in
that
may
or
may
not
be
a
very
large
task
to
handle.
The
other
approach
is
to
go
ahead
and
interface
to
that
existing
system,
so
that
all
the
modern
tooling
can
happen
on
top
and
mainframe
developers
and
maintainers.
A
Don't
have
to
worry
about
that
interface
and
we're
here
today
and
ven
cuts
gonna
share
a
bit
more
too
about
broad
comms
approach,
which
is
that
embracing
of
heritage
to
be
able
to
utilize
those
best
debris
to
lanes
and
start
working
much
more
quickly
without
a
need
to
migrate.
All
of
that
logic
on
all
of
the
code
that
exists
in
that
problem,
those
projects.
B
So
you
know
the
approach
that
we
are
actually
taking
is
so,
but
never
let
me
take
it
one
more
step
back
right.
Whenever
we
talk
about
mainframe,
you
know
you
hear
the
word
legacy
right.
I,
don't
want
to
look
at
it
as
a
legacy
legacy,
something
that
you
leave
behind.
I
want
to
look
at
it
as
heritage.
That
is
something
that
you
can
actually
leverage.
You
continue
to
use.
You
continue
to
build
on
right.
B
The
reality
is,
you
know,
organizations
have
invested
30,
40,
50
years
of
effort
in
it,
and
our
goal
right
internally
for
ourselves
as
well
as
for
our
customers,
is
to
see
how
we
can
leverage
or
proba
allow
that
heritage
to
can
to
be
to
be
reused
right
now,
as
as
phil
was
talking
about.
Obviously,
there
are
different
approaches
right
for
the
folks
who
actually
attended
the
Ford
session
yesterday
they
were
actually
talking
about
moving
from
clearcase
to
get
up
and
that's
a
perfect
use
case
right.
B
You
know,
and
and
that's
pretty
legit,
and
if
there
are
organizations
who
have
their
source
code
be
sitting
in
a
proprietary
repository
or
something
else
that
is
all
flat
for
migrating
together
of
standardizing
on.
It
is
a
perfect
approach,
but
is
that
the
answer
for
all
the
cases
probably
not
right,
and
that's
one
of
the
things
that
we
are
actually
going
to
talk
about
today?
So
so
our
goal
is
to
say
that
you
know
there
is
a.
B
There
is
a
mainframe
SEM
right
so
for
for
the
folks
who
are
not
familiar
with
mainframe
SCMS
typical
stuff
that
exists
there
is
it's
not
just
a
version
control
system
right,
it
is
also
a
build
engine.
It
is
actually
also
a
lifecycle
management
governance
audit
tool.
So
what
that
means
is
the
investment
that
the
organization's
have
put
in
and
the
processes
that
they
have
established
around
it
is
is
something
that
needs
to
be
managed
maintained
and
you
don't
want
to
disrupt
that
workflow.
So
that's
one
of
our
key.
B
You
know
bedrock
principles
as
we
are
looking
at
this
modernization
effort
now.
The
other
thing
is,
you
know.
As
I
said,
mainframe
run
code
runs
on,
mainframe
is
built
on
mainframe,
it's
deployed
on
the
mainframe
so
and
then
the
number
of
assets
that
we're
actually
talking
about
actually
runs
into
millions
right.
So
over
the
years,
that's
what
it
has
grown
to
so
those
things
you
know.
B
If,
if
the
approach
is
to
say
hey,
you
know,
you
know
to
take
everything
out
of
your
SCM
and
move
it
to
github
and
then
rebuild
or
reinvent
your
infrastructure,
so
that
you
can
actually
do
the
bills.
The
promotion,
the
lifecycle
management,
that's
a
huge
task
for
these
mainframe
organizations
who
are
still
trying
to
get
their
head
around.
B
You
know
DevOps,
agile
principles,
and
things
like
that,
so
we
want
to
make
life
easy
and
and
simple
using
using
these
using
using
our
bridging
approach,
and
the
other
thing
that
we
want
to
do
is
one
of
the
things
mainframe
organization
of
ever
Stu
is
bringing
new
tools
to
the
platform.
So
if
you
want
to
get
a
new
tool
on
to
the
mainframe,
it's
a
huge
task,
because
you
know
because
of
the
existing
processes.
In
terms
of
when
you
know,
new
mainframe
software
can
be
installed.
B
What
kind
of
rigor
and
checks
it
needs
to
go
through
before
it
gets
approved
and
blessed.
So
we
want,
we
don't
want
to.
You,
know,
introduce
you
know
any
niche
tools
onto
the
platform,
but
rather
leverage
something
that's
there,
but
still
gave
organizations
the
flexibility
to
do
the
job
in
using
the
modern
tools.
A
B
B
So
why
get
well
I
mean
there
is
a
lot
of
text
on
that
chart,
but
the
thing
that
struck
me
is
that
October's
report
that
said,
1.7
million
students
learn
how
to
code
using
github
now
related
back
to
the
slide
that
Phil
had
talking
about
the
skill
gap.
If
you
think
about
it,
you
know
these
1.7
million
students
who
have
learned
how
to
code
on
github
are
the
ones
were
gonna,
come
into
this
workforce,
trying
to
bridge
that
skills
gap
so
providing
or
having
set
of
tools
that
they
can
understand.
B
The
green
screen
remember
that
we
don't
want
that
in
the
2-2
to
welcome
the
new
generation
of
application
developers
to
the
platform.
Okay.
The
other
thing
that
I
mentioned
when
we
talk
to
our
organization
I
mean
the
various
customers
is
they
want
to
standardize
right,
I
mentioned
that
they
want
to
use
a
common
set
of
tools.
B
They
want
their
developers
to
be
speaking
the
same
language
same
workflow,
so
that
you
know
they
can
actually
have
full
stack
developer
to
be
developing
Java,
Ruby,
Python
or
COBOL
and
B
be
familiar
with
the
workflows
and
the
tools
that
they're
actually
using,
and
you
know
that
involves
providing
a
seamless
experience
when
it
comes
to
your.
You
know
how
developers
are
actually
interacting
the
tools
that
they're
actually
using,
which
is
which
may
include
their
favorite
IDE
right
and
then
you
know,
leverage
the
the
proven
and
collaboration
practices
that
are
out
there
to
establish
that.
B
So
that's
the
reason
why
we're
going
to
actually
use
get
our
standardized
on
get
further
four
main
training
organizations.
So
then
the
question
arises:
what
happens
to
those
you
know
my
good
friends
who
are
about
or
60
the
30
percent
60
plus
year
old
mainframe
errs,
who
are
really
productive
with
the
existing
tools.
Our
solution
will
give
the
organizations
the
flexibility
that
so
that
the
existing
set
of
developers
who
don't
know
anything
about
gear
github,
they
can
continue
to
use
their
the
tools
that
they're
actually
familiar
with.
They
don't
have
to
transform
anything.
B
A
A
B
Wanna
admit
that
but
hey,
why
not?
So
so?
That's
that's
the
the
the
again
striking
that
balance
right,
making
it
easy
for
enterprises
to
go
through
this
transformation
and
not
you
know,
change
the
the
entire
workflow
processes
for
everybody
with
the
flip
of
a
switch.
So
that's
what
we're
actually
looking
at
right.
So
what
enables
that
magic?
So
what
we
are,
what
we
have
developed
is
called
get
bridge.
B
You
know
it's
essentially
a
simple
springboard
java
application
bridges
get
hub
to
the
mainframe
source
configuration
system,
so
the
gate
bridge
is
the
magic
that's
going
to
manage
every
thing
behind
the
covers
from
a
developer
perspective,
and
you
know,
a
mainframe
developer
can
actually
use
the
green
screen
Eclipse
interface,
whatever
they
want
to
use
right.
They
can
continue
to
work
on
using
that
and
more
you
know.
B
A
new
age
application
developer
can
use
their
favorite
IDE
vs
code,
Eclipse
IntelliJ,
you
name
it
right,
and
the
gate
bridge
is
actually
going
to
manage
the
synchronization
of
these
two
and
make
it
seamless
from
from
a
end
user
perspective,
and
they
don't
have
to
worry
about.
You
know
the
interacting
with
mainframe.
So,
as
you
can
see
on
this
particular
chart,
we
have
identified
three
different
personas
Michelle
is
our
new
age
application
developer
Tod?
B
B
So
here
is
a
basically
a
simple
overview
of
how
how
you
know
it
works.
So
the
gate
bridge
saying
this
app
actually
manages
the
mapping
between
a
github
repository
or
a
branch
to
whatever
is
actually
sitting
on
the
mainframe
SCM
in
the
backend.
So
it
essentially
does
the
the
the
mapping
management
and
the
synchronization
aspects
of
it
and
the
components
that
we
have
in
there
are
well.
B
The
user
would
actually
be
interacting
with
using
a
web
UI
and
they
there
is
an
email
notification
that
actually
comes
in
when
there
are
some
changes
that
the
user
has
to
worry
about,
and
then
we
have
a
scheduler,
remember.
I
said
the
gate
bridge
is
responsible
for
doing
the
synchronization,
so
so
organizations
when
they're,
actually
setting
up
this
good
bridge
can
say
I
want
to
do
the
synchronization
on
a
particular
schedule,
or
we
have
even
based
synchronization
mechanism
that'll.
Actually
you
know
synchronize
the
backend
mainframe
ECM
to
to
the
the
github
nice
repo.
B
We
use
JDO
for
actually
doing
our
persistence,
there's
logging
infrastructure
and
then
there
is
a
endeavour.
Web
services
component,
which
is
basically
the
interacting
with
the
backend
mainframe
using
REST
API,
so
remember
the
CLI
aspect
of
it
that
actually,
you
know,
forced
us
to
have
these
REST
API,
and
that
enabled
you
know
us
to
do
more
innovation.
In
this
area
we
use
jagged
library
to
talk
to
github.
There
is
a
github
app.
B
You
know
that
pretty
much
you
know,
I
loves
us
to
integrate
the
the
Gate
Bridge
to
the
github
repository
to
handle
any
of
the
authentication
race,
api's
hook,
management
and
stuff,
like
that.
So
that's
a
very
high-level
picture
of
how
we
do
it
now.
Here
is
a
picture
that
shows
you
of
our
back-end.
You
know
SCM
system
and
what
the
the
sdlc
lifecycle
would
look
like.
So
what
you're
looking
at
here
is
basically
the
different
stages
right:
the
dev
test
fraud.
This
is
this
is
configurable,
so
organizations.
B
So
this
is
how
the
code
would
actually
flow
when
I
talk
about
lifecycle
management
on
the
mainframe
right.
So
it
goes
from
dev
to
test
one
to
test
you
to
pre
prod
to
prod,
but
that's
the
workflow
that
you
have,
and
there
is
a
map.
You
know
that
be
back
in
the
CM
managers.
In
terms
of
you
know
what
artifact
is
sitting
where,
so
it
has
that
particular
knowledge-
and
the
key
thing
here
to
note
is
there-
is
something
called
an
increased
age.
This
is
where
the
developers
actually
work.
B
This
is
where
developers
are
actually
pulling
the
you
know
the
latest
version
from
to
make
the
further
modifications,
and
why
is
that
important?
Because,
as
I
said,
you
know,
these
back-end
SEMS
typically
may
have
millions
of
artifacts
to
enable
this.
We
don't
want
to
clone
all
of
those
million
artifacts
into
a
github
repository,
because
we
don't
want
it
to
take
like
a
week
before
people
can
actually
start
using
it.
So
the
idea
here
is
the
gate:
bridge
will
only
map
to
this
code
and
code
entry
stage
that
the
developers
are
actually
working
with.
B
So
what
that
does
is
basically
it
subsets.
The
amount
of
you
know
artifacts
that
the
users
are
actually
looking
at
right.
So
that
way
you
are
not
cloning,
everything
and
then
the
Gate
Bridge
has
additional
functionality
to
say.
Oh,
if
I
need
a
dependency,
for
example,
that
is
not
part
of
the
stuff.
You
can
actually
pull
it
using
into
it
into
the
working
directory
using
the
using
the
Goodrich.
So
that's
essentially
how
the
magic
actually
happens.
B
Now
you
know
a
typical
get
developer
rate.
You
know
you
have
your
enterprise,
good
repo,
you
create
your
free
to
branch,
you
make
your
changes
and
then
what
you
know
if
you're
following
the
the
basic
principles,
you
would
actually
want
to
do
it
build
just
compile
a
link
off
your
changes
without,
actually
being
you
know,
we
impacting
other
changes
or
pulling
in
other
changes
from
other
developers.
So
what
we
have
is
you
know
a
a
mechanism,
so
we
actually
ship
a
build
script
that
can
be
customized
and
it
leverages
Zoe.
B
Remember
that
open
source
project
that
I
mentioned
it
leverages
Zoe
to
facilitate
the
build
of
the
user
changes.
So
this
provides
the
developer
isolation
and
you
know
in
terms
of
the
build
so
that
they
can
actually
build
this.
Their
changes
validate
their
changes
before
actually
pushing
it
back
into
the
into
the
main
repository.
B
Excuse
me
sorry.
Now,
I
wanna
I
want
to
actually
use
the
workflow,
so
I
commit
my
changes
to
the
enterprise's
good
repo
and
then
the
gate
bridge
is
going
to
propagate
those
changes
back
to
back
to
the
backend
SCM.
Ok,
life
is
great
right
now.
What
happens
when
something
goes
wrong,
which
is
the
case
where
Carl
has
made
some
changes
using
his
ispf
interface
for
the
same
source
modules.
B
You
know
that
the
user
is
actually
working
in
a
gate
environment,
so
the
collisions
are
possible,
so
the
gate
bridge
actually
detects
those
changes
and
before
it
actually
pushes
or
synchronizes
those
changes
back
it
does
a
vanity.
There
is
a
valley
datian
step
where
it
validates
and
if
there
is
a
conflict
that
cannot
mean
that
you
know
merged
automatically
it'll
actually
create
a
private
branch
and
notify
the
user.
Why
our
email
saying
hey?
You
know
you
need
to
worry
about
merging
in
these
changes,
because
something
else
has
happened
on
the
backend.
B
Okay,
so
I
have
a
real
recorded
demo
nowise,
because
I
like
to
talk
so
we'll
just
run
through
this.
This
particular
demo
that
to
give
you
an
idea
of
how
how
it
actually
works.
So
what
you're
seeing
here
is
our
get
bridge
interface
right.
So
this
is
where
Todd
are
in
the
gate
of
admin
would
actually
come
in
and
do
the
mappings.
So
this
is
not
a
typical
developer
interface
that
they
would
actually
interact
with.
So
he
would
do
the
clone.
B
He
would
do
the
mapping
and,
as
you
can
see,
there
are
these
COBOL
artifacts
that
have
been
cloned
into
into
a
get
up
repo.
They
can
actually
look
at
and
hey.
You
know
there
is
even
syntax
highlighting
for
COBOL
code
awesome
now
the
developer
here
is,
you
know,
we're
actually
again
in
spirit
of
opening
up
open
source.
Here
is
a
choice
from
a
developer's
perspective.
This
is
Eclipse
Shea,
which
is
a
hosted
IDE
that
we
have
extended
for
with
COBOL
specific
tooling,
and
then
you
know
the
developer
is
working
there.
B
The
lower
git
pull
just
to
make
sure
that
everything
is
up
to
date
and
then
create
a
feature.
Branch
right,
the
typical
to
get
related
activities
from
the
IDE
and
now
what
I
would
do,
is
I
open
up
my
COBOL
program
where
I
need
to
make
the
changes
and,
as
you
can
see
it
has
you
know,
COBOL,
specific
syntax,
highlighting
this
is
the
extensions
that
we
built.
B
You
can
actually
do
pretty
much
expect
all
sorts
of
common
things
like
you
know,
curtis's
real
time,
validation
for
COBOL
for
any
other
language,
and
you
know
they
don't
let
architects
do
coding
anymore.
So
all
I'm
allowed
to
do
is
basically
make
a
comment
change
here
so
making
that
particular
change
in
my
feature.
Branch.
So
add
it
in
a
comment.
B
And
once
I'm
done,
I
can
actually
go,
save
it
and
then
use
leverage,
the
IDE
capabilities
and
the
gate
capabilities
that
are
built
in
to
do
a
comparison
of
the
current
version.
That's
out
there,
so
I
can
use
that.
I
can
see
my
changes
and
now,
since
I
made
a
very
important
change,
I
need
to
build
it.
Okay,
so
I'm
gonna
run
the
script
to
do
the
build
and
what
it's
doing
is
essentially
it's
leveraging
Zoe
as
the
infrastructure
to
take
the
modified
artifacts
sitting
in
my
future
branch
to
the
mainframe
leveraging
the
build
infrastructure.
B
That's
already
been
established
for
years,
build
it
and
then
you
can
see
you
know
it
comes
back
with
the
results
in
terms
of
whether
the
build
was
successful
or
not,
and
if
I
want
to
see
the
output
from
the
build
you
know,
I
can
issue,
use
the
same
script
and
issue
a
command
to
see
the
output
from
that
particular
build.
So
what
it's
doing
is
again
it's
downloading
the
build
output
to
the
IDE
so
that
I
can
actually
go
look
at
it
and
as
a
developer,
I
can
go
in.
B
And
here
we
go,
that's
what
that's
how
it
looks
like
now.
The
most
important
thing
to
notice
here
is:
the
comment
is
still
there,
so
just
to
prove
that
is
the
same
version
of
the
code,
that's
actually
being
built.
So
I
did
my
change.
I
validated
it
I
built
it
now,
I'm
actually
going
to
go
through
the
gate,
steps
of
committing
those
changes
and
pushing
those
changes
to
the
enterprise
repo.
B
B
B
So
that
you
know,
if
essentially
what
you're
seeing
here
is
the
same
good
workflow
right
for
Pete,
you
know
if
you
people
want
to
use,
want
to
actually
collaborate,
do
the
code,
reviews
and
things
like
that.
All
of
those
capabilities
are
still
intact,
and
you
know
anybody
who
understands
get
up
can
follow
the
same
set
of
principles
and
rules
that
have
been
established
while
still
working
with
the
mainframe
code,
so
it's
merged
in.
B
So
let's
confirm
that
it's
already
it's
in
there.
So,
as
you
can
see,
you
know,
or
the
comment
actually
made
it,
so
it
is
still
just
the
file
that
I
actually
modified
in
my
future
branch
and
the
last
step
right.
Let's
prove
that
it
is
actually
the
gate
bridge
has
done
its
job
of
synchronizing
it
back
with
the
mainframe
SCM
and,
as
you
can
see,
the
new
comment
that
we
added
in
there
is
in
the
repository.
B
So
that's
pretty
much
the
workflow
in
terms
of
how
you
know
the
user
is
actually
interacting
with
get
without
actually
knowing
what's
happening
on
the
back
end
and
that's
the
kind
of
modernization
that
we're
actually
bringing
to
the
table.
You
know
for
mainframe
organizations
and
taking
things
to
the
next
level,
and
all
we
are
doing
here
is
leveraging
open
source
tools
with
the
help
of
some
innovation,
like
the
Gate
Bridge,
that
we
that
we
did
and
bridging
the
old
world
to
the
new
world,
and
so.
A
What
we've
seen
in
some
of
the
keynotes
earlier
today,
leverage
of
the
ability
to
automatically
assign
code
reviewers
vyas,
just
the
core
capabilities
of
the
pull
request
and
then
get
those
changes
into
the
system,
much
more
quickly.
We're
able
to
branch
and
work
on
multiple
feature
branches,
at
once
in
mainframe
code,
which
is
a
very
new
capability
tackling
we
can
start
to
unblock
those
weeks
to
months
long,
deploy
queues
and
start
to
get
them
more
in
sync,
with
the
other
projects
that
are
being
built.
A
B
Essentially,
you
know
letting
the
mainframe
organizations
know
what
is
possible
right
and
the
existing
set
of
tools.
You
know
from
a
CI
perspective,
CD
perspective
can
be
leveraged
for
the
mainframe
core
as
well
right.
One
of
the
things
that
I
am
Phil
we're
talking
about
just
before
this
presentation
is
our
next
step
is
to
actually
incorporate
get
up
actions
into
this
particular
demo
and
pretty
much
go
through
the
whole
CI
CD
process.
Right,
that's,
which
is
possible.
You
know
we
just
didn't
get
there
exactly.
A
A
So
with
that,
we're
really
excited
to
be
able
to
share
this
story
with
you
today
and
if
you
have
any
questions
want
to
ask
us
anything
here
after
the
presentation
and
been
cut
and
I'll
be
around
for
a
while.
So
thank
you
very
much
everyone
for
coming
on
out
and
taking
some
time
to
learn
about
the
exciting
future
of
a
very
established
heritage
technology
and
how
we
can
continue
to
bring
new
people
onto
that
platform.
Thank.