Learn how Boeing has improved collaboration and innovation by enabling easy sharing of components across many software projects.

1. #
Daniel Anolik
Solutions Architect, Boeing/Jeppesen

2. #
• 8 years with Jeppesen
• 15 years of direct SCM experience, 8 with Perforce
• Software developer, solutions architect, Scrum master,
bluegrass mandolin picker, wilderness survival enthusiast…

3. #
• 8 years with Jeppesen
• 15 years of direct SCM experience, 8 with Perforce
• Software developer, solutions architect, Scrum master,
bluegrass mandolin picker, wilderness survival enthusiast,
and lucky father of this baby girl:

4. #
• 80-year strong company founded in aviation safety
• Wide array of software supporting:
– airborne navigation systems
– flight planning services
– pilot training
– airline operations management

5. #
• Team sizes from 2-50 developers
• Full range of deployment targets
– Web
– Windows/Mac/Linux and other embedded devices
– iOS/Android/Windows mobile devices
• Lots of overlapping technology across products

6. #
• Leverage the best features and innovative
technologies across our product lines
• Leverage the strengths of our different teams
• Pursue component based development
• Minimize development overlap across teams, and
re-use the best implementation of each technology

7. #
• Optimize for collaboration
– Make it easy to share components
– Make it easy to use shared components
• Empower your developers
– Establish SCM framework, train the teams, then stay out
of the way of any day-to-day activities
• The ‘right’ way to work should also be the easiest
• Version everything!

8. #
• over 500 developers in Perforce
• over 200 shared packages
• over 1000 releases
• over 100 projects
• over 11 international sites
and growing…

9. #

10. #
• A component is an artifact that we clearly identify
in our software systems. It should have an
interface and encapsulates internal details.
• A package is the smallest unit of software that we
will independently version and release. One or
more software components may be bundled
together into a single package.

11. #
//da
/applications
/category1, /category2, etc..
/packageA, /packageB, etc…
/libraries
/category3, /category4, etc..
/packageC, /packageD, etc…
/resources
/more packages…

12. #
v2
v3
“streams” are codelines that we create at
the beginning of a development cycle,
targeted towards a release
v4
2.0 2.1 2.2
3.0 3.1 3.2
Merge your changelists
“downstream”
4.0 4.1 4.2 4.3
Note: we were using the term ‘stream’ before the Perforce stream existed

13. #
//da/libraries/category3/packageX
/streams
/v01
/v02
/releases
/1.0
/1.1
/1.2
/2.0
Each package
contains their
own ‘streams’
and ‘releases’

14. #
//da/application/category2/packageA/streams/v03/…
//**WORKSPACE**/da/packageA/...
//da/libraries/category1/packageB/releases/v04.2/...
//**WORKSPACE**/da/packageB/…
//da/libraries/category3/packageC/releases/v01.0/…
//**WORKSPACE**/da/packageC/…

15. #
• Right.

16. #
• Engineers interact with projects, not depot paths
• Each Project Defines:
– which packages will be used
– the individual package versions
– package permissions (rw/ro)
• View specs are handled auto-magically

17. #
• Project specifications:
– are simple text files
– live within the application packages they define
– just another versioned object in Perforce
– define the project name, status and current view spec

18. #
• Front end utility for creating, updating and
removing workspaces
• Abstraction layer for working with projects
• Manages view specs
• Automates naming conventions and other policies

19. #
• Client is written in Ruby.
– Currently running on Linux, OSX, HPUX and Windows
– Uses p4ruby API for all client/server interaction
• No server processes needed outside of P4D
• Triggers used to update global project indexes
automatically
• P4V ‘Custom Tools’ extensions used to provide
easy GUI integration

20. #

21. #
• Component sharing is part political, part technical
– Focus on clearing the technical obstacles
• Engineers like to be productive
– Provide a solution that make your developers more
productive and they are likely to adopt it

22. #
• Apply open source models internally
– Share more code within your company
– Welcome contributions to your code from other teams
• Identify ‘stewards’ of shared packages
– Help ensure that contributions still meet the design
goals of the shared package

23. #

24. #
Daniel Anolik
daniel.anolik@jeppesen.com