doc/html/scramintro.html

<! Style Sheet Header>
<html>
<head>
<title>scramintro.html</title>
<body bgcolor=beige>
<! End Style Sheet Header -----------Insert Text Here --------------------->
<center>
<H1>SCRAM</H1>
<font color=red>S</font>oftware <font color=red>C</font>onfiguration,
<font color=red>R</font>elease <font color=red>A</font>nd
<font color=red>M</font>anagement
</center>
<hr>
<h2>Background</h2>
        SCRAM has been developed to enable large, geographically dispersed and
autonomous groups to work together on software development projects.
The groups, primarily based in universities and national institutions,
independently manage their own resources. As such it can be extremely
difficult or even impossible to impose software process, adequate
documentation levels and heavy resource requirements - such as dedicating
entire machines to a single software development project.
<p>
        The philosophy throughout the SCRAM project is, therefore, to
encourage good practice by making the intuitive easy and convenient way to do
things the right way of doing things. Take for example the fact that SCRAM is
controlled and configured through XML documents. Thus documentation has to
be kept up to date for SCRAM to even function.
<p>
<h2>What is SCRAM?</h2>
<h3>A Configuration Manager</h3>
  The main task of the SCRAM tool is to ensure that all developers are
  working with the same consistent set of products, libraries, environments
  and source codes.
<ul>
<li>External Products Configuration<br>
    A requirement of any SCRAM managed project is an
    explicit statement, in the form of an XML document, of all the underlying
    products and versions of external libraries and other software products
    used. Each product must have a description document to tell SCRAM how
    it is to be used, dependency information, environmental variables,
    default system locations etc. Such description documents can be
    maintained independently of SCRAM and imported into the project by
    SCRAMs built-in url down-loading mechanism.
<li>Common Configurations<br>
    It is often the case that many projects need to share the same configuration
    in order that they can be inter-operable (e.g. Two applications using the
    same database). SCRAM thus provides a mechanism for importing independently
    maintained configuration documents automatically.

<li>Source Code Control<br>
    SCRAM itself is not a code repository but any project must have access to
    one or more such repositories from which it can checkout the appropriate
    code into the appropriate place in the project structure. Currently it
    only supports CVS but this could be easily extended to other repositories
    if required.

<li>Environment Control<br>
    The build and runtime environments are built up from the descriptions
    of those required by external products and project specific environment
    description documents.
</ul>
<h3>A distribution system</h3>
   SCRAM projects can be 'bootstrapped' from a single document that describes
   its structure and download information of other project documents and
   components.<p>
   From this document SCRAM can construct a copy of a project release. Connected
   to a web browser such as netscape makes "single click" installation possible.
   At present SCRAM is unable to automatically install external components
   although the user can be directed to the correct documentation to do this
   themselves. Binary distribution is not supported as building a distribution
   is seen as a check that all the components of the system have been installed
   properly. This feature could be added if user distributions were required.

<h3>A System resource/application interface</h3>
   As no two people are the same, it is often the case that no two machines
   are the same. Products can be installed in different places depending on
   the whims of system administrators, policy makers and system constraints.
   SCRAM matches up the request for a product from a projects configuration
   to the system it is installing the project on. SCRAM does this
   by a number of automated means and if it fails to find a product will prompt
   the user for its location. SCRAM then maintains a database of such system
   information for future reference.

<h3>A Build System</h3>
<ul>
   <li> Abstraction of logical build elements from implementation details
   <li> Associate directory and file structure with build operations
     (e.g. everything in a directory libsrc could be automatically compiled
     into a library ,
      e.g.2 every binary in a directory test could be automatically linked
      with a test utilities library)
   <li> Definition of Classes of build objects.
      e.g A library class can have types such as debug, archive, shared,
      shared debug, profiled etc. Default types can be assigned
      to a class/directory structure but are easy to override on the
      command line.
   <li> Strong environment control. Makes it easy to tweak general rules
      for special cases - something not easy to do in make.
   <li> Abstract dependency specification. You can link in a product by specifying
      its name, SCRAM does the rest taking care of system specifics,
      dependencies etc.
   <li> Module Interfaces can be defined for large software modules to define
      dependencies etc. Other modules can then simply load the interface to use
      the module.
   <li> Compatible with code repositories such as CVS which checkout the file
      with the same date that it was checked in. This is a major flaw in make
      which simply checks to see if a datea > dateb rather than datea != dateb.
</ul>

<h3>A development environment</h3>
   Once a copy of a release is installed and built on a system it can be made
   available for developers by adding it to SCRAMs list of projects.
   Upon selecting an item from this list, a new development area is created
   in which the developer can work independently of everyone else. The
   development area will have the same configuration, environment etc. as
   the base release. It will also automatically use libraries/headers etc.
   from the base release if not rebuilt in the local development area. The
   user is free to use whatever editors and other tools he/she prefers.

<h3>Project Isolation</h3>
   SCRAM ensures that an installed release is independent of any other. This
   allows developers to easily switch between projects/versions they might be
   working on even though they may have very different and conflicting
   environment requirements.

<p>
<h2>Summary</h2>
<ul>
<li>Project installation with a click on a web page
<li>Control of Build Environment, including dependency tracking
<li>Fully configurable build operations, including default operations.
<li>Abstraction of logical build elements from the implementation details
<li>Reuse of configuration management elements between projects.
<li>Configuration specifications with XML documents.
</ul>
<p>
<img src=../images/scram.jpg>
<p>
If you have any ideas 
that you think will make this project better then dont hesitate to tell me
(email me at the address given below).
<! Style Sheet Footer ---------------Do not change anything after this line-->
<hr>
<table border=1 width=100%>
<td align=left>
<a href=mailto:Christopher.Williams@cern.ch
>Chris Williams</a>
</td>
<td align=center>
<script language="JavaScript">
<!---//hide script from old browsers
document.write( "<br>Last updated "+ document.lastModified
);
//end hiding contents --->
</script>
</td>
<td align=right>Show <a href=/cgi-cmc/pagestat>Stats</a>
</td>
</table>
</body> </html>
<! End Style Sheet Footer>
Revision:	1.3
Committed:	Wed Sep 6 16:01:54 2000 UTC (24 years, 8 months ago) by williamc
Content type:	text/html
Branch:	MAIN
CVS Tags:	V0_18_5, V0_18_4, V_18_3_TEST, V0_18_2, BuildSystemProto1, V0_18_1, V0_18_0, V0_18_0model, V0_17_1, V0_18_0alpha, V0_17_0, V0_16_4, V0_16_3, V0_16_2, V0_16_1, V0_16_0, V0_15_1, V0_15_0, V0_15_0beta
Branch point for:	V0_17branch, V0_16branch, V0_15branch
Changes since 1.2:	+113 -4 lines
Log Message:	New Scram description
#	User	Rev	Content
1	williamc	1.1	<! Style Sheet Header>
2			<html>
3			<head>
4			<title>scramintro.html</title>
5	williamc	1.2	<body bgcolor=beige>
6	williamc	1.1	<! End Style Sheet Header -----------Insert Text Here --------------------->
7			<center>
8			<H1>SCRAM</H1>
9			<font color=red>S</font>oftware <font color=red>C</font>onfiguration,
10			<font color=red>R</font>elease <font color=red>A</font>nd
11			<font color=red>M</font>anagement
12			</center>
13			<hr>
14	williamc	1.3	<h2>Background</h2>
15			SCRAM has been developed to enable large, geographically dispersed and
16			autonomous groups to work together on software development projects.
17			The groups, primarily based in universities and national institutions,
18			independently manage their own resources. As such it can be extremely
19			difficult or even impossible to impose software process, adequate
20			documentation levels and heavy resource requirements - such as dedicating
21			entire machines to a single software development project.
22			<p>
23			The philosophy throughout the SCRAM project is, therefore, to
24			encourage good practice by making the intuitive easy and convenient way to do
25			things the right way of doing things. Take for example the fact that SCRAM is
26			controlled and configured through XML documents. Thus documentation has to
27			be kept up to date for SCRAM to even function.
28			<p>
29	williamc	1.2	<h2>What is SCRAM?</h2>
30	williamc	1.3	<h3>A Configuration Manager</h3>
31			The main task of the SCRAM tool is to ensure that all developers are
32			working with the same consistent set of products, libraries, environments
33			and source codes.
34			<ul>
35			<li>External Products Configuration<br>
36			A requirement of any SCRAM managed project is an
37			explicit statement, in the form of an XML document, of all the underlying
38			products and versions of external libraries and other software products
39			used. Each product must have a description document to tell SCRAM how
40			it is to be used, dependency information, environmental variables,
41			default system locations etc. Such description documents can be
42			maintained independently of SCRAM and imported into the project by
43			SCRAMs built-in url down-loading mechanism.
44			<li>Common Configurations<br>
45			It is often the case that many projects need to share the same configuration
46			in order that they can be inter-operable (e.g. Two applications using the
47			same database). SCRAM thus provides a mechanism for importing independently
48			maintained configuration documents automatically.
49
50			<li>Source Code Control<br>
51			SCRAM itself is not a code repository but any project must have access to
52			one or more such repositories from which it can checkout the appropriate
53			code into the appropriate place in the project structure. Currently it
54			only supports CVS but this could be easily extended to other repositories
55			if required.
56
57			<li>Environment Control<br>
58			The build and runtime environments are built up from the descriptions
59			of those required by external products and project specific environment
60			description documents.
61			</ul>
62			<h3>A distribution system</h3>
63			SCRAM projects can be 'bootstrapped' from a single document that describes
64			its structure and download information of other project documents and
65			components.<p>
66			From this document SCRAM can construct a copy of a project release. Connected
67			to a web browser such as netscape makes "single click" installation possible.
68			At present SCRAM is unable to automatically install external components
69			although the user can be directed to the correct documentation to do this
70			themselves. Binary distribution is not supported as building a distribution
71			is seen as a check that all the components of the system have been installed
72			properly. This feature could be added if user distributions were required.
73
74			<h3>A System resource/application interface</h3>
75			As no two people are the same, it is often the case that no two machines
76			are the same. Products can be installed in different places depending on
77			the whims of system administrators, policy makers and system constraints.
78			SCRAM matches up the request for a product from a projects configuration
79			to the system it is installing the project on. SCRAM does this
80			by a number of automated means and if it fails to find a product will prompt
81			the user for its location. SCRAM then maintains a database of such system
82			information for future reference.
83
84			<h3>A Build System</h3>
85			<ul>
86			<li> Abstraction of logical build elements from implementation details
87			<li> Associate directory and file structure with build operations
88			(e.g. everything in a directory libsrc could be automatically compiled
89			into a library ,
90			e.g.2 every binary in a directory test could be automatically linked
91			with a test utilities library)
92			<li> Definition of Classes of build objects.
93			e.g A library class can have types such as debug, archive, shared,
94			shared debug, profiled etc. Default types can be assigned
95			to a class/directory structure but are easy to override on the
96			command line.
97			<li> Strong environment control. Makes it easy to tweak general rules
98			for special cases - something not easy to do in make.
99			<li> Abstract dependency specification. You can link in a product by specifying
100			its name, SCRAM does the rest taking care of system specifics,
101			dependencies etc.
102			<li> Module Interfaces can be defined for large software modules to define
103			dependencies etc. Other modules can then simply load the interface to use
104			the module.
105			<li> Compatible with code repositories such as CVS which checkout the file
106			with the same date that it was checked in. This is a major flaw in make
107			which simply checks to see if a datea > dateb rather than datea != dateb.
108			</ul>
109
110			<h3>A development environment</h3>
111			Once a copy of a release is installed and built on a system it can be made
112			available for developers by adding it to SCRAMs list of projects.
113			Upon selecting an item from this list, a new development area is created
114			in which the developer can work independently of everyone else. The
115			development area will have the same configuration, environment etc. as
116			the base release. It will also automatically use libraries/headers etc.
117			from the base release if not rebuilt in the local development area. The
118			user is free to use whatever editors and other tools he/she prefers.
119
120			<h3>Project Isolation</h3>
121			SCRAM ensures that an installed release is independent of any other. This
122			allows developers to easily switch between projects/versions they might be
123			working on even though they may have very different and conflicting
124			environment requirements.
125
126	williamc	1.2	<p>
127	williamc	1.3	<h2>Summary</h2>
128	williamc	1.1	<ul>
129			<li>Project installation with a click on a web page
130			<li>Control of Build Environment, including dependency tracking
131			<li>Fully configurable build operations, including default operations.
132			<li>Abstraction of logical build elements from the implementation details
133			<li>Reuse of configuration management elements between projects.
134	williamc	1.3	<li>Configuration specifications with XML documents.
135	williamc	1.1	</ul>
136			<p>
137	williamc	1.2	<img src=../images/scram.jpg>
138			<p>
139			If you have any ideas
140	williamc	1.1	that you think will make this project better then dont hesitate to tell me
141			(email me at the address given below).
142			<! Style Sheet Footer ---------------Do not change anything after this line-->
143			<hr>
144			<table border=1 width=100%>
145			<td align=left>
146			<a href=mailto:Christopher.Williams@cern.ch
147			>Chris Williams</a>
148			</td>
149			<td align=center>
150			<script language="JavaScript">
151			<!---//hide script from old browsers
152			document.write( "<br>Last updated "+ document.lastModified
153			);
154			//end hiding contents --->
155			</script>
156			</td>
157			<td align=right>Show <a href=/cgi-cmc/pagestat>Stats</a>
158			</td>
159			</table>
160			</body> </html>
161			<! End Style Sheet Footer>