GitHub Enterprise Roadshow, Munich
2020-01-29

Engineering Lead
</>

a network of organizations
TECHNOLOGY
CREDIT
PLATFORM
REAL ESTATE
PLATFORM
INSURANCE
PLATFORM
Digitalisation of the
credit, real estate
and insurance
industries

a network-centric
organization
Connecting wishes
with banks

in numbers
>200
employees
662
partners on the
platform
53.5
bill euro
real estate financing
transaction volume
in 2019
3.5
bill euro
credit
transaction volume
in 2019
housing-saving
transaction volume
in 2019
11.0
bill euro

Photo by Khachik Simonian on Unsplash

Photo by Dominika Roseclay from Pexels

Photo by mentatdgt from Pexels

Photo by Ian Kim on Unsplash

Photo by fauxels from Pexels

Photo by anna-m. w. from Pexels

Open Source
&
InnerSource
A community of
practice for applying
The Apache Way in
Europace

challenge or
opportunity
idea
solution in
one team
feedback
share with
community
of practice
adoption by
other teams
recommendation
in documentation
or principle
upstream
sharing
(public)
improvement
of solution

Photo by Chokniti Khongchum from Pexels

Collaboration between
multiple teams on a
shared project
#1 Private repository on GitHub

Private repository on
GitHub org with
pull-requests
#1 Private repository on GitHub

● Use “WIP” labels or draft-pull requests
● Author of pull-request should merge
● Expectation management for reviews
● Pull-request templates are often ignored
● Source code in the cloud has no legal
constraints unless it contains user data
● Continuous integration before merge
#1 Private repository on GitHub

● High entry barrier for other teams
● Does not scale well: How to organize
repositories
● Unknown GitHub accounts as members
● How to collaborate between teams
● Integration with existing development
infrastructure
#1 Private repository on GitHub

Scalability: How to
organize repositories
Unknown GitHub
accounts as members
#2 Teams in GitHub

Replicate team
structure with “teams”
feature on GitHub
#2 Teams in GitHub

● Prefixes in repository names are more
helpful
● READMEs for better findability
● Teams can manage their members
#2 Teams in GitHub

● Management of many repositories is still
cumbersome
● Rules of play for GitHub organization
reduce team autonomy
#2 Teams in GitHub

High entry barrier for
other teams
#3 Support channel in Slack

GitHub as a product
#3 Support channel in Slack

● Support is good, documentation is better
● Documentation is good, trainings are
better
● It’s good to have a FAQ for repeating
issues
● Internal tools are also products
#3 Support channel in Slack

● Documentation for GitHub@Europace
● Git-/GitHub-Trainings
● FAQ on GitHub@Europace
#3 Support channel in Slack

Management of many
repositories is still
cumbersome
Rules of play for GitHub
organization reduce
team autonomy
#4 GitHub org for one product

Divide and conquer:
GitHub orgs for
managing repositories
and teams
#4 GitHub org for one product

● Easier separation of repositories
● More autonomy for team around product
#4 GitHub org for one product

● Less transparency due to limited access
(only team)
● Extra costs for every organization and
additional seats for people of other teams
#4 GitHub org for one product

Less transparency due
to limited access (only
team)
Extra costs for every
organization
#5 GitHub org per subsidiary or product

GitHub Enterprise Cloud
#5 GitHub org per subsidiary or product

● Enforce SSO and 2FA from beginning
● Use units which last longer, i.e. subsidiaries
or products
#5 GitHub org per subsidiary or product

● No enterprise search, search does not find
internal repositories if not member
● CI/CD integration
● GitHub Registry and Actions
● No migration path to Enterprise SSO
● Azure AD supports only max. number of
orgs per SAML connector
#5 GitHub org per subsidiary or product

CI/CD with multiple
organizations
Management of
technical users
#6 CI/CD with technical user per purpose

Integrate security team
into the process of
creating technical users
#6 CI/CD with technical user per purpose

● Integrating cloud and on-premise
infrastructure is not easy
● Personal access tokens have a too broad
scope to be used for CI/CD
● Integrate security team early
● If you only need an RSA key and an access
token, don’t ask for whole ActiveDirectory
account
#6 CI/CD with technical user per purpose

● Use similar process for integrating other
cloud services with on-premise
infrastructure
#6 CI/CD with technical user per purpose

Who should be
contacted for
contributions or other
questions regarding one
project?
#7 Trusted committer for InnerSource documentation

Trusted committer or
code owner
#7 Trusted committer for InnerSource documentation

● Every project needs at least 2 or 3 active
code owners in order to ensure proper
maintenance of the code
● CODEOWNERS file in GitHub repositories
● Accountabilities of a trusted committer or
code owner should be identical for all
teams
#7 Trusted committer for InnerSource documentation

● Questions on non-technical topics need
to be answered outside of issues and
pull-requests, because many
non-developers don’t use GitHub
#7 Trusted committer for InnerSource documentation

How to agree on
standard technologies
between autonomous
teams?
#8 Open decision process for standards

Use Open Decision
Framework from RedHat
#8 Open decision process for standards

● Use IETF RFC 2119 (MUST, SHOULD, MAY etc.)
for defining compliance level of
technology standards
● GitHub flow for reviewing and applying
standards
● Standard committee defined in
CODEOWNERS file
#8 Open decision process for standards

● Communication of standards
#8 Open decision process for standards

for finding the
right direction
for guidance on
the journey
for reducing
uncertainty and
moving forward