Technologies
B.V.
Configuration Management in relation to
Software/Platform Development and
Integration @ Océ Technologies B.V
Xavier Brankaert
Software Team Lead/Integrator
Outline of this presentation
Introduction
About Océ : Some facts
Context
Way of Working
Typical Configuration Management Examples
Lessons learned (The hard way)
How we worked with CM
How we work now
What will we do in the future
(Components Based Developments)
Contact information
2
About Océ: who is Océ?
We are a Dutch international company
24,000 people world-wide (1800 R&D)
Annual revenue 2006: € 3,1 billion
World-wide distribution in 90 countries
Direct sales and services in 30 countries
8 R&D-sites in 7 countries
(Munich, Paris, Namur, Phoenix, Timisoara,
Vancouver, Venlo, Eindhoven High Tech Campus)
HQ based in Venlo, the Netherlands
We have a 130 year old tradition of innovation
Our motto is „printing for professionals‟
3
Context
Roles
Software Engineer
Do the actual work…
Configuration Manager
Releasing, Baselines, Reconfigure Templates (I.e. what must
be combined)
Integrator
Integration of Software changes,
Development TREE handling/definition
Problem Analysis
Often these roles are combined
4
Context
Currently under development
2 active mainlines and 1 maintenance:
REF8D->REF8E->REF8F (Maintenance)
REF10 (Product line 1)
REF11 (Product line 2, New Architecture)
5 different product types
6 engineering teams ( [Paris, Venlo] * 3 projects)
Grand total of about 60 software engineers
Code base of about 1.5 Million LOC
5
Context
In a picture
Product Line 1 Product Line 2
REF10 REF11
6
Way of Working
Way of Working
Problem/Task based (using Continuus CM Synergy)
Checkin Rules (avoid failed builds/fix failed builds)
TICS Coding Rule checking
Using Automatic Testing to prove correctness of
changes.
Working in Releases
7
Way of Working (Examples)
Merging
8
Way of Working (Examples)
Complexity (avoid conflicts)
9
Way of Working (Examples)
Branching (e.g. for a release)
10
Learned lessons
Controller CM/Integration
We became aware of items that were missing from
earlier developments and we implemented:
Mainline TREE chaining containing all tasks of the
previous TREE(s)
Separate developments are possible using different
“SQA” versions based on the same mainline.
It also became clear that even when a product is not
being developed for a specific REF, it is crucial to keep
testing the product to be able to continue development
later.
11
Learned lessons
Controller CM/Integration
Using parallel TREES to implement risk full changes
works well.
Automatic Testing is crucial used to cope more and
more with diversity of products and product
functionality (Regression Testing).
Integration == Configuration Management
12
Learned lessons
Controller Integration/CM first improvements
Coupled releases (requires merging), better than
missing fixes
More and more complexity is added. Introduction of
more parallel branches and SQA versions to allow for
multiple feature development for multiple products
simultaneously. While allowing these products to
develop and release on the same baseline.
Support for Multiple Clients (More products/versions)
Avoid unnecessary Product Specific Code
Integration Teams “owner” of the Tree/tools
13
Near Future (I.e. new Architecture line)
Evolutions
More and more component based developments and
integration, allowing for focus on and integration of well
managed interfaces (in order to develop functionality
faster).
Faster Integration of more complex changes
More and More focus on Configuration Management
of components
Well Managed Interfaces
CM relates directly to Architecture (interfaces and
Components) and Integration (Component Tests,.
Component Quality Criteria, Asset Board etc.)
14
Contact us?
Websites
www.oce.com
www.oce.nl/jobs
E-mail:
xavier.brankaert@oce.com (R&D)
lucas.cras@oce.com (HRM)
recruitment@oce.com
For a job, a graduation assignment
or just to get more information
15
16