White Paper for Samsung's presentation by Sungchul "Steve" Kim

1. Configuration and build management of Product line development
with Perforce

2. Perforce User Conference 2011 Version: Draft
Configuration and build management of product line development with Perforce Date: 2011-03-16
Revision History
Date Version Description Author
2010-03-15 Draft Initial draft Steve Kim
Samsung SDS, 2011 Page 2 of 9

3. Perforce User Conference 2011 Version: Draft
Configuration and build management of product line development with Perforce Date: 2011-03-16
Table of Contents
1. Introduction 4
2. Product-line development 4
1.1 Definition 4
1.2 Considerations 5
1.3 Depot structure 5
1.4 Branch Strategy 6
1.5 Baseline Strategy 7
1.6 Integration with the defect tracking tools 8
1.7 Build and release strategy 8
Samsung SDS, 2011 Page 3 of 9

4. Per
rforce User Connference 2011 Version: Draft
Connfiguration and build manage
d ement of produ line develop
uct pment with Per
rforce Date: 2011-03
3-16
1. Introduction
Product-line development engineering ( or Platform bas developmen engineering ) has been ado
e o sed nt g opted in the org
ganizations
whi want to dev
ich velop and releaased multiple embedded prod
e ducts simultaneeously to enhan the efficien of SW development.
nce ncy
Many organi izations struggl with the com
le mplexity in inherent in develo
oping and enhaancing a produc family. This complexity ca
ct s an
be m
managed both by maintaining a strong focu on the reusab SW archite
g us ble ecture and by controlling the g
governance on the SW
n
dev
velopment proc cess.
Variation ma
anagement in product line dev
p velopment is th key element to distinguish the other deve
he t h elopment process.
Software dev
velopment and maintenance are dynamic pr
a rocesses where software consstantly evolves. So, Configura
ation
man
nagement is the control of the evolution of the system.
e t
Concentratin on the config
ng guration manag
gement and bu managemen this articles explains how the configura
uild nt, s w ation and build
mannagement can be implemente in the product-line develop
b ed pment environm based on the experience from the cust
ment e tomer who has
dev
veloped multipl products sim
le multaneously.
2. Product-li developm
ine ment
1.1 Definition
Software pro oduct line is a well-known app
w proach in the field of softwar engineering. In a software product line, a set of related
f re .
products are produ uced through th combination of reused cor assets togeth with produc specific cust
he n re her ct tom assets[1]. Due to the
cha
aracteristics of product line de
p evelopment, it has a managem issues, su as change c
ment uch control and evoolution manage ement.
[ Figure 1 ] General config
G guration mana
agement and asset evolution model for sof
a ftware product line [1]
t
To avoid the ambiguity and misunderstan
d nding, it is need to define an explain the terminologies used in this pa
ded and aper.
Component : A component is the basic un for configur
t nit ration managemment. For exammple, a single f could be a component.
file
A set of files that unite to pe
erform a fuctio or form an in
on nheritance tree is also called a component.
e
Asset : An as is a collect
sset tion of compon
nents. An asset may contain o or more co
t one omponents.
Core Asset : A Core asset contains a set of domain spec
c o cific but applicaation independ componen that can be a
dent nts adapted and
reused in vario related pro
ous oducts. Core asset is one of th most import concepts in a software pr
he tant n roduct line.
Custom asset : A custom as contains a set of applicat
t sset tion specific co custom asset is not designed for reuse,
omponents. A c s
but produced for a specific application.
d c
Samsung SD 2011
DS, Pag 4 of 9
ge

5. Per
rforce User Connference 2011 Version: Draft
Connfiguration and build manage
d ement of produ line develop
uct pment with Per
rforce Date: 2011-03
3-16
Product : A product is a col
p llection of core assets and custom assets. Pr
e roducts share t same or sim
the milar core asset
ts.
ance : After a new product is produced, it may also need to be configura
Product insta n m o ation managed. The product u
under
configuraation managem is called product instanc e.
ment p
ons
1.2 Consideratio
The product line development requires mu more effor to construct the reusable a
uch rts t architecture and also to maint it which ca
d tain an
be c
continually reu
used by all deviices. Many app proaches on the product line d
e development a well defined But, most of the
are d. f
organization had failed to achiev it. Based on the experience from the cust
f ve n e tomers, the ma
aintenance of th reusable arc
he chitecture and
prac
ctices require much more eff
m forts and costs than implemen
t nting those.
Concentratin on the config
ng guration and bu manageme The consid
uild ent, derations of de
eveloping and m
maintaining bo core assets
oth
and custom assets are shown as following.
d s
1) The code structure of repository to manage both a common assets and variant as
r m c s ssets
2) Brach sttrategy for rulin the development process
ng
3) Baseline strategy for each asset and a whole produc
e ct
4) Integrati with the de
ion efect tracking to
ools
5) Daily Bu and Releas process
uild se
1.3 Depot struct
ture
The structure of repository of configuratio managemen tools should be deeply con
e on nt nsidered with th SW architec
he cture, the
stru
ucture of the de
evelopment tea the access control, the cha
am, c aracteristics of the product.
f
We can devis the several alternatives how to put assets in Depots of P The last on is preferred b the conveni
se a w s P4. ne by ience to manag
ge
the assets.
- Each de
epot holds each asset
h
- One dep holds all as
pot ssets
- One dep holds multi assets by the characterist of assets. F example, A related core a
pot iple t tics For assets are put o a depot.
on
As a rule of thumb, when th count of ass reach over 10 items, you ’d better to put related assets on a single de
t he sets t epot. Too many y
dep usually tak the time of users to navigat them.
pots ke u te
We can categ gorized the typ of depots as three types. First type is for Core Assets, S
pes s F r Second type is for Custom A
s Assets, Third typ
pe
is fo advanced as
for ssets which are immature asse under the development fo the pilot prod
e ets d or ducts.
[ Figure 2 ] Organizing the projects in P4
O e P
To manage assets, the addit
a tional informat
tion should be also managed by the tools or the systems. I includes the followings :
r It
1) The mem
mbers who part veloping each asset. Only, th can modify the codes of a
ticipated in dev hey y asset.
Samsung SD 2011
DS, Pag 5 of 9
ge

6. Per
rforce User Connference 2011 Version: Draft
Connfiguration and build manage
d ement of produ line develop
uct pment with Per
rforce Date: 2011-03
3-16
2) The admministrators of each asset. The are in charge of assigning new developer into the mem
e ey rs mber, making a baseline for
releasing an asset.
g
3) The poli which contr integrating and locking the branch.
icy rols g t
Each asset is controlled by a team develop
s ping and maint taining a softw
ware which accounts for the re
equirements. It also has a
t
ferent level of control depend on the type of asset. There is a new concep in order to m
diff c d f pt manage an asse So, I called the control uni
et. it
of e
each asset as “PProject”. Project is shown as a directory or a branch in P4 The naming r
4. rule to differen
ntiate Project w directory is
with
useful.
Unfortunatel P4 doesn’t the concept of project until no so the assi
ly, t p ow, istance system will be needed to use it. The following
d
feat
tures are suppo
orted by the sys
stem :
- To add new members and to view th registered members and th administrators of the projec
he m he ct
- To crea the branch and view the hi
ate a ierarchy of all branches whic are belong to a project
ch o
- To set the access cont by the adm
t trol ministrator of a project by them
mselves withou the assistanc of the admin
ut ce nistrator of
Perforce
1.4 Branch Stra
ategy
The decision on which bran strategy ca be applied depends on the conditions suc as the matur of develope and the size
n nch an ch rity ers e
of t
team and the qu uality requirem of assets. When the size of team and th quality requi
ment W he irement are hig the more br
gh, ranches are
neeeded.
In case of a Core assets, the high quality requirements re
C e r equire more qu uality assuranc activities suc as a code rev
ce ch view and
test
ting. So, the ch
hanges should be separated by the branch an should be co
b y nd ontrolled by the policy. Becau of more de
use evelopers migh
ht
be aassigned to a te to develop core asset tha custom asset
eam p an ts.
In case of a custom asset, th codes are cu
c he ustomized for a specific prod
duct. The qualit requirement is less importa and the size
ty t ant e
of t
team is less sm than cores assets.
mall a
A project of developing ass has several branches in which the codes are evolved a controlled by the policy. The branches
sets w s and
und the project are logically or
der a rganized as a hierarchy which can guide the flow of integ
h h e gration among t branches. P
the Please refer to
Figu 3.
ure
[ Figure 3 ] The organizati of branche of a project managing a co asset
T ion es ore
In Figure 3, the activities of change mana
t agement for dev
veloping a core asset are as f
e followed :
1) Each dev
veloper owns a development branch in whic he changes the codes to ac
ch ccomplish the change require
ement.
Samsung SD 2011
DS, Pag 6 of 9
ge

7. Per
rforce User Connference 2011 Version: Draft
Connfiguration and build manage
d ement of produ line develop
uct pment with Per
rforce Date: 2011-03
3-16
2) When he completed hi work, he inte
e is egrate all chang to the uppe branch.
ges er
3) On each change requir
h rement, Code re
eviewer makes a review on a changes gath
s all hered from the lower branche by referring
e es
to changgelists which ar linked with Jobs in P4.
re J
4) After completing a cod review, the passed changel
de p lists are integra
ated into the up
pper branch.
5) All the changes from th lower branc
c he ches are built with the other a
w assets. After su
ucceeding in bu
uilding, SQA a
activities are
performe ed.
6) After SQ activities, All successful codes can be in
QA A c ntegrated into t RELEASE branch.
the E
7) All integ
grated changes also should be integrated fro the upper br
e om ranch into the lower branch b turns.
by
There might be an argumen on maintaini the separate branches ba
nt ing ed ased on the pha of maturing the codes. Th are pros an
ase g here nd
con Notwithstan
ns. nding its compl
lexity and sacrifice of the per
rformance, Sep
parated branch can provide us to release mo safe asset to
s ore o
the developers wh should comb them into their own asse
ho bine et.
When we dev the branch strategy, the policies of con
vise h p nfiguration man nagement whic governs the activities of un
ch nder a project
also should be def
o fined. these policies usually control these ki
c inds of activiti es such as Sub
bmitting, Integr
rating, Labelin
ng.
Submitting :
When some changelists are submitted, the should be lin
c e ey nked with at le one job. It will be possib when the int
east ble tegration
betwween P4 and th defect tracki tool correc are synchro
he ing ctly onized each oth
her. It can be i
implemented b the trigger o Perforce. The
by of e
trig
gger might be affected on the developer’s br
a ranch in which all changes wi be made.
ill
Integrating :
The status of Jobs which were linked with changelists are verified whe
f w h ether the status is allowed to integrate into t upper branch.
s the
The allowable stat of jobs are different based on the branch The contro of integratin flow also should be devise in order to
e tus d hes. ol ng ed
prev the develo
vent opers making a mistakes whe they integrat their codes. In the Figure 4 we show the sample policy of the
en te 4, e y
inte
egration flow among the bran
a nches. Most pol licies related In
ntegrating are i
implemented b writing a scr
by ripts on P4 Brooker.
[ Figure 4 ] The matrix of integrating flo among bran
T f ow nches
Labeling :
the naming ru of label might be verifie with the trigg of P4, whe the label wa created and m
ules m ed ger en as modified. Sometimes, the
con
ntrol to check only the creator of label can modify the cont
o r m tents of label w be needed
will
1.5 Baseline Str
rategy
Two types of baselines mig be needed for supporting the product lin developmen One type of baseline is use to attach it on
f ght f ne nt. ed o
each asset. It can be attached on any branch of asset in accord
h b f dance with the purpose of a b
e baseline. The m purpose o baseline is to
main of o
Samsung SD 2011
DS, Pag 7 of 9
ge

8. Perforce User Conference 2011 Version: Draft
Configuration and build management of product line development with Perforce Date: 2011-03-16
get the list of all files with version for synchronizing into the workspace.
The other type of baseline is used to reproduce a set of all files which compose a product. In our environment, with a label of P4,
we can aggregate all assets, because of assets are dispersed. So, new concept of attaching a baseline on a product is adopted. we call
it as “Composite baseline”. When releasing a product, Integrator used to make a composite baseline by aggregating right baselines of
assets which composing a product.
Composite baseline should provide the following functionality in the product line development.
1) To keep the labels which were already tagged on assets composing a product.
2) To synchronize all assets with a client workspace of developers by using a composite baseline.
3) To view all composite baselines belong to each branch of a project.
Baseline is used for releasing a set of files with version on each public asset. With the released baseline, the product developers
who develop a custom asset used to synchronize all assets into their client workspace in order to check whether his changes are fit to
the other assets which are already released.
Baseline can also be used for showing the maturity of the code. Naming rules of baseline are very useful to indicate which
maturity level of codes are acquired.
1.6 Integration with the defect tracking tools
Organizations which own over mid-size developers ( > 50 ) already are fully equipped with the defect tracking tools. Most of
change requests such as new requirements, enhance requirements, defects are managed by the defect tracking tool. All change
requests which are related with modifying the files under P4 should be integrated through Job between the defect tracking tool and
Perforce. To avoid the inconsistency of data, One way synchronizing is recommended. It mean that all contents of a change request
can be modified only in the defect tracking tool.
When you link a job with changelists in P4, these relationship can be sent to the defect tracking tools. This feature gives a
developer finding out which changelists and files were modified by change requests. With these relationship, we can generate a
release notes automatically when assets are released by collecting all jobs which have contributed to the current release of asset.
1.7 Build and release strategy
In product line development, Build and release management also are seemed more complex than the conventional development.
This complexity is caused by the difficulty to combine a set of the right versions of assets. For example, when one of core assets was
released for accounting for new requirements. The newly released core asset should be built and testified by all products with the
other assets. In real environment, most of core assets are release frequently. It made the developers feel difficult to combine a set of
all asset without errors.
To avoid the inefficiency on building and releasing which caused by the miscommunication among the projects who develop
assets, there should be a well-defined and detailed process of build and release. The process should be specified such as the
followings :
1) Which kinds of builds will be run by whom
2) The rule of synchronizing the source code when the builds of all products start
3) When assets will be released and which quality assurance activity will be done
There are several types of builds, such as Integration builds, Daily builds, CI ( Continuous Integration ) builds. On each project
who develop assets, the integration builds and CI builds may be done to verify whether its own changes will be fit with the other asset
during the business hours. And then, at night, the daily builds of all products will be started by the automation build tools with the
same rules of synchronizing the source codes.
Samsung SDS, 2011 Page 8 of 9

9. Per
rforce User Connference 2011 Version: Draft
Connfiguration and build manage
d ement of produ line develop
uct pment with Per
rforce Date: 2011-03
3-16
At the morni of next day the developer check the results of the dai builds of all products which combined b
ing y, rs ily both core assets
s
and custom assets If there are no build error. The quality ass
d s. T surance works will be perform And then, Core assets an custom
med. nd
asse are released with the relea baselines by turns.
ets d ase
[ Figure 5 ] Daily Build and release pro
a ocess
Related with P4 in build an release mana
h nd agement. The following func
f ctionalities of s
synchronizing t source code in build
the es
auto
omation tool sh
hould be provided :
1) onizing the latest label of each asset
Synchro h
2) Synchro
onizing the latest composite baseline of a pro
b oduct
3) Synchro
onizing the speccific label/chan
ngelist of each asset
4) Make a baseline of eac asset
b ch
5) Make a composite base
c eline of a produ
uct
6) Automattically generate the release notes of each asset with P4 jo which gath
es n a obs hered from the defect tracking tools/systems
g s
Samsung SD 2011
DS, Pag 9 of 9
ge