►
From YouTube: GitLab - BCBS Webcast - June 7, 2018
Description
Security is a critical part of automating the DevOps lifecycle. Join us to learn how can healthcare and insurance providers within the BCBS network are developing a faster DevOps lifecycle by integrated security directly into the process with GitLab.
A
All
right:
well,
what
we'll
do
is
just
go
ahead
and
get
started.
First,
I
want
to
welcome
everyone
to
this
gitlab
BlueCross
BlueShield
webinar,
it's
about
faster,
more
secure,
DevOps.
I
really
would
like
to
welcome
a
couple.
Bluecross
companies,
specifically
their
install
berry
canva,
can
be
a
Health
Solutions
and
Jim
newmeyer
at
health
solutions.
You
guys
are
going
to
talk
a
little
bit
about
how
you
use
get
lab
today.
I'll
move
into
the
quick
overview
of
the
agenda.
A
I
also
wanted
to
thank
Joel,
cruse,
wick
and
John
Wood
should
get
lab
they'll,
be
giving
a
brief
overview
and
a
demo
of
the
art
of
the
possible
if
you
live
so
far
to
kick
off
for
today
is
why
secure
DevOps
right
so
Amazon
is
starting
to
enter
into
the
healthcare
business
and
BlueCross
BlueShield
needs
to
be
a
little
bit
more
flexible.
Moving
at
a
faster
pace
right,
so
big,
doesn't
necessarily
meet.
Small
fast
is
beating
slow,
so
well
we're
wanting
to
improve
with
with
give
a
vis
our
customers,
speed
of
solutions
and
cybercrime.
A
Damages
are
expensive
and
so
a
little
bit
about
get
labs
overview
with
Joel
and
John,
and
then
we'll
do
a
demo
and
then
we'll
turn
it
over
to
which
companies
that
BlueCross
BlueShield
are
using
it
lab.
Daren
Stalder
will
share
a
little
bit.
Jim
Newmar
will
share
some
more
and
then
we'll
open
it
up
to
questions
feel
free
to
ask
questions
any
time
during
this
webinar
in
the
chat
and
we'll
jump
in
and
start
getting
started.
So
a
brief
overview
as
gitlab
is.
A
As
we
start
in
2014,
we
are
an
open-source
software
company
with
over
270
team
members
across
440
countries.
We
are
the
leader
of
on-prem
self,
get
on
market
with
over
a
hundred
thousand
organizations.
Millions
of
users,
and,
what's
really
nice,
is
that
Google
crowdsource
development.
We
have
over
2,000
contributors
to
our
open-source
platform.
We
do
release
every
month
and
it's
a
way
for
us
to
risk
to
our
customers
needs
quickly.
John,
you
can
go
to
the
next
slide,
so
get
labs.
These
DevOps
is
a
broader
definition.
A
You
have
the
security
teams
and
the
business
teams
as
strategic
stakeholders
in
the
software
development
lifecycle.
So
we
like
to
include
them
in
the
process
and
include
them
in
our
solution.
You
can
move
ahead.
John
get
lab
we're
about
innovation
instead
of
integration.
What
most
customers
have
is
a
string
of
integrated
tools
could
be
multiple
tools.
We
are
a
single
application
that
can
cover
the
complete
DevOps
lifecycle,
John.
You
can
go
to
the
next
slide.
A
Here's
an
example
of
the
different
phases
of
DevOps
plan
create
verify
package
release,
configure
monitor,
and
this
is
an
example
of
the
different
tools
that
customer
string
together.
What's
really
challenging
is
is
managing
and
keeping
these
tools
working
together,
as
you
upgrade
one,
you
potentially
break
another.
As
you
add
new
projects
and
new
users,
you
have
to
get
the
permissions
and
configurations
right
for
all
these
different
users.
John.
You
can
move
to
the
next
one
I
like
to
call
this
tool
chain
madness
for
the
dev
Cyclops
environment.
No
one
really
planned
this.
Yes,
it
works.
A
Is
it
fragile?
What
are
you
gonna
do?
Does
it
scale?
Well,
maybe
not
right.
So
a
git
lab
on
the
next
slide,
we're
about
providing
you
a
platform,
that's
based
on
open
source
that
allows
you
to
manage
a
secure,
devops
life
cycle,
which
is
speeding
up
by
three
to
ten
apps
for
some
of
our
customers
on
the
next
slide.
This
is
a
brief
overview
of
what
we
cover
throughout
the
lifecycle
I'm
not
going
to
list
all
these
out.
A
We
are
still
working
on
some
in
2018
and
the
gray
we
do
later
eight
every
month
you
will
see
pieces
and
parts
of
this
throughout
the
demo,
but
what
I
really
wanted
to
share
is
that
get
labs
about
everyone
can
contribute
throughout
the
lifecycle,
not
just
the
developer
and
that
we're
more
than
a
code
repo
John.
The
next
slide
so
build
from
the
ground
up
as
a
single
application.
All
of
these
things
just
work
together
and
we
simplify
with
a
single
conversation.
A
A
single
data
store
a
single
permission
model,
a
single
interface
right,
so
it
makes
it
much
easier
for
your
users
in
the
software
development
lifecycle.
Specifically,
if
you
need
to
govern
and
secure
the
the
process,
the
team
collaboration
is
easier.
If
you
have
one
tool,
everyone
can
see
everything
that's
going
on
and
then
you
can
measure
with
lifecycle
analytics.
What's
working,
what's
not
working
right.
Where
are
you
improving?
Where
are
you
struggling.
A
You
can
go
to
the
next
slide
John,
so
I
want
to
be
clear
and
that
gitlab
can
do
everything
end-to-end
and
your
DevOps
lifecycle,
but
we
also
do
integrate
with
some
major
tools
like
JIRA
github
Jenkins,
we're
not
asking
you
to
rip
and
replace
heavy
investments
that
you
may
have
already
made.
We
just
want
to
make
it
easy.
If
you
have
those
tools
in
place
today,
we.
B
A
Open
source,
api's
and
web
hooks,
and
if
there's
something
that's
not,
there
feel
free
to
log
a
feature
request
or
contribute
yourself.
You
can
add
the
integration
or
the
API
in
our
community
edition
for
open
source
edition
John.
You
can
hear
the
next
song,
so
good
luck.
Key
differentiator
is
that
we
make
it
easy
for
everyone
on
the
software
development
lifecycle
right.
A
We
make
it
visible,
so
you
can
see
everything
as
it
changes
in
real
time
and
it's
more
efficient
since
you're
collaborating
all
with
one
tool
and
the
governance
is
easy
to
develop
and
operate
with
a
secure
solution.
So
it's
based
on
open
source
I'm,
going
to
turn
it
over
to
John
and
Joel
and
they're
gonna
talk
a
little
bit
more
about
git
lab
and
making
it
more
secure
in
the
software
development
lifecycle.
Yorktown
thanks.
B
Adam,
so
security
is,
is
a
reality
for
organizations
today
and,
for
most
of
us,
were
in
the
middle
of
a
cyber
security
crisis.
We've
seen
incidents
like
where
Equifax
leaked
critical
data
because
of
an
outdated
vulnerable
dependency
in
their
struts
dependency,
they
were
relying
on
a
single
security
employee,
not
even
just
a
team,
a
single
imperson
to
manually
notify
on
patching
the
strengths
vulnerability.
This
notification
process
should
have
been
automated.
B
So
how
did
we
get
here
today?
Traditionally,
dev
and
QA
have
been
siloed
from
each
other.
There
was
limited
to
no
automated
testing.
There
is
lots
of
quality
issues
in
staging
environments,
which
required
lots
of
rework,
and
this
really
slowed
down
that
socrata
violent
lifecycle
going
from
idea
to
production.
Continuous
integration
has
solved
many
of
these
issues.
We've
automated
our
builds
our
unit,
testing
and
and
testing
higher
quality
code
going
into
staging.
B
Thus
DevOps
was
born,
but
what
about
security?
Security
is
a
lot
harder,
so
is
generally
left
to
the
end
of
the
software
lifecycle
and
was
only
done
occasionally.
Developers
would
essentially
throw
their
code
over
the
cubical
wall
to
the
security
team
and
said
have
at
it,
and
then
they
secured
you
to
come
back
a
couple
weeks
later
and
say:
here's
all
these
security
bugs
now
go
fix
them.
This
was
slow
and
and
and
really
made
things
difficult
on
for
both
teams
and
essentially
security
is
just
really
hard.
B
B
Dependency
scatting
earlier
this
year,
get
lab,
acquired
a
dependency
security,
security,
firm,
called
gymnasium
and
we've
already
implemented
their
database
of
security
vulnerabilities
in
to
get
lab.
We
analyzed
everybody.
These
days
is
using
open
source
security
or
sorry
open
source
dependencies,
and
this
is
the
most
likely
penetration
point
for
for
hackers.
B
B
The
sass
test
performs
that
static
analysis
on
your
source
code
itself
and
it
spots
those
potential
vulnerabilities
before
they
get
into
deployment
and
that's
really
key
again.
We're
leveraging
popular
open
source
tools
and
and
putting
them
into
get
into
a
custom
container
that
you
can
use
to
analyze.
Your
code.
B
B
B
This
allows
for
there's
many
benefits
of
this.
A
lot
of
security
tools
are
charging
by
lines
of
code
scanned,
which
is
why
a
lot
of
people
we're
doing
security
testing
at
the
end
of
the
lifecycle
to
save
costs
with
gitlab
there's
one
overall
price
that
you're
paying
for
to
have
this
integrated
security
that
can
be
run
as
many
times
as
needed.
B
B
And
additionally,
because
of
get
labs,
high
velocity
releases,
there's
so
much
stuff
coming
down
the
road
so
quickly.
Here's
a
few
things
in
our
for
our
direction
that
we're
working
on
I'm,
like
I,
mentioned
we're
increasing
your
language
coverage
of
our
scanning
tools,
we're
working
on
our
single
noise
management,
so
you're
not
getting
as
many
false
positives.
B
We're
gonna,
be
adding
license
management
into
get
lab
so
to
make
sure
that
you're
not
using
licenses
that
are
outside
of
your
come
on
own
company's
policies
and,
finally,
we're
going
to
expand
upon
our
security
offering
by
offering
us
security
dashboard.
Let's
get
the
security
team
right
into
the
mix
show
them
the
results
of
those
constant
tests
that
your
developers
are
running.
B
We're
also
thinking
about
implementing
interactive
application
security
testing,
where
we're
collecting
information
from
inside
a
running
application
during
a
denied
n
Amex.
Can
we're
also
working
on
something
we
call
recon,
which
will
scan
through
a
top-level
domain
that
you
specify
and
search
for,
unidentified
domains
below
that
or
identified
hosts
below
that
for
security
purposes?
And
then
a
web
application
firewall
built
right
into
our
deployment
to
minimize
the
risk
of
a
break-in
once
once
your
application
is
deployed.
B
And
lastly,
probably
our
greatest
vision
is
Auto
remediate.
This
is
where
gitlab
will
automatically
scan
your
code
for
known
vulnerabilities
and,
if
ID
identify
something
it
will
automatically
remediate
those
it'll
identify
the
fixes
and
implement
them,
for
you
then
verify
it,
merge
it
back
in
and
deploy
it.
B
B
We
see
here
a
get
lab
project
I'm
right
at
the.
Let
me
go
right
to
the
top
level
of
the
project
here
and
within
get
lab.
We
believe,
there's
three
like
I,
said
the
three
pillars
of
get
lab:
the
repo
itself
issue,
tracking
and
CI
CD
for
our
repo
management.
We
obviously
use
get
gets
in
our
name.
We
better
be
good
at
it
and
we
are.
B
We
have
standard
directory
hierarchies
here
you
can
click
in
on
a
file
standard
version,
control,
stuff.
Where
you
can
view
the
history
of
the
file,
you
can
run
get
blame
to
see
who
has
who
made
certain
changes
to
certain
parts
of
the
file,
all
that
great
version,
control
functionality
that
you're
used
to
regardless
of
what
version
control
tool
you're
using
yet
is
more
and
more,
is
becoming
the
standard
for
for
industry
because
of
its
ease
of
use
and
developers
and
developers
love
it.
B
B
B
B
B
Get
labs,
CI
tool
is,
like
I
said,
is
integrated,
it's
scalable,
it's
flexible
and
it's
self-service
on
this
other
project
and
looking
at
now,
the
gate
lab
CI
is
run
by
this
doc.
Get
labs,
CI
Yama
file,
and
this
is
unusual
for
a
lot
of
CI
tools
in
that
developers
generally
don't
have
access
to
their
pipelines
within
the
tool
they're
working
in.
They
usually
have
to
go
through
a
gatekeeper
or
an
administrator
to
you,
access
to
whatever
third-party
CI
tool
they're
using
but
get
lab.
It's
all
self-service.
B
This
is
a
master
branch
on
another
project.
If
I
as
a
developer,
take
this
master
branch
and
create
a
feature
branch
off
of
it,
this
gate
lab,
CI,
Yama
file
comes
with
me.
I
can
make
changes
to
it
for
testing
if
needed,
but
it's
also
there
so
that
when
I
make
commits
to
that
branch,
if
I'm
working
on
my
project
it'll
run
the
pipeline's
I
need
to
run.
My
builds
my
tests
and
and
and
my
deployments
as
needed.
So.
B
That's
all
great,
so
we
have
our
repo.
We
have
our
issues
and
we
have
our
CI
tool,
but
how
do
we
tie
it?
All
together?
That's
done
through
the
gitlab
merger
quest
I
mentioned
how
developer
works
in
a
feature
branch
when
they
want
to
merge
that
branch
back
in
the
master.
They
create
a
merger
quest
for
those
who
might
be
used
to
other
popular
get
based
tools.
They
might
know
this
as
a
pull
request.
Button
get
lab
we're
merging
from
that
branch
into
master.
So
we
call
it
what
it
is
a
merge
request
now.
B
What
was
the
this
is
the
merger
quest
I
wanted
to
look
at,
and
we
can
see
here
within
the
merger
quest
the
changes
that
were
made
so
the
exact
disk
that
we're
done.
We
can
see
the
pipelines
that
have
been
run,
the
exact
commits
and
any
discussion
around
the
code
review,
and
this
is
where
the
the
collaborative
development
comes
into
play
right
within
the
merger
quest.
You
can,
you
can
set
approvers
in
this
project.
B
We
don't
have
approvers
turned
on,
but
you
can
set
gatekeepers
who
have
to
approve
of
a
merge
request
before
it
can
be
merged
back
into
a
into
the
master
branch.
Like
I
said,
everything
is
coming
into
the
merge
request
itself.
We
have
the
description
if
this
was
based
off
of
an
issue.
The
issue
itself
would
be
listed
here
to
be
closed
upon
merging
in
the
master
we
see
the
branch
were
starting
in
and
the
branch
were
merging
into
I,
see
that
were
six
commits
behind
in
the
master.
B
So
there
may
be
conflicts
that
we
might
need
to
resolve.
It
doesn't
look
like
it
here,
but
if
there
was
there'd,
be
a
conflict
resolution
tool
available
right
within
the
merger
quest.
Additionally,
you
could
work
on
files
through
our
built-in
web
IDE.
This
is
great
again
for
those
developers
who
do
want
to
do
context,
switching
between
an
IDE
and
get
lab
itself.
Gitlab
has
a
web
ID
in
beta,
that's
currently
available
for
test
and
development,
and
it
works
great
for
developers
wanting
to
work
on
files.
B
B
We
see
we
have
our
built
in
code,
quality
testing
as
well,
and
the
results
of
that
we
see.
We
have
our
like
I,
said
our
performance
testing
and
that
we've
increased
our
performance
on
this
one
point
and
we
have
our
security
testing
built
right
in
the
git
lab.
We
see
here
that
my
buddy
Joel
has
has
been
a
bit
lacks
in
his
security
remediation
and
he
has
376
Valle
nura
bilities.
You
can
expand
that
you
can
view
the
complete
SAS
report.
We
see
our
container
has
most
of
those
vulnerabilities.
B
So
this
is
great.
This
is
that
whole
shift
left
movement.
Now
developers
are
seeing
the
results
of
their
security
scans
on
every
commit.
They
can
address
those
much
earlier
in
the
development
process,
as
opposed
to
wait
until
the
end
thinking,
they're
finished
and
then
having
security
come
back
to
them.
The
next
day
saying
no,
you
know
what
you
have.
Three
hundred
and
five
vulnerabilities
in
your
container
go
fix
those.
B
A
Thanks
John,
if
you
guys
have
any
questions
with
anything
that
John
showed
you,
please
feel
free
to
throw
them
in
chat
at
the
end,
we
will
open
it
up
to
you
know
some
vocal
questions.
I
didn't
want
to
really
highlight
something
that
John
pointed
out
is
that
our
solution
is
really
helping
solve
these
security
problems.
Earlier
on,
all
these
security
vulnerabilities
are
extremely
expensive
to
fix
and
almost
I
think
it's
like
over
75%
of
developers
never
have
gone
through
any
security
coding,
secure
code
type
of
training,
either
in
their
education
or
in
the
enterprise.
A
A
A
It
lab
has
a
couple
different
flavors
there's
get
labs
EE,
which
we
Community
Edition,
which
is
core,
and
it's
kind
of
a
Russian
doll
model,
and
then
there's
our
Enterprise
Solution
everything's
built
on
core
and
then
their
starter
premium
ultimate,
and
these
are
some
of
the
blue
crosses
that
are
currently
using
get
lab
today
and
we're
lucky
enough
to
have
two
of
them
here
that
are
willing
to
speak
about
it.
I'm
gonna
go
ahead.
C
A
To
the
next
slide
and
introduce
it
was
someone
else,
but
Darren
I
want
to
say
thank
you
for
being
a
last-minute
switch
Darren's,
a
release,
engineer
on
the
platform
services
and
release
engineering
team.
It
can
be
a
Health
Solutions,
Darrin,
we're
gonna
turn
it
over
to
you
and
feel
free
to
share
your
story.
Your
DevOps
journey,
what's
working
well
forget
lab,
and
the
goal
here
is
for
us
to
help
collaborate.
What
other
Blue
Cross's
they're
doing.
D
D
D
D
D
We're
we're
actually
working
right
now
on
we
use,
we
use
JIRA
for
our
issue
tracking
and
we're
using
ansible
is
are
generally
what
we're
using
for
our
automation
and
we've
got
that
integrated
in
with
get
lab.
We
even
have
we
have
ansible.
We
can
spin
up
a
new
get
lab
instance
in
about
five
minutes
using
ansible,
and
it
was
interesting
when
we
first
did
this
in
that
we
were
trying
to
replace
the
get
lab
instance
and
then,
when
get
lab
went
open,
the
repo
went
away
in
the
middle
of
it
ansible
kind
of
got
upset.
B
B
So
you're
using
get
lab
primarily
for
like
the
code,
repo
code
review
and
you're,
integrating
with
other
tools
for
for
issue,
tracking
CI
and
deployment.
Yes,
yeah
I
think
that's
a
great
example
of
just
how
flexible
get
lab
can
be
and
and
what
Adam
was
talking
about
earlier,
no
need
to
rip
and
replace
the
tools
that
you're
familiar
with
and
get
lab
can
fit
right
in
where
needed.
Yeah.
D
A
A
C
I
am
Jim
newmeyer,
my
I
am
an
architect.
I,
always
put
technical
in
front
because
I
don't
do
the
pretty
billy's
building
drawings.
I
just
make
sure
people
were
aware
of
that,
but
health
solutions.
Just
as
a
background,
we
were
a.
We
were
the
IT
department
of
hi
mark
Inc,
hi,
marking
split
off
into
different
companies.
We
have
the
parent
company
of
Highmark
Inc
Highmark
health
is
the
insurance
wing.
We
have
Allegheny
Health
Network
as
the
provider
area
and
Highmark
health
solutions
is
the
IT
company.
C
The
first
we
have
three
installations
of
get
lab.
Actually
two
of
our
clients
came
to
us
and
said:
hey.
We
want
to
do
some
development
outside
of
your
IT
company,
in
which
we
are
fine
with.
Can
you
set
us
up
a
get
lab
installation,
so
we
just
rolled
out
a
simple
C
II
version
to
them.
They
maintain
it.
They
management,
I,
helped
them
with
any
technical
issues
or
installations,
but
for
for
our
use,
health
solutions
decide
to
go
with
get
lab
enterprise.
The
starter,
audition
I
believe
it's
called.
C
C
It's
a
a
commercial
product.
It
is
not
Jenkins,
I'm,
actually
very
much
anti
Jenkins,
but
we
are
using
that
and
we
have
that
setup,
but
our
source
control
repo
was
clunky
at
best
it
was
a
client-server
application
and
some
of
the
teams
were
really
pushing
it
in
our
industry,
and
we
said:
okay,
let's
look
at
a
get
solution
that
adds
security
and
LDAP
integration.
C
So
where
we
are
today,
it's
mostly
a
source
repository
as
I
said
we
are
using
it
as
our
code
review,
so
developers
will
submit
a
change
to
a
branch.
They
will
submit
a
merge
request
down
to
the
master
branch
at
that
time.
Another
set
of
eyes
must
code
review
it.
We
have
a
different
group
that
does
code
reviews.
This
is
for
our
soft
2
compliance,
so
we
have
a
second
set
of
eyes
even
before
a
build
occurs.
C
Once
the
code
reviewer
looks
at
it
and
uses
the
in
tool
comparison
on
get
lab,
they
can
either
reject
the
merge
request.
Send
it
back
to
the
developer,
send
notes
right
in
the
to
letÃ's
emails,
the
developer,
you
can
correspond
either
via
email
or
in
the
UI
itself,
when
the
merge
requests
and
all
that
everything
is
finally
done,
it
gets
merged
into
master
and
then
our
build
cycle
can
occur
with
our
new
pipeline.
We
are
exploring
the
CI
function
just
for
executing
unit
test
cases
before
a
merge
request.
C
C
Did
this
coach
pass
all
their
unit
test
cases
and
that's
what
we're
using
the
runner
for
a
very
simple
case,
but
it'll
save
time
and
save
load
on
our
CI
build
server,
so
teams
aren't
just
merging
running
a
build
and
then
that
build
may
not
pass
unit
test
cases.
It
moves
it
even
further
left
for
them.
C
Well,
we're
constantly
looking
at
expanding
usage,
we
did
in
we're
writing
our
own
inventory
system
and
when
the
inventory
system
it's
a
new
record
into
it,
it
actually
creates
an
API
call
over
to
get
lab
to
create
the
security
to
add
the
security
groups
and
create
the
repos
and
create
any
other
information
inside
of
get
lab.
We
need
so
really
for
us
when
a
team
requests
a
new
application
in
our
inventory
system,
they
don't
have
to
do
anything.
C
C
The
real
challenges
for
us
with
devops
aren't
around
tools
as
much
as
they
are
around
culture
and
process
getting
our
developers
out
of
the
mindset
of
oh,
we
must
silo
all
our
applications.
We
can't
share
code
across
the
organization.
Get
lab
is
starting
to
break
down
some
of
those
barriers.
Where
teams
can
now
go
in
and
say
you're
doing
it
using
this
code
over
there
I
want
to
use
it,
make
it
a
library,
publish
it
up
to
an
internal
repository,
and
then
they
can
include
it
in
their
build
process
as
well.
C
Now
we
have
some
posts,
our
we
have
one
tool,
that's
hooked
into
our
IDE
s
that
does
scanning
on
our
desktop
and
then
we
are.
We
are
using
a
commercial
available
tool
during
our
build
process
to
do
our
security
scanning
and
vulnerability,
checking
those
are
still
being
rolled
out
and
we're
hoping
to
I
know
the
one
tool
with
the
local
desktop
tool
work.
The
security
team
is
looking
at
replacing,
but
just
like,
every
other
organization
will
probably
or
a
lot
of
them
out
there
we're
very
siloed.
B
B
C
Our
you
know
we're
redoing
our
entire
build
and
deploy
pipeline.
So
for
us,
while
security
is
very
important,
it
will
be
something
we
mentioned
to
our
security
team
for
them
to
analyze
and
look
at,
and
then
they
have
again.
We
we're
not
security
experts.
They
are
they're,
the
ones
that
are
going
to
be
telling
us
yes
use
this
or
no
we're
going
to
do
it.
This
way
would.
A
B
D
D
B
D
Going
to
talk
about
that
we're
actually
using
slack
and
we've
got
I
think
somebody
just
recently
started
doing
some
integration
between
slack
and
get
lab
and
we
actually
have,
except
for
a
clip
for
like
three
projects.
All
of
our
projects
are
set
as
internal,
and
so
everybody
anybody
that
has
a
log
into
our
our
get
lab
instance-
can
see
everybody
else's
code
and
it's
actually
been
propagating
a
lot
of
code
sharing
between
the
teams.
A
D
A
Sure
so
you
know,
if
there's
anyone
else
on
the
call
that
has
any
questions
or
you
want
to
share
your
dubs
AQAP's
journey
doesn't
have
to
be.
Today
could
be
another
time
we're
happy
to
do
another
kind
of
private
BlueCross,
BlueShield
webinar.
We
do
a
lot
of
standard
webinars
here
and
get
lab
about
different
topics.
If
you
have
an
idea
for
a
topic,
please
let
us
know.
Sometimes
you
got
some
brave
people,
they
listen
in
on
the
call
and
they
share.
Hey
I
have
this
problem.
This
is
what
you
know.
A
We
struggled
there
if
there's
any
one
feel
free
to
raise
your
hand
in
the
chat,
let
us
know,
but
you
can
move
the
next
slide
and
then
you
know
our
recommendations,
for
you
guys
is
to
have
some
kind
of
way
to
collaborate
amongst
the
BlueCross
companies.
It
could
be
quarterly
semi-annually.
We
could
do
a
BlueCross
BlueShield
specific,
get
bad
day
for
any
of
the
crosses
that
want
to
dive
deeper.
Will
we
come
on-site?
It
could
be
remote
if
you're
willing
to
do
an
internal
case
study
or
start
to
present
at
your
local
meetup
about.
A
You
know
I
liked
how
you
put
it
Jim,
you
know,
hey
a
lot
of
our
challenges
were
around
culture
and
process,
not
necessarily
tools,
but
those
are
always
good
opportunities
for
other
people
to
learn
from
hey.
We
face
this
problem.
This
is
how
we
solved
it.
The
tool
might
be
a
piece
of
the
puzzle.
I
encourage
you
guys
to
present,
or
do
other
webinars
like
that,
any
other
questions
in
the
chat.
A
Really
quickly,
I'll
show
you.
We
are
open
and
transparent
company.
One
of
our
values
is
transparency
and
we
have
our
roadmap
out
in
the
public.
So
if
you
ever
engine
Google
get
lab
directions,
you
can
see
our
roadmap.
It's
broken
down
by.
What's
the
next
release
coming
down
the
right,
it's
broken
down
by
what
flavor
of
enterprise
or
even
the
core
solution
and
then
by
functionality,
so
we'd
like
to
part
of
it
up.
A
You
just
want
to
click
on
like
a
lemon
I
know
if
you
scroll
up
to
the
top.
So
this
is
our
next
release
we
release
every
month.
These
are
the
features
that
are
coming
out
on
June
22nd.
What
is
today
the
seven
so
you're?
Looking
at
less
than
about
two
weeks
pick
anyone
over
there,
you
want
John,
it
doesn't
really
matter.
This
is
get
lab
when
you
get
it
when
you
click
on
one
of
these
Auto
DevOps
plus,
you
will
see
you
know
it's
a
conversation,
there's
some
requirements,
there's
a
feature
request.
A
There's
a
lot
of
updates.
It's
a
pretty
interesting
update,
Autobots.
It's
gotten
related
issues
that
are
linked
to
it
and
you
can
subscribe
to
this.
You
can
share
your
thumbs
up
thumbs
now.
I,
like
this
I,
don't
like
to
get
out
which
you
did
it
this
way.
If
you
have
an
idea
on
how
to
iterate
on
it,
please
share
with
us.
We
mean
it
when
we
started
this,
you
know
gitlab
is
about,
everyone
can
contribute.
That
is
you
that
is
our
customer
base.
A
It
could
be
encore,
it
could
be
on
the
enterprise,
but
we
want
you
guys
to
give
us
feedback.
We
can't
get
better
unless
we
get
the
feedback
and
we
will,
you
know,
follow
a
Minimum,
Viable,
Product
method,
where
you're
asking
for
a
car,
you're
gonna
get
a
skateboard
a
scooter,
a
bike,
a
motorcycle,
then
a
car
right.
So
we
want
the
feedback.
Please
participate,
I,
don't
think
I
have
anything
else
on
the
roadmap,
except
just
you
know,
check
it
out.