Driving Innovation with Component-based Development at Boeing
Download as PPTX, PDF0 likes2,027 views
Daniel Anolik, a solutions architect at Boeing/Jeppesen, has extensive experience in supply chain management and software development, emphasizing team collaboration and component-based development. Jeppesen, a longstanding company in aviation safety, employs over 500 developers and manages a vast array of software products, utilizing a shared component system to optimize efficiency. Key processes include versioning, project specifications, and fostering productivity through internal open-source models and dedicated package stewards.
Driving Innovation with Component-based Development at Boeing
- 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