|
1 #!perl |
|
2 # Copyright (c) 2000-2009 Nokia Corporation and/or its subsidiary(-ies). |
|
3 # All rights reserved. |
|
4 # This component and the accompanying materials are made available |
|
5 # under the terms of the License "Eclipse Public License v1.0" |
|
6 # which accompanies this distribution, and is available |
|
7 # at the URL "http://www.eclipse.org/legal/epl-v10.html". |
|
8 # |
|
9 # Initial Contributors: |
|
10 # Nokia Corporation - initial contribution. |
|
11 # |
|
12 # Contributors: |
|
13 # |
|
14 # Description: |
|
15 # |
|
16 # |
|
17 # Description: |
|
18 # Licensee Product Environment |
|
19 # |
|
20 |
|
21 =head1 Licensee Project Environment |
|
22 |
|
23 The processes for distributing source code and binaries between engineers has a large impact on the efficiency of both the development and integration phases of a project. The efficiency of these processes is even more significant when a project is being developed between multiple sites that are geographically separated. The LPD release tools address the key elements of this process, making the human tasks required to distribute software as simple as possible. The following points characterise the projects LPD are generally involved with: |
|
24 |
|
25 =over 4 |
|
26 |
|
27 =item * |
|
28 |
|
29 Integration is centrally owned and performed by a dedicated integration team. The integration team are responsible for collecting all software modules delivered by multiple external and internal parties, and assembling them into a self-consistent sofware platform. |
|
30 |
|
31 =item * |
|
32 |
|
33 Many 3rd parties are involved in delivering software modules into the integration team. It is important, therefore, to have a standard means of delivering software irrespective of the package's origin. |
|
34 |
|
35 =item * |
|
36 |
|
37 There are dependancies between the software 3rd parties. |
|
38 |
|
39 ...delivery of software packets into the integration team is not a one-way process. Unofficial baselines are typically maintained in different sites amongst integration-clusters. All software packets may be delivered to all development groups. |
|
40 |
|
41 =item * |
|
42 |
|
43 different 3rd parties have different SLDA's and therefore are entitled to differing source IPR categories |
|
44 |
|
45 ...there is no single customer and so provision must be made for protecting source code IPR and confidentiality. |
|
46 |
|
47 =item * |
|
48 |
|
49 contributing software teams may have close dependancies, and form natural integration clusters |
|
50 |
|
51 ...telephony, for example, consists of a number of contributing components and may choose to release a sub-system of components before submitting to the rest of the porject. |
|
52 |
|
53 =item * |
|
54 |
|
55 software author's development environments should never become too old, and hence require updating frequently |
|
56 |
|
57 ...developing against an old environment always leads to unecessary integration problems. This most frequently occurs when the cost of upgrading a development environment is large; in terms of time, network bandwidth, and local storage. |
|
58 |
|
59 =item * |
|
60 |
|
61 an effective integration team must be capable of fast baseline turnaround |
|
62 |
|
63 ...delays in baseline deliveries result in a larget than normal volume of unintegrated code getting submitted to the next build. It is therefore more likely to be late again. |
|
64 |
|
65 =back |
|
66 |
|
67 =head1 Software Distribution |
|
68 |
|
69 There are two main strategies for distributing source and binaries: |
|
70 |
|
71 =over 4 |
|
72 |
|
73 =item * |
|
74 |
|
75 component releases |
|
76 |
|
77 =item * |
|
78 |
|
79 monolithic environments |
|
80 |
|
81 =back |
|
82 |
|
83 =head2 Component Releases |
|
84 |
|
85 The component release strategy involves modularising the project into a set of named components. These generally map onto the source level modularisation. Component owners are identified and are responsible for compiling a set of binaries for use by the rest of the developers at regular intervals. An integration team is responsible for identifying a set of versioned releases that work together. |
|
86 |
|
87 =head2 Monolithic environments |
|
88 |
|
89 These are the direct ouputs of a centralised build process, where all software components are built from source on a single machine, using a uniform procedure. A build team is employed to perform these builds at regular intervals on the latest source. The results of the build are packaged into a small number of large F<.zip> files for distribution. |
|
90 |
|
91 Each of these approaches is best suited to particular applications and address some of the same problems. They both have a number of advantages and disadvantages. |
|
92 |
|
93 In addressing the key aspects of the Licensee project environment described at the start, the LPD Release Tools combine the strengths of both distribution methods: |
|
94 |
|
95 =over 4 |
|
96 |
|
97 =item * |
|
98 |
|
99 reduce the data transfer between sites |
|
100 |
|
101 =item * |
|
102 |
|
103 reliable environment sharing between sites |
|
104 |
|
105 =item * |
|
106 |
|
107 ability to verify the I<current> state of a development drive |
|
108 |
|
109 =item * |
|
110 |
|
111 incorporation of I<mainline builds> with I<component releases> (ie, validateenv) |
|
112 |
|
113 =item * |
|
114 |
|
115 facilitate I<integration clusters> |
|
116 |
|
117 =item * |
|
118 |
|
119 fast baseline turn-around |
|
120 |
|
121 =back |
|
122 |
|
123 =head1 COPYRIGHT |
|
124 |
|
125 Copyright (c) 2000-2009 Nokia Corporation and/or its subsidiary(-ies). |
|
126 All rights reserved. |
|
127 This component and the accompanying materials are made available |
|
128 under the terms of the License "Eclipse Public License v1.0" |
|
129 which accompanies this distribution, and is available |
|
130 at the URL "http://www.eclipse.org/legal/epl-v10.html". |
|
131 |
|
132 Initial Contributors: |
|
133 Nokia Corporation - initial contribution. |
|
134 |
|
135 Contributors: |
|
136 |
|
137 Description: |
|
138 |
|
139 |
|
140 =cut |