►
Description
When you can build as one team, you can deliver a strong, unified vision for your business. But too often, different workflows across tools and teams require context switching, which can break momentum and slow down the entire software development process. In this session, you'll hear from Michael Yates, Head of Technology at Domain, and Russell Clarke, Engineering Chapter Lead at ANZ, about how you can increase developer happiness and productivity with GitHub Enterprise. They'll demonstrate how building a next-generation developer workflow can enhance and streamline the development experience by using GitHub Codespaces, GitHub Actions, GitHub Advanced Security, and GitHub Copilot together.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
A
Today,
I'm
super
excited
to
host
a
fireside
chat
focused
on
prioritization
of
the
developer
experience.
So
we
can
accelerate
the
high
quality
software
development,
as
mentioned
earlier
in
the
Keynotes.
If
you
had
the
chance
to
watch
it
in
today's
modern
economy,
there's
no
organization
that
can
grow
and
start
without
software
and
without
developers.
The
developer
is
at
the
heart
of
everything
and
at
GitHub
we
prioritize
developer
developers,
happiness
and
developer
experience.
A
A
My
name
is
fatenhiri
I'm.
The
corporate
Fields
service
manager
for
GitHub
in
APAC
I
am
based
in
Sydney.
Australia
I
have
been
with
GitHub
for
over
five
years
and
I've
got
more
than
14
years
of
experience.
That
sounds
like
I'm
very
old,
but
here
we
go,
and
all
of
that
is
around
technology
and
I
had
lots
of
different
roles
within
the
software
development
life
cycle.
A
Okay,
before
we
get
started
just
a
couple
of
housekeeping
items,
so
the
first
one
is
around
Q
and
A.
So
if
you
have
any
question
for
our
speakers,
make
sure
that
you
drop
them
in
the
Q
and
A
Tab,
and
also
today,
I
have
well
the
developer,
Advocate
Michelle
manilik,
you
might
know
her
as
well
as
the
hackathon
cream.
She
is
joining
us
to
keep
an
eye
and
help
with
the
qn
questions.
We
will
make
sure
that
we
will
cover
all
of
your
questions
towards
the
end
of
our
funnel
as
housekeeping
as
well.
A
A
Okay.
So
let's
get
started
just
one
more
thing
before
we
start
with
before
we
start
with
the
chat.
I
would
like
to
start
with
a
panel
just
to
get
an
idea
where
everybody
is
joining
us
from
today.
So
I'm
gonna
stop
sharing
my
screen,
so
we
can
start
with
the
first
poll
and
the
poll
you'll
be
able
to
see
it
at
the
right
hand.
A
Side
just
to
see
where
you
guys
are
joining
us
from
so
I
am
based
in
Sydney,
not
in
sedicity
I've
come
in
a
suburb
called
Castle
Hill
45
minutes
away
from
the
city
and
I
would
like
to
see
everybody
from
the
audience
where
they're
joining
us
from
I
will.
Let
you
answer
the
first
poll
and
in
the
meantime
we
will
start
by
getting
a
quick
introduction
from
our
speakers.
So
today
I
am
joined
by
Craig,
Michael
and
Russell.
Thank
you.
A
B
Thanks
Ben,
my
name
is
Craig
here
I
worked
at
Iris
I'm
as
a
platform
engineer
and
that's
my
current
role
as
a
platform
engineer
I've
actually
been
at
RS
for,
like
20
plus
years
so
I've
seen
a
lot
of
change
through
the
company
over
the
years
and
I've
been
through
a
lot
of
different
roles.
You
know
starting
off
as
a
bb6
developer,
to
all
the
way
up
to
you
know
deploying
into
Cloud
environments.
B
You
know
using
terraform
and
things
like
that.
Yeah
Iris,
some
people
might
not
know
what
rsc's
RS
we
just.
We
provide
software
and
online
services
to
the
a
lot
of
financial
arm
Industries
around
like
trading
and
wealth
management
and
lending
and
superannuation
risk
all
that
type
of
stuff
yeah
save
it
yeah.
So
I
I've
my
current
role
of
the
platform
engineer
we
actually
look
after
our
address.
B
We
would
like
to
give
the
the
rest
of
like
a
lot
of
developers,
a
good
footprint
to
start
off
with,
so
they
don't
have
to
repeat
the
same
things
over
and
over
again
to
make
sure
and
also
make
sure
they're
doing
the
right
thing
consistently.
We
also
look
after
a
lot
of
CR,
City,
tooling
and
Source
control
and
artifact
management
and
and
other
cross.
A
C
C
So
domain
group
is,
you
know:
150
160
software
developers,
we're
a
you
know:
350
million
dollar
company
and
the
most
famous
thing
that
we
you
know
produce
is
domain.com.
So
a
lot
of
people
would
have
seen
that
on
the
side
of
the
bus,
if
you're
in
in
Sydney
and
that's
a
property
portal,
we
also
sell
services
to
the
real
estate
industry,
to
Banks
and
and
to
government.
So
that's
what
we're
about
so
my
role.
C
D
D
You
can
check
your
spend
and
a
lot
more
features.
So
you
know
it's
a
new
app
new
new
way
of
of
banking
and
and
the
the
way
that
kind
of
demand
that
we've
been
giving
us
to
produce
everything
in
a
cloud
first,
SAS,
first
and
GitHub
is
a
big
part
of
what
we
do
so
my
team.
We
managed
the
the
CI
CD
tools,
github's
part
of
that
there's.
D
A
A
Yeah,
okay,
cool!
Thank
you.
So
I
just
want
to
say,
of
course,
good
morning
good
afternoon,
good
evening,
depending
on
where
you're
joining
us
from,
but
so
far
it
seems
that
most
of
our
audience
are
from
APAC
and
the
highest
one
is
from
India
as
well
as
southeast
Asia
and
Australia
New
Zealand.
Thank
you
all
for
joining
us.
Thank
you
all
for
dialing
in
and
listening
to
us,
okay,
so
I'm,
not
gonna
overdo
it
with
the
pause,
but
I
still
would
like
to
have
another
question
that
will
help
us
start.
A
The
conversation
for
this
fireside
chat
and
I
would
like
to
start
stop
sharing
and
the
result
of
the
first
poll
and
ask
the
audience
as
well
as
how
many
tools
are
you
using
today
as
part
of
your
software
development
tool
tooling?
So
what
how
many
tools
are?
Your
is
your
team
using
today.
So
while
you
are
answering
this
poll,
the
second
poll
is
open
right
now,
yeah,
while
you're
all
answering
the
second
thought.
I
would
like
to
now
ask
a
question
to
our
audience
to
our
speakers.
Sorry.
D
So
by
using
by
kind
of
integrating
everything
with
GitHub,
we
can
kind
of
shift
left.
As
we
like
to
say,
you
know,
testing
building,
you
know
through
GitHub
actions
we
can.
You
know
we
can
have
checks
on
pull
requests,
doing
things
like
note,
minting
or
or
running
automated
tests
in
in
RCI.
So
it
really
is.
You
know
the
central
tool
that
all
our
other
tools
integrate
with
that's
that's
pretty
much.
How
we,
how
we
see
it.
D
Doesn't
do
everything
there's
a
lot
of
other
tools
we
use
as
well
and
and
for
those
tools?
What
we
look
at
one
of
the
primary
things
we
look
at
is:
how
does
it
integrate
with
GitHub,
because
that's
the
developer
experience
right?
That's
the
primary
interface
that
Engineers
uses
the
interact
with
with
Git,
either
through
CLI
vs
code,
extensions
whatever,
but
they
all
end
up
going
through
through
GitHub
when
you,
when
you
come
in.
D
A
C
I
think
quite
similar
to
Russell
in
that,
obviously
we
started
with
GitHub
primarily
as
Source
control
SCM,
as
as
many
many
do
I
think,
probably
maybe
slightly
different,
so
we're
using
actions
as
a
secondary
or
tertiary
build
system,
so
we're
a
little
bit
newer
to
to
action.
So
we
had
some
CI
CD
fairly.
C
You
know
well
set
up
CI,
CD
already
and
so
actions
when
that
arrived,
we've
moved
some
workloads
there
that
make
sense,
but
it's
not
our
our
primary
cicd
in
terms
of
other
other
components
of
GitHub
we're
using
we're,
certainly
using
packages
quite
a
lot.
So
packages
is
pretty
much
our
go-to
for
for
artifact
management.
C
C
What
are
those
Enterprise
management
features,
look
like
and
can
it
hook
into
the
you
know
the
next
Downstream,
the
next
Downstream
piece
and
for
us
when
we
look
at
GitHub?
The
answer
is
yes
to
those
things.
So
can
it
hook
into
a
variety
of
tools?
Yes,
does
it
provide
us
some
level
of
Enterprise
oversight?
Yes,
and
is
the
platform
expanding
to
cover
new
work
types
as
they
become
available,
and
the
answer
is
yes,
so
where
we
started.
C
Obviously,
with
a
simple
use
case,
we've
started
pushing
into
actions
and
package
management
and
Enterprise
management,
because
it
it
hooks
in
really
well
to
such
a
wide
variety
of
tools.
So
that's
kind
of
our
use
case
I'm,
not
sure
whether
you
wanted
to
pass
the
same
question
to
Craig
or
or
back
to
you.
B
Yeah
sure
so
we
I
think
it's
about
I
think
it's
about.
Five
years
ago
we
started
this
journey.
We
had
like
everything
you
know
behind
the
great
corporate
firewall,
and
you
know
the
developers
want
a
little
bit
more
freedom
and
we
also
wanted
to
integrate
and
use
a
lot
of
other
tools,
but
some
of
those
tools,
the
you
know
the
internet
facing
their
SAS
facing,
and
then
we
also
started
realizing
that
some
of
these
things
about
managing
on-prem
and
managing
operating
them
and
managing
the
hardware
it
just
switches.
B
We
don't
have
time
to
do
all
this.
It's
just
annoying.
You
know,
we've
got
other
things
more
important
to
do
so.
We
started
on
a
journey
where
we
moved
out.
We
made
our
issue
tracker
system
sort
of
a
little
bit
more
exposed
to
the
internet,
securely,
that's
explosive.
We
can
use
it
and
then
we
decide
well.
Can
we
do
the
same
thing
with
Source
control?
We
had
Source
control
internally,
and
so
then
we
ran
this
discoveries
like.
How
would
this
work
and
how
would
this
happen?
How
would
we
be
comfortable
with
this?
B
Is
it
going
to
be
secure
enough,
and
so
we
ended
up
Landing
on
yeah
using
GitHub
Enterprise
Cloud
I
mean
there
was
only
at
the
time
there's
only
the
two
options
you
either
do
GitHub
on-prem
install
it
yourself
or
use
the
cloud
one
we
didn't
want
to
manage
it
so
go
for
the
cloud
one
and
so
yeah.
We
we
set
it
up
and
I'm
over,
like
I,
think
I
think
about
a
month
or
something
we've
got
everyone
to
just
move
all
their
repositories
across
and
just
continue
working
and
I.
B
Think
that's
one
of
the
good
things
about
git.
Sometimes
because
git
is
like
just
get
pulled,
get
push
and
off
you
keep
going
to
some
extent,
so
yeah
we've
made
sure
there's
a
lot
of
guardrails
in
there
there's
it's
all
backed
by
SSO
off.
You
know
OCTA
and
things
like
that,
so
you
can't
get
in
there
without
being
properly
authenticated.
B
B
There's
like
5,
000,
plus
repositories
and
all
their
repositories
are
under
one
organization
that
we
just
we
kind
of
separate
things
between
we've
got
an
organization
which
we
consider.
Everything
in
here
has
to
be
private,
that's
our
own
private
one,
and
that
and
it's
the
repository
where
all
the
main
work
goes.
That's
like
production
work,
then
we
have
another
organization
that
actually
has
a
book
called
like
a
Sandbox
fund
develops
can
go
on
there
and
create
stuff.
B
We
don't
care
that
that's
just
them
to
play
around
with,
but
we
just
try
and
keep
them
separate,
because
otherwise
we
just
end
up
with
a
complete
mess
in
the
one,
and
then
we
have
our
public
facing
always
the
public,
with
the
public
facing
repositories
just
to
keep
things
separate.
I
know
we
could
probably
put
it
all
in
one,
but
it
just
makes
it
very
clear
to
the
developers.
That's
that's
the
way
it
works.
B
When
we
first
joined
GitHub,
there
was
no
actions.
There
was
no
packages,
there
was
no
Advanced
security
and
that
stuff,
so
we
had
to
you,
know,
use
other
tools.
So
you
know
we
use
another
tool
for
Ci
City,
primarily,
and
we
at
the
moment
we're
quite
ingrained
with
that,
because
we've
set
up
in
a
very
secure
way,
but
we
have
talked
about
numerous
times
about
what
could
be.
B
Could
we
leverage
GitHub
actions
for
our
numerous
things,
and
there
is
always
that
possibility
and
teams
do
use
it
for
doing
certain
things
like
it's,
so
the
Market's
great
for
them
to
just
use
it
just
to
orchestrate
things
within
GitHub.
You
know
if
someone
opens
a
PR
write,
an
action
to
go,
do
something
against
that.
It
doesn't
make
sense
to
boot
up
our
Ci
City
system
to
go
and
do
that.
It's
just
like
you
know
like
get
taking
a
the
gorilla
tour
yeah.
A
B
The
workload
and
we
we
do
depend
on
Dependable.
That's
been
great
in
terms
of
integrate
that
a
lot,
and
that's
been
great
too,
because
we've
been
able
to
integrate
that
through
our
artifact
system,
because
that
was
also
something
we
had
existing
and
we've
managed
to
in
scratch
that
so
they
can
get
updates
for
the
artifacts
that
we
create
in
addition
to
the
public
ones
and
event
security.
B
We
have
play
around
a
little
bit,
we're
still
trying
to
get
get
there
in
terms
of
getting
on
board
with
that,
but
they're,
all
things
I
think
they're,
all
the
great
features
of
getting
everything,
working,
alright
and
I.
You
know
recommend
anyone.
Who's
like
starting
out
just
use
the
features
that
are
there.
Don't
start
only
start,
looking
a
bit
further
than
that,
if,
if
they
don't
quite
fit
your
use
case,
but
yeah.
A
Yeah
very,
very
good
point,
and
the
common
thing
from
the
the
answer
is
like
GitHub
is
the
base
making
sure
that
whatever
you're
using
can
integrate,
as
well
as
exploring
the
existing
features
and
tools
that
you
have
available
within
within
GitHub
at
the
moment
as
well?
As
you
said,
it
started
as
a
place
to
store
your
code,
but
not
it's
evolved
way
more.
It's
about
GitHub,
Advanced
security.
A
You've
got
like
GitHub
actions
for
automation,
for
CI
packages,
the
project
management
tool,
GitHub
project,
as
well
as
like
code
spaces
and
go
Partners,
we'll
talk
about
that
a
little
bit
later,
but
let's
share,
let's
close
the
port.
Thank
you.
Everyone
for
answering
the
poll
I
will
close
it
and
share
the
answers
to
the
second
poll,
which
is
around
the
number
of
tools.
Can.
Can
you
see
the
four
results
yeah?
A
So,
as
you
can
see,
we've
got
the
highest.
One
is
one
to
five
and
then
followed
like,
which
is
I,
think
very
acceptable
as
well
as
realistic,
because
as
you
as
we
all
know,
that
consolidating
tools
is
like
one
of
the
things
that
is
everybody's
goal.
But
in
reality,
when
it
comes
to
real
life
and
to
practice,
some
of
the
teams
might
be
in
the
process
of
working
toward
that
goal.
A
But
in
the
scenarios
where
we
have
to
adopt
and
take
other
tools,
make
sure
that
the
can
integrate
within
each
other,
they
can
talk
with
each
other.
Thank
you
all
for
answering
this
poll,
and
any
any
comment
from
the
speakers
on
the
body
sauce.
Is
that
something
that
you're
expecting
or
like?
Was
it
like
a
bit
of
a
shock.
B
I
think
excess
tools
that
we
need
to
consolidate
and
that
has
also
yeah
come
from
mainly
from
Acquisitions
and
then
and
then
you
know
trying
to
get
around
to
moving
them
into
another
platform.
Sometimes
it's
difficult
because
sometimes
they're
under
the
pump
and
pressure,
and
they
don't
have
time
to
do
it
and
but
yeah.
B
You
have
the
worse,
it
gets
because
I've
had
situations
where
you
know
everyone
like
say.
For
example,
we've
got
one
artifact
system,
but
we've
got
all
these
CRC
tools
and
they
all
need
to
integrate
with
it.
They
all
need
credentials
and
when
we
need
to
rotate
them,
we've
got
to
run
through
all
these
tools
to
fix
it
up,
and
it's
just
a
real
pain
like
the.
C
One,
the
one
thing
I'd
guess
is
I'm
I'm,
not
imagining
any
individual
developers
interacting
with
30
tools,
I
think
it
was
about
five
people
who
said
30
tools.
My
guess
is
Russell
Craig
and
I
probably
do
have
more
than
30
tools
under
our
remits.
I'm,
Reckoning,
I
I
think
there
might
be
five
other.
You
know
head
of
platform
type
people
on
not
on
that
poll
and
I
would
say
that
they're
likely
to
be
the
ones
who
are
in
that
30
plus
I
would
hope.
C
D
Were
like
we're
a
green
fields
project,
so
we've
we've
started
with
a
few.
We
are
expanding,
they
didn't
know
the
the
broader
ANZ.
There's,
definitely
definitely
going
to
be
people
with
30
plus
category,
so
yeah
Craig
I
was
also
he's
like.
Oh
that's,
that's
a
lot.
Then
I
was
thinking
yeah.
What
what
you
know?
What
do
people
think
when
they
answer
this
question
I
can
see
there
is
yeah.
If
you,
if
you
start
looking
into
it
properly,
count
I
can
probably
at
least
count
15..
D
A
Okay,
thank
you
for
that
I,
just
wanna
open
one
more
call.
So
that
way
we
can
keep
the
conversation
going
and
this
one
is
around
the
CI
CD
tools
that
you
are
using
regularly.
So
we
have
GitHub
actions
as
part
of
GitHub
and
with
GitHub
Enterprise
like
you
get
50
000
minutes
available
for
you
to
use
GitHub
actions
and
we've
got
other
tools.
I
just
wanted
to
see
what
are
the
tools
that
the
audience
are
using,
so
I
just
opened
the
poll
as
right
now.
A
So,
if
you
can,
please
give
us
your
answers
in
the
poll
Tab
and
in
the
meantime,
I
just
want
to
ask
Russell.
Please
so
I
know
that
you,
you
come
from
a
banking
industry
from
a
very
regulated
industry.
I
just
want
to
see
how
were
you
able
to
enable
your
team
to
use
like
GitHub,
Enterprise
cloud
and
like
SS,
offering.
D
Yeah
yeah,
that's
good,
because
when
I
joined
ANZ
we
were,
we
were
not
using
the
cloud
at
all.
We
were
Now
using
SAS
products.
That
was
only
a
few
years
ago
and
again,
you
know
kind
of
180
degrees
in
in
the
past
few
years,
where
you
know,
if,
if
you're
not
doing
things
on
cloud,
then
it's
it's.
You
know
kind
of
question.
Why
why
you
know
why
we're
using
a
SAS
product
or
something?
And
it's
yeah?
It's
interesting.
D
How
that's
that's
changed
so
I
think
Craig
mentioned
some
some
of
the
things
that
that
Iris
uses
so
things
like
that.
You
also
use
Enterprise
Cloud,
which
is
essentially
you,
know
the
github.com,
but
there's
a
there's,
an
Enterprise
layer
which
lets
you
put
some
management
over
your
your
organizations,
so
we
also
enforce
SSO
and
and
2fa
on
all
our
accounts.
Okay,
a
basic
thing
we
can
do
to
just
just
lock
down
access
to
to
the
orgs,
but
even
even
that's
not
enough.
D
It's
kind
of
there's
there's
a
lot
of
features
of
GitHub.
We
want
people
to
use
GitHub
actions,
and
that
was
one
of
our
primary
reasons
for
using
Enterprise
Cloud
back
when
we
started
actions
was
not
available
for
for
GitHub
Enterprise.
So
like
this
was
the
the
analysis
done.
This
is
the
only
option
that
really
that
really
worked
so
like
in
a
hack
Queen.
How
can
we
secure
Enterprise
Cloud,
so
we've
we
could
have
actions
by
default.
D
You
you
run
your
workflows
on
on
GitHub,
provides
the
runners
get
our
posted
runners,
so
the
workplace
run
on
on
Google's.
You
know
back-end
Cloud
to
do
that
to
run
the
workflows
but
they're,
essentially
public
internet
facing
which
is
something
we
we
don't
want.
So
GitHub
provides
the
self-hosted
Runners
option,
so
you
basically
spin
up
your
own
Runners
and-
and
we
primarily
use
Google
Cloud.
So
we've
got
a
Google
Cloud
VMS
that
we
register
with
GitHub
and
and
they
run
out
our
workloads.
D
So
that's
one
of
the
one
of
the
things
we
do
and
then
there's
those
VMS
are
behind
our
firewall
and
they
have
to
proxy
out
of
the
internet
stuff.
So
we
can
control
egress
and
make
sure
we
don't
we're.
Looking
at
control
traffic
to
those
to
those
VMS,
we've
built
a
lot
of
configures
code,
so
one
is
just
helps
maintenance.
We
don't
need
to
maintain
things.
You
know
through
through
click
Ops,
especially
like
a
team
of
like
600
Developers.
D
So
we've
done
a
lot
of
conflict
of
code
config
as
code
we've
bought
some
wrappers,
which
encapsulate
the
the
apis.
So
things
like
repo
management,
user
management
teams
are
all
done
through
through
code
and
then
because
of
that,
when
we
can,
we
can
actually
limit
access
to
some
of
the
features
so
to
a
bit
of
a
double-edged
sword.
D
If
there's
a
new
feature
available
in
order
to
then
I,
don't
know
repo
environment
or
something,
then
you
know,
we
need
to
update
our
code
to
support
that,
but
at
the
same
time
it
lets
us
control
what
you
know.
What
what
what
features
the
team
uses.
So
it's
kind
of
a
constant
back
and
forth.
We
get
you
know
we
get
our
Engineers.
You
know
I
get
requests
every
week.
People
think
I've
heard
about
this
new
GitHub
feature
or
you
know,
I
know
if
they
can
kind
of
use.
D
C
One
of
the
ones
that
we've
just
picked
up
on
Russell-
you
talked
about
Runners
just
before
so
we
use
the
the
default
Runners
that
come
with
GitHub
the
50
000
minutes
for
some
workloads.
We
actually
had
a
restriction
just
recently
where
we
needed
our
runner
to
talk
on
a
fixed
IP,
essentially
through
to
another
platform
snowflake
in
this
case,
and
we
didn't
want
it
to
have
a
a
moving
IP
and
there
is
actually
a
feature
I'm,
not
sure.
C
A
A
A
A
C
So,
for
the
audience
domain
still
is
a
is
a
large
Jenkins
user
and
when
I
mentioned
that
to
Russell
and
Craig,
they
were
very
surprised
that
how
how
ingraine
Jenkins
was
to
our
pipeline
so
I
think
to
your
previous
question.
You
know
how
surprised
are
people
I,
think
Craig's,
probably
pretty
surprised
at
the
the
high
up
Jenkins
is
in
in
in
people's
current
workloads,
yeah.
A
C
A
D
Thing,
no
one,
no
one
likes
doing
a
migration
right
and
you
know
Jenkins
is
a
it's
all
once
you've
got
it
and
you
set
it
up
and
it
does
its
job,
it
works
and
I'm
sure
I
would
would
agree.
Actions
is
a
better
tool,
but
you
know
biting
the
bullet
and
doing
that.
Migration
is
not
in
there.
Not
always
an
easy
ask
right.
Yeah.
A
B
B
Had
an
experience
recently
where
we
had
internal
team,
they
were
still
using
bamboo
and
I'm,
trying
to
convince
him
just
moved
to,
because
we
use
build
guides,
just
moved
to
build
cut
and
they're
like
oh,
it's
gonna
be
too
hard.
This
is
not
going
to
work.
This
is
not
going
to
work.
How
are
we
going
to
do
this?
How
we're
going
to
do
that
and
it's
like
I
just
I-
just
talk
them
through
it
and
eventually
they
they
started
it
and
they
said.
Oh
actually,
this
is
not
too
bad.
A
Thank
you
for
sharing
I'm,
just
gonna
switch
gears
a
little
bit
now
and
talk
about
a
new
higher
onboarding
experience,
we'll
hear
from
our
audience
via
the
poll
as
well.
So
I
will
open
another
book
to
get
an
idea
about.
How
long
does
it
take
for
a
new
hire
on
your
team
to
start
committing
code
to
start
being
productive
and
doing
great
work
as
well
as,
at
the
same
time,
I
would
like
to
hear
from
our
speakers
about
the
hiring
The
onboarding
Experience
within
your
company.
Would
you
like
to
start
Craig.
B
Sure
I
think
as
long
as
stars
are
aligned
and
the
new
hire
is
being
added
to
the
right
groups
in
the
first
day,
the
first
time,
although,
if
they
weren't,
we
can
actually
get
them
out
of
that
day.
They
would
get
pretty
much
straight.
Access
into
GitHub,
they'll
just
have
to
then
just
connect
up
either
their
own
GitHub
account
or
they
can
create
their
own
some.
B
We
know
some
users
decide
to
create
their
own
separate
one,
because
they
want
to
keep
a
separation
between
the
work
and
their
home
and
their
home
life,
but
generally
yeah
they'll
get
access.
They
go
get
straight
into
the
org.
They
can
create
they're
assign
the
sh
key.
They
can
then
I
will
authorize
it
to
you
know
to
bypass
the
SSO,
so
they
can
start
cloning
and
they
can
pull
something
and
they
can
open
for
requesting
compute
pretty
much.
On
the
the
same
day.
B
Sorry,
it
could
be
pretty
fast.
I
mean
we're.
Also
we've
been
trying
to
at
ice
when
we
onboard
people.
Now
we
try
and
make
sure
there's
a
bit
of
work
for
them
to
actually
even
start
with
within
the
first
day
or
at
least
the
first
week,
so
that
they
can
actually
contribute,
because,
if
the
faster
you
get
something
to
contribute,
then
the
the
faster
they
feel
a
part
of
the
the
team
part
of
the
company
and
feel
productive
they're.
Doing
something
productive.
C
That
was
something
that
they
wanted
and
something
that
we
wanted
to
enable.
So
we
have
a
probably
a
less
restrictive
environment,
I
suppose
in
some
of
the
banking
environments,
we
don't
force
people
to
create
a
new
GitHub
handle
specifically
for
the
org
and
we're
just
working
on
that
sort
of
automation
all
the
way
through
so
the
the
onboarding
from
the
the
first
day
through
to
OCTA
and
then
down
to
the
team.
C
C
We
just
need
those
sort
of
team
and
and
groups
set
up
properly
in
GitHub,
essentially
by
the
team,
and
then
we
can
map
that
all
the
way
through.
We
also
Target
around
that
first
day
getting
somebody
in
up
in
an
operation.
Also,
that's
everything
from
we
issue
laptops.
You
know
and
that's
all
one
click
provisioning
so
from
signing
into
your
laptop
all
the
way
through
to
to
getting
some
code
committed
we
target
a
day,
but
I,
don't
think
everybody
makes
a
day
and
I'll
be
completely
honest.
C
A
D
Yes,
of
course
so
I
mentioned,
we
have
a
lot
of
a
lot
of
configures
code,
so
onboarding
a
lot
of
it
is
a
matter
of
adding
adding
users
to
the
right
groups
and
raising
a
pull
request.
So
we
kind
of
need
to
bootstrap
that
for
them
and
we're
working
on
we're
actually
working
a
project
right
now
to
simplify
onboarding
once.
C
D
Have
that
voted
that
usually
takes,
you
know
less
than
half
a
day
or
so
then
they
are
provisioned
and
depends
on
the
team,
but
within
platform
we
give
everyone
an
onboarding
exercise,
that's
essentially
a
kind
of
a
Hello
World
exercise,
but
the
the
main
point
is
to
make
sure
they
do
have
access
and
they
have
they.
They
can
use
all
the
all
the
tools
you
know
have
a
Docker
set
up
and
everything
so
usually
the
onboarding
exercise,
people
complete
it
within
a
couple
of
days
and
then
after
that,
then
writing.
D
A
We've
got,
we've
got
63
a
week
and
one
day
we've
got
only
17
percent
I
think
for
the
one
month
and
larger
than
a
month.
I
think
there's
lots
of
room
for
improvement
here
to
reduce
that,
because
we
are
talking
about
developer
experience
and
the
onboarding
is
like
the
new
hire
or
the
developers.
First
experience
I
think
we
can
help
remove
lots
of
these
friction
via
like
when
it
comes
to
their
entitlement
to
Via
SSO,
as
well
as
like
via
other
tools
like
we've
got
code
spaces.
A
B
So,
if
you're
going
up
to
away
if
it's
within
a
week,
I
think
you're
doing
okay,
get
try
and
get
through
that
day
or
two
there's.
It's
kind
of
the
goal
the
month
and
longer
than
a
month
I'll
be
curious
about
what
why
that
is
like
is
that
is
there
because
there's
only
training
involved
before
they?
They
start.
Is
that
the
reason
why
or
other
complexities
GitHub,
maybe
just
developed,
getting
a
laptop
or
getting
a
PC
or
other
things
on
to
that?
To
that
developer,
yeah.
C
You
know
very
structured
onboarding
before
you're
actually
even
allowed
to
look
or
touch
the
code,
so
I'm
imagining
security
or
defense
or
some
of
these
types
of
things,
maybe
there's
some
security
people
but
I
think
the
opportunity
in
that
that
one
week
space
you
know
if
you
can
reduce
that
one
week,
space
I
think
there's
a
huge,
huge
amount
of
opportunity
there
really
thinking
about
the
onboarding
and,
what's
you
know
what
are
the
hold?
Ups?
There's
definitely
possibilities.
So
we
don't
use
code
spaces
as
an
example.
C
We
issue,
you
know
pretty
laptops
to
all
our
developers,
but
you
know
to
be
honest:
it's
something
we
should
probably
experiment
with
to
get
people
on
quicker,
while
they're
setting
up
the
the
more
structured
environment.
So
there's
certainly
knowledge
and
learning
that
you
can
do
to
explore
the
code
and
understand
the
code
through
something
like
code
spaces
before
you.
You
know
you
might
want
to
compile
locally
as
an
example,
so
it
might
be
something
that
we
should
look
at
actually
as
well.
So.
B
There's
nothing
weird
thought
about
code
spaces,
I,
think
it's
people
because
it
means
you
know
like
you're,
providing
these
expensive,
more
powerful
laptops,
and
sometimes
each
developer's
got
varying
degrees
of
what
they
actually
really
need.
And
so,
if
you,
if
you
off
offload
that
to
a
code
space,
it
means
you
can
give
them
a
simpler,
lighter
device
to
carry
around
and
they've
got
all
the
power
they
can.
They
can
get,
they
can
get
in
the
cloud
and
mix
their.
C
Experience
a
lot
easier
and
remembering
I
I
do
the
I.T
side
as
well,
so
remembering
that
for
a
lot
of
us,
the
normalizing
means
you're
actually
on
the
highest
common
denominator,
so
yeah
you're
going
to
buy
you
know
three
and
a
half
thousand
dollar
laptops
to
try
and
get
them
to
last.
You
know
two
three
years,
that's
fairly
expensive
when
you're
talking
I
mean
both
you
Russell
and
Craig
have
way
more
developers
than
I
do,
but
that
gets
quite
expensive
when.
D
C
B
We've
been
going
through
trying
to
align
with
the
essential
eight
and
one
of
them.
One
of
the
pillars
is
to
be
non-admins
on
anywhere.
So
you
know
as
a
nine
minute
on
laptop
for
a
developer.
It
can
make
life
extremely
difficult
if
certain
things
aren't
in
place
to
help
out
with
that.
So
you
know
maybe
the
solution
to
that
East
Coast
space.
A
Yeah
we're
adding
lots
of
policies
as
well
for
code
spaces
to
make
it
even
like
safer
and
more
secure
place
than
having
anything
on
the
developer
machines,
because
that
will
be
even
better
and
safer.
Okay,
I
have
a
question
for
Craig.
You
mentioned
previously
that
you
had
to
go
through
a
migration
exercise
to
GitHub
Enterprise
cloud
and
start
start
your
SAS
Journey
and
coming
from
on-prem.
Can
you
tell
us
a
little
bit
more
about
the
migration.
B
Yes,
I
mean
we,
we
yeah
we're
using
it.
On-Prem
like
losing
your
bucket
server,
yeah
I'll,
say
it,
but
we're
using
on-prem
and
everyone
was
in
there
and
everyone
was
you
know
coming
on
great,
but
then
you
know
we
wanted
to
open
it
up.
So
it's
like
well,
how
are
we
going
to
move
all
these
repositories
into
GitHub
and
then
we'll
had
a
looming
deadline
come
in
because
our
license
was
starting
to
run
out.
We
didn't
want
to
renew
it,
so
it's
like
I
had
a.
B
How
are
we
going
to
do
this
so
I
mean?
Unfortunately,
I
took
a
bit
of
a
sledgehammer
approach
to
it.
I
think
there
was.
There
was
some
tooling
available
to
help
with
the
migration
from
GitHub.
It
would
mean
I
think
it
reads
it
go
for
that.
Was
it
the
extra
Services
the
external
services,
to
help
out
with
that,
because
the
tooling
wasn't
available
to
us
directly,
which
has
changed
now.
Everyone
can
actually
there's.
B
However,
they
want
so
it
makes
it
which
we
have
used
for
another
CAT
use
case.
It
does
work
really
well,
but
yeah
pretty
much.
We
had
a
space
of
like
I
think
a
month
and
at
the
end
of
the
day,
just
it
was
just
simply
just
simply
turned
around
and
said:
let's
see,
okay,
everyone
you've
got
a
month
to
move
your
repositories
across.
So
a
lot
of
them
just
get
push
get
or
get
pulled,
get
pushed
leave.
You
have
to
leave
all
your
PR's
behind.
B
You
can't
bring
them
across
it's
too
difficult
to
try
and
get
that
query
that
stuff
out
of
your
bucket
and
get
it
into
GitHub
and
online
at
all,
and
so
for
a
lot
of
teams.
I
complained
about
it.
I
mean
it
was
one
of
the
best.
We
probably
could
have
scripted
a
bit
better,
but
we
were
running
out
of
time,
but
they
managed
to
get
over
the
line.
You
know
pretty.
C
B
B
C
B
Oh,
we
want
to
bring
all
our
history
well,
there's
all,
and
we
want
to
bring
all
this
with
us
we're
going
to
bring
all
that
with
us
like.
How
often
do
you
need
to
go
back
that
far
and
then
you
know,
and
this
kind
of
prove
that
we
left
all
these
pull
requests
behind
him
still
kept
going
like
it
was.
It
wasn't
too
big
of
a
deal
but
I
think
if
you
did
now,
you'd,
probably
just
try
it
you'll
try
and
pull
that
stuff
across
as
much
as
possible.
I.
B
Right
because
we've
still
actually
got
bitbucket
server
running
in
our
read-only
mode,
because
I'm
licensed
and
we're
being
sort
of
just
ignoring
it
for
a
bit,
and
it's
it's
come
to
this
series
like
this.
Yet
we
have
to
turn
it
off
so
gotta
go
in
there
delete
as
much
as
things
that
don't
need
to
be
in
there
anymore
and
then
archive
copy
and
archive
to
GitHub
the
rest
of
it,
so
that
we
don't
lose
anything
because
I
know
there's
some
stuff
there.
B
B
That
yeah,
it's
also
mapping
I
suppose,
because
you
had
like
in
people
it's
projects
and
then
repositories,
but
in
GitHub
it's
just
it's
the
repositories,
so
it's
like
if
we
brought
them
across
that
we
end
up
there
with
name
collisions.
If
we
and
things
like
that,
so
we
led
up
to
the
teams
to
bring
them
across
and
we
wanted
to
also
to
fix
their
repository
names
because
they're
all
over
the
place,
I'm
trying
to
get
some
sort
of
consistency,
Navy
convention,
but.
B
I
think
watch
out,
for
is
the
size
of
repository
without
issues
with
some
teams
had
large
files
checked
in
and
we
could
we
managed
to
get
in
there
and
be
a
bucket,
but
we
could
not
push
it
into
GitHub
and
had
to
rewrite
history
to
get
rid
of
it,
and
that
was
a
bit
of
a
pain
Point
but
yeah.
It's
it's
what
you
have
to.
A
B
A
Thanks
for
sharing
I
can
tell
that
the
migration
journey
is
way
better,
because
the
time
that
I
just
had
it
was
at
early
stage,
but
now
we've
got
Services.
We've
got
partners
with
our
own
Professional
Services
team
will
be
happy
to
help.
We've
got
our
partners
as
well
as
Tools
in
place
and
question
for
Michael.
A
C
C
You
know
we
have
to
go
on
a
on
a
journey
with
the
bit
bucket
migration,
so
I
might
take
some
tips
from
from
Craig
or
use
that
beta
I
think
the
the
primary
thing
is:
whenever
there's
an
acquisition
and
it's
coming
into
into
the
organization,
you
have
to
look
at
what
tools
you
currently
have
what
the
setup
is
in
the
in
the
other
company
and
make
a
call
in
a
lot
of
cases.
You
know
to
Craig's
point:
do
you
leave
some
of
that
behind?
C
Is
there
stuff
you
actually
want
to
migrate?
I
think,
what's
important
in
in
the
domain
context,
isn't
necessarily
important
in
other
contexts
and
vice
versa.
One
of
the
most
important
things,
though,
for
us
is
as
especially
if
the
the
acquired
company
has
software
developers
they're
all
coming
in
and
seeing
the
domain
group
software
pretty
much
straight
away.
C
You
know
from
from
fairly
early
on
those
developers
can
come
in
and
see
the
catalog
of
services
domain's
been
around
more
than
20
years,
and
we've
got
a
lot
of
internal
services
that
do
interesting
things
with
property
data,
or
you
know
interesting
services.
So
I
think
what
what
do
you
do?
You
catalog?
You
have
a
look.
You
set
up
migration
programs.
Is
there
challenges?
Yes,
but
a
lot
of
them
are
overcome
because,
most
you
know,
small
medium
companies
have
one
of
some
of
the
major
tools.
C
We've
not
done
a
lot
where
the
acquiring
you
know
the
acquired
company
has
been
in
GitHub
so
which
is
interesting
just
as
of
note
but
yeah.
That's
how
we
sort
of
approach
it.
We
have
a
look,
we
catalog
it
out
as
and
when
you
know,
I
think
a
few
people
here
have
mentioned
in
passing
contracts
coming
up
to
end
dates
and,
and
that
I
think
that's
always
a
good
trigger,
because
nobody
likes
to
pay
for
two
two
tools
at
once
and
then
once
the
source
control
is
over.
C
We've
spoken
a
little
bit
today
about
that
concept
that
it's
then
possible
to
take
github-based
source
code
and
hook
it
back
into
the
existing
Ci
or
CD
of
of
the
company,
and
so
you
don't
actually
have
to
migrate
the
entire
tool
set
from
a
company
into
the
center.
You
can
actually
start
with
the
source
code,
bring
it
into
GitHub
and
then
still
back,
connect
to
the
you
know.
A
A
E
D
Well,
yeah,
so
for
us
it
was
at
the
time
it
was
it's
a
it's
a
tool
that
a
lot
of
our
Engineers
already
use
for
their
personal
projects.
So
it's
a
lot
of
a
lot
of
Engineers
use.
I
started.
You
know
they
like
doing
their
personal
projects
in
their
spare
time.
They
store
their
code
on
their
personal
GitHub
repositories
and
then
just
take
advantage
of
GitHub
actions
for
the
CIS
as
it's
built
in
so
a
lot
of
the
engineers
enjoyed
that
experience,
and
so
we
thought
well,
you
know,
how
can
we?
D
D
C
B
Okay,
yeah
I
mean
I'll,
say
I
mean,
like
I
said
we
we
first
came
out
to
get
up.
There
wasn't
any
kind
of
action,
so
we've
centered
on
another
tool
for
this
time
being,
but
we
we
keep
looking
at,
get
up
actions
and
we
keep
thinking
you
know
this,
but
for
some
cases
cases
it's
better
to
keep
it
yeah
in
GitHub.
B
That's
all
I
want
to
stay
yeah,
like
you
said,
there's
no
point
going
out
to
fire
up
a
CR
City
for
us
running
a
simple
script
and
they
could
just
run
it
as
a
quick
action
and
get
a
result,
especially
if
it's
like
for
a
check
or
so
for
a
PR
check
or
something
that
would
come
at
any.
So
that's
where
we're
using
it
more
predominantly,
but
I
think
over
time.
We
may
look
at
it
and
use
it
a
bit
more
extensively.
E
Fantastic
thank
's
answers.
Now.
We've
probably
got
time
for
one
more
question,
but
we
know
if
you've
seen
in
the
news
and
the
media.
One
of
the
big
hot
topics
right
now
is
AI
and
artificial
intelligence.
I've
got
quite
a
few
questions
in
the
chat
about
this,
but
I've
kind
of
distilled
it
down
to
one
question
right
now,
which
is
how
do
each
of
you
see
AI
being
implemented
into
your
workflows
and
what
kinds
of
things
do
like?
E
D
D
Okay,
yeah,
oh
yeah,
we're
yeah,
there's
a
lot
of
interest
in
our
team
on
GitHub
co-pilot.
Like
all
around
you
know,
management
Engineers,
you
know,
there's
everyone's
excited,
that's
one
of
the
things
we're
looking
at.
How
do
we?
How
do
we
enable
people
to
use
GitHub
co-pilot?
But
you
know
conscious
that
it's
you
know
it's
a
pretty
dramatic
shift
in.
You
know
in
engineering
right,
so
we're
gonna.
We
want
to
do
our
assessment,
but
we're
doing
a
we're
starting
a
trial.
D
Essentially
it's
just
a
way
to
make
Engineers
more
efficient.
That's
that's
the
way.
I
see
it
and
you
know
especially
replacing
some
of
the
more
maybe
the
mundane
things
that
you
have
to
do.
But
you
know
it's
just
going
to
take
like
you
know
it
might
take
you
a
few
hours,
but
if
you
can
do
it
in
a
few
minutes,
you
know
then
that's
you
know.
That's
a
big
Advantage
and
we've
all
seen
the
announcement.
D
C
Yeah
I've
got
kind
of
three
quick
things.
I
think
we're
in
you
know
starting
a
trial
for
for
copilot
as
well.
In
Enterprise
environments.
Things
tend
to
be.
You
know
that
little
bit
slower
than
your
side
projects,
so
we
definitely
see
that
as
a
as
a
developer,
enhancement
chat,
gpts
everywhere,
right,
plugins
were
released
on
Friday
I.
Think
the
there
will
be
some
security
pullback
on
that
I
think
at
some
point
so
we're
you
know.
C
All
those
fundamentals
are
still
required
right.
If
people
are
worried
about
software
jobs
going
away
because
chat
CBT
can
you
know,
write,
boilerplate
or
or
co-pilot
and
ripe
oil
plate?
You
don't
need
to
worry.
You
know,
there's
there's
plenty
of
jobs,
of
making
sure
that
what
it's
writing
is
is
good
and
all
those
key
Concepts
kind
of
will
remain
for
forever
around.
You
know,
time.
Complexity,
trade-offs
and
all
those
kind
of
things,
so
I
wouldn't
worry
too
much
about
that.
B
We
wanted
to
look
at
it
and
then
we
couldn't
because
it
wasn't
about
for
business
yet
and
now
that
it
is
then
we'll
we're
gonna
again.
Yeah
same
thing
start
a
trial
at
some
point,
I
believe.
But
with
someone
asked
a
question,
certainly
recently,
it
ended
up
Sarah
like
a
popcorn
of
watching
this
chat,
going
off
people
having
a
go
at
each
other
and
around
questions
around
and
we've
ever
done
the
jobs
and
this
and
that
and
but
I
kind
of
see
it
as
yeah.
It's
it's
to
me.
B
It
feels
like
I've
used
chat
to
be
like
my
example
is
I
was
writing
a
blog
post
and
I
wrote
All
myself
and
I
was
publishing
internally
and
I
thought.
Oh,
hang
on
I'll
just
ask
Jack
TV
did
the
same
thing,
I'll
just
tell
it
what
I
needed
and
just
ask
for
this
blog
post,
and
it
just
spewed
it
out
in
like
two
seconds,
but
every
time
I
asked
the
same
question.
You
always
give
me
a
completely
different
blog
post.
So
the
idea
is
it's
not
giving
an
answer.
It's
giving
that
answer.
E
A
You
so
much
Miss
and
I
would
say
Also
earlier
in
the
keynote
as
well.
How
co-pilot
is
here
to
help
developers
we're
talking
about
developer
experience,
it's
not
taking
anyone's
jobs
here,
it's
the
opposite.
It's
making
them
be
able
to
deliver
code
faster,
be
in
another
one.
That
I
thought
was
very
interesting
is
that
the
developers
are
reporting
there
to
be
like
75
percent,
more
fulfilled
when
using
copilot,
because,
like
you
know
they,
they
know
what
they're
doing
they
are
the
drivers,
not
the
co-pilots,
I'm,
just
gonna
share
my
screen.
Thank
you.
A
A
Finally,
on
Friday,
we
have
another
great
fireside
chat
plan
featuring
team
leadings
from
CBA
from
Commonwealth
Bank
from
kpmt
Tokyo,
as
well
as
Udan,
as
well
as
running
a
very
fun
interactive
session,
where
my
colleagues,
Karthik
and
Shilpa
will
be
talking
through
some
of
the
common
development
as
well
as
how
they
could
be
holding
you
back.
So
all
of
these
sessions,
including
the
Keynotes,
everything,
will
be
broadcasted
and
everything
will
be
available
on
demand.
A
So
you
will
be
receiving
a
follow-up
email
once
the
sessions
are
available
to
view
it
so
make
sure
you
check
your
inbox
and
if
you
would
like
a
deeper
dive
on
anything
that
we
covered
today
and
that
can
be
anything
from
GitHub
Enterprise
co-pilot
code
spaces.
Anything
that
you
would
like
GitHub,
Advanced
security
that
you
would
like
to
learn
more
about.
A
You
can
click
the
book
editing
button
on
the
top
right
of
your
corner,
and
we
will
make
sure
that
we
will
get
in
touch
with
you
shortly
and
lastly,
I
just
want
to
say:
please
take
just
a
minute
or
two
to
complete
a
short
survey
about
your
experience
with
us
today.
You'll
find
the
link
to
the
survey
as
well
in
the
documents
tab
at
the
right
of
your
code
of
the
corner
of
your
screen
and
the
resources
or
in
the
chat
window.
A
We
will
be
sharing
it
as
well,
so
we
designed
this
program
for
you
and
you
really
want
to
make
sure
that
you
are
getting
the
most
out
of
it
and
we
would
like
to
get
your
feedback.
So
please
make
sure
that
you
share
that
with
us,
so
we
can
get
a
better
experience.
Always
don't
be
shy.
Tell
us
what
you
think
please
and
with
that
I
just
want
to
say
thank
you
again
to
our
speakers
and
thank
you
to
all
the
audience
for
joining
us
today.
We
look
forward
to
seeing
you
soon.