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:Shaun.Ashby@cern.ch
>Shaun Ashby</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.4
Committed:	Fri Jul 20 12:21:28 2001 UTC (23 years, 9 months ago) by sashby
Content type:	text/html
Branch:	MAIN
CVS Tags:	V0_19_6, V0_19_6p1, V0_19_5, SFATEST, V0_19_4, V0_19_4_pre3, V0_19_4_pre2, V0_19_4_pre1, V0_19_3, V0_19_2, V0_19_1, V0_19_0
Branch point for:	V0_19_4_B
Changes since 1.3:	+2 -2 lines
Log Message:	Updated documentation.
#	Content
1	<! Style Sheet Header>
2	<html>
3	<head>
4	<title>scramintro.html</title>
5	<body bgcolor=beige>
6	<! 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	<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	<h2>What is SCRAM?</h2>
30	<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	<p>
127	<h2>Summary</h2>
128	<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	<li>Configuration specifications with XML documents.
135	</ul>
136	<p>
137	<img src=../images/scram.jpg>
138	<p>
139	If you have any ideas
140	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:Shaun.Ashby@cern.ch
147	>Shaun Ashby</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>