Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[alf-dev] Build SCM Use Cases

As discussed today in our meeting  rather than too course grained it
seems perhaps we are focusing on detail a bit too much and should
probably consider (at least briefly) more scenario level use cases to
get at what is important for an ALF vocabulary.  The use cases currently
in play are at a function level and its easy to get bogged down in
detail while missing the big picture.

With that in mind we came up with a few "scenarios" and discussed some
variations.

1. Scheduled Build
The build is schedule to happen at a particular time. It is general
configured to build a particular configuration (build this version of
these components) or follow a particular predefined pattern  (eg. Lable
latest, get it and build it).  The usual purpose of this kind of build
is to provide a known version for the next day's work

2. On Demand Build
This build is unscheduled and occurs at the request of a user or tool
for ad hoc reasons.  It may follow a predefined configuration or be
parameterized to allow the build configuration to vary with the build.
The usual purpose of this kind of build is to handle unusual
circumstances (eg the nightly scheduled build failed - tgb.  not really
"unusual" I suppose :) 0

3. Triggered (Continuous) Build
This build is unscheduled and occurs, typically, as the result of an
event being raised.  A typical event may be caused be changes to the
code stored in the SCM.  It will typically be configured to build the
latest of a particular set of code. 

4. Patch Build
This build may be scheduled or unscheduled and is generally a subset of
a larger build.  The main difference seems to be how it is specified (ie
the query used to get the appropriate source code) and the likleyhood
that it will be associated with a difference report.

5. Checkin of Derived Objects
Really a variation rather than a scenario.  Some build need to checking
the objects that they produce for various reasons

It seems from this that builds differ in three main ways

1. What triggers them: scheduled, triggered, on demand
2. How they are specified.  What "query" is used to define the source to
get.
3. What they do with the result. Check it in, prepare difference report
etc.

>From 1 it seems that we will need an SCM to raise an ALF event when
things stored in the SCM are changed.  It seems to me that this is
related to the object we have defined and we could define ALF events for
changes to a subset of those objects.  We need to explore what this
means.
Looking at the list I might guess that  Element (NewVersion), Change-Set
(creation, update), Branch/Stream (creation, update), Configuration
(creation, update), Baseline (creation, update?), Component (creation,
update) as possible events that would trigger a build.  This seems
fairly straight forward with the right intensity of hallucination.

The "query" aspect seems to imply that we may need to define an ALF SCM
"query language" that could be used for Checkout/Lock, Get, Report etc.
and carry over to CheckIn, Lable etc.  This is probably not a shock but
may be a bit more onorous than the first blush "let's have a vocabulary"
statement.  A structured query will probabably be a better approach to
use with Web services than a object system that represents the query.

"101 things I might do with this build" also seems fairly straight
forward to define.  Things I want to do seem to be limited to the
complete set of non-admin SCM functions :) - Get, Check out, Check in,
New Check in, Lable, Report etc.  

>From this I conclude that perhaps our to date current approach address
item 3 and we should continue that but we also need to examine the
"query" and "event" definitions to come close to a full picture.  If
this makes sense then someone(s) with some SCM domain knowledge should
probably have a go at these sooner rather than later.

Thoughts, Volunteers?

Thanks,
Tim Buss
Serena
 

-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eric Minick
Sent: Tuesday, May 16, 2006 3:16 PM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] RE: ALF Source Code Mangement Vocabulary Meeting
meetingminutes

SCM Vocab Team and all,

I've put together a quick overview of the SCM integration use cases from
the perspective of build management tools. Comments and suggestions from
those who are familar with these tools would be most welcome.

It's currently up on the wiki here: 
http://wiki.eclipse.org/index.php/ALF/Build_Server_Use_Case .

As we discussed, this is a fairly coarse grained set of use cases. On
further reflection though, I'm not sure that's the right direction. As
we move have added more customizable workflow oriented behavior in our
commercial app, we found it helpful to expose more low level and scm
dependent concepts directly to the user - particularly the advanced
user. In the open source tool, the coarse grained approach does simplify
development.

In a tool like ALF that is primarily geared towards users scripting
interactions in service flows, finer grained use cases might be more
appropriate, if only in the context of the more coarse.

Cheers,

Eric Minick
Urbancode, Inc.
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.



Back to the top