At SAP, a self service is offered to all development teams and automatically creates new development projects in Perforce without the need for approval by a central team. In this talk, learn how SAP uses Perforce to capitalize on the trend away from centrally-ruled processes toward more self service at the team level.
[SAP] Perforce Administrative Self Services at SAP
1. 1
Perforce Administrative Self
Services at SAP
Wolfram Kramer
Development Architect
SAP AG
TIP Core ECF & Production
2. 2
SAP today
• 232,000
Customers in more than
• 180
countries
• €16.22bn
Revenue
• 64,422
SAP employees worldwide
• SAP offices in more than
130 countries
3. 3
Perforce @SAP
• 1998
Introduction of Perforce at SAP
• 10,000
licensed users
• ~ 100
Perforce server instances
• 2
Perforce server locations
• ~ 2 TB
Perforce db.* files altogether
• ~ 10 TB
versioned data
• ~ 4·108
files (including branches)
@
4. 4
The iOS development process
deploy
and
test
idea
get
SCM
Project
Prepare
development
environment
release
and
delivery
exchange
Integrate
and
release
+
SAP
Mobile
Development
Lifecycle
develop
get
Libraries
e.g.
SUP
inhouse
delivery
How are
developer
teams enabled
to work with
Perforce?
5. 5
Provide Perforce access to developer teams
get
SCM
Project
• Get
a
locaGon
in
Perforce
where
to
put
the
sources
• Define
access
groups
and
protecGons
• Fill
the
access
groups
with
development
team
members
means
How?
Central
Perforce
Administrator
Email
Phone
call
Workflow
Ticket
system
Scalable?
Agile?
6. 6
Perforce depot structure
3 levels:
//depot/project/codeline
The
development
area, product
Component,
subsystem
Branch
Enablement
of
standardized
build
and
producGon
infrastructure.
Empowered
by
usage
of
change-‐submit
trigger.
7. 7
Permissions and groups
Access group types
• dev group (Developers)
• patcher group (Quality Managers, Build
Operators)
Possible group access ranges
• depot level (shown here), even multiple
depots
• project level
buildenv-
dev
buildenv-
patcher
write
read
write
write
write group buildenv-dev * //buildenv/*/ct01_stream/...
read group buildenv-dev * //buildenv/*/ct01_publish/...
write group buildenv-patcher * //buildenv/*/ct01_stream/...
write group buildenv-patcher * //buildenv/*/ct01_publish/...
8. 8
Multi-server landscape at SAP
Many servers at SAP since 2000
(Reasons: Performance)
User and Group store per server
instance
groups
users
groups
users
groups
users
groups
users
9. 9
Multiple user and group maintenance
Problem:
Per-server user and group
administration not possible any
more
Boundary condition:
No single-point-of-failure, i.e.
authorization Perforce server is
not an option
groups
users
groups
users
groups
users
groups
users
Central Perforce Administrator
10. 10
Central user and group storage
User and Group data are
maintained in a central application
with an SQL database underneath
(Perforce Management System,
P4MS)
User and group data are
automatically written by P4MS to
dedicated Perforce servers
Perforce
Management
System
(P4MS)
Central Perforce
Administrator
12. 12
Centralized user and group management
Problem:
Centralized user and group
management does not scale
Observation:
Decision on granting access
rights of new users is taken
locally
groups
users
Central
Perforce
Administrator
Development team members,
project leads
Access requests
13. 13
Admin groups
New group type
• admin group (Project Managers)
Admin groups exist only in P4MS, not on
Perforce servers.
Members of an admin group are allowed
to modify group members.
buildenv-
dev
buildenv-
patcher
write
read
write
write
buildenv-
admin
modify
modify
14. 14
Decentralized user and group maintenance
Development Team members
Perforce
Management
System
(P4MS)
Access requests
Project lead
Notification
Approval
Central
Perforce
Administrator
15. 15
Perforce Access Request
Development
Team member
Types in Path and
Server
Requests access
16. 16
Perforce Access Request Approval
Project lead
Notification
Email
Add user to group
17. 17
Centralized project management
Problem:
Centralized project management
does not scale
Observation:
Development teams know by
themselves which projects and
codelines they need
Central
Perforce
Administrator
Project
leads
Project creation
request
Codeline
creation
request
P4MS
Create
project
Generate
path in
Perforce
18. 18
P4MS administrator frontend for project creation
Project creation frontend in P4MS (Administrators only)
Created project in Perforce
19. 19
Self-service for creating a new project in the
Mobile area
Self-service for project
managers (and other people) to
create a new project in the
mobile area
Current restriction:
Only one Perforce server, one
depot enabled
Project
lead
P4MS
Generate
path in
Perforce
Project
creation
request
Project
creaGon
self-‐service
20. 20
Frontend for project creation self-service
Perforce server selection
(currently only one possible)
Perforce depot selection
(currently only one possible)
Enter team members
21. 21
The future: project creation self-service for all
servers and depots
Perforce
server
selection
Perforce depot
selection
Alternative:
“I want the new
project to be created
at the same location
where I already have
another project”
Create also the
given codelines
22. 22
The sophisticated future: free project and
codeline permission definition
Select the project
Grant accesses to
groups for codelines
of the project
23. 23
The sophisticated future: use-cases for self-
services
Project
managers
P4MS
Generate
path in
Perforce
Project
creation
AdministraGve
Self-‐services
Codeline
creation
Permission maintenance
for project
Generate
protections
in Perforce
Central Perforce
Administrator
24. 24
Major take-aways
• Establish standards and enforce them
• Enable the teams
• Don‘t be a central bottleneck