#

Daniel AnolikSolutions Architect, Jeppesen

Driving Innovation with Component-based Development

#

Daniel AnolikSolutions Architect, Airborne Navigation SystemsJeppesen (A Boeing Company)• 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…

#

Daniel AnolikSolutions Architect, Airborne Navigation SystemsJeppesen (A Boeing Company)• 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:

#

Jeppesen at a Glance• 80-year strong company founded in aviation safety• Wide array of software supporting:

– airborne navigation systems– flight planning services– pilot training – airline operations management

#

• 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

Software Development at Jeppesen

#

• 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

Enterprise Architecture Approach

#

• 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!

SCM Approach

#

• over 500 developers in Perforce• over 200 shared packages• over 1000 releases• over 100 projects• over 11 international sitesand growing…

Where Are We Now?

#

So how does it work?

#

• 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.

p4 sync //jeppesen-terminology/…

#

//da/applications

/category1, /category2, etc..

/packageA, /packageB, etc…

/libraries/category3, /category4, etc..

/packageC, /packageD, etc…

/resources

/more packages…

Our “Package Library” Depot

#

Branching Library Packages

v2

v3

v4

2.0 2.1 2.2

3.0 3.1 3.2

4.0 4.1 4.2 4.3

“streams” are codelines that we create at

the beginning of a development cycle,

targeted towards a release

Note: we were using the term ‘stream’ before the Perforce stream existed

Merge your changelists

“downstream”

#

//da/libraries/category3/packageX/streams

/v01

/v02

/releases

/1.0

/1.1

/1.2

/2.0

A Closer Look at the Depot

Each package contains their own ‘streams’ and ‘releases’

#

//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/…

Mapping Packages into View Specs

#

• Right.

Oy!That looks very cumbersome!

#

• 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

Enter: The Project as an SCM Unit

#

• 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

Version Your Project Definitions!

#

• Front end utility for creating, updating and removing workspaces

• Abstraction layer for working with projects

• Manages view specs

• Automates naming conventions and other policies

Introducing Halyard

#

• 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

Inside Halyard

#

• P4V ‘Custom Tools’ extend the GUI

• Right-click context menus integrate depot paths and changelists

Now for some examples….

P4V Integration

#

Create a new workspace by

browsing to the depot path

#

“Rebase” will update theview spec then

sync files

#

Rebase your workspace to any

changelist

#

• Engineers like to be productive– Make your SCM plan “user friendly”

– Provide a solution that makes your developers more productive and they are more likely to adopt it

• Component sharing is part political, part technical – Focus on clearing the technical obstacles

Lessons Learned (or Verified)

#

• 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

The “Inter Sourcing” Mindset

#

Any Questions?

#

##

Thank you!And have a safe flight home.

Daniel Anolikdaniel.anolik@jeppesen.com