[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [alf-dev] Build SCM Use Cases
|
Title: Re: [alf-dev] Build SCM Use
Cases
Thanks Doug for the Build Vocabulary input. Does this mean
that IBM is planning to
participate in ALF? As you know Catalyst is coordinating
the build vocabulary discussions. We are in the process of
organizing other Build vendors. At present there are 3 companies
participating. If IBM is supporting ALF, and Rational is
interested in participating, please let us know so we can make sure to
contact you for the discussion meetings. There will be a notice
on ALF-DEV.
Some general comments:
For items 1,2 and 3 (Scheduled, Demand, and Triggered) are
methods of how to execute a Service Flow. It may be
useful to have a scheduler added to ALF. This should be
brought up to the ALF Architecture team. For
example, you would schedule a Service Flow that may include such
activities as Build/Test/Deploy. A scheduled build, an on
demand build or a triggered build is not a use case, but a way a
service flow may be initiated.
I agree that #4, Patch Build, is a Type of Build. The Type
of Build will be defined as
part of the Build Vocabulary. The Build Vocabulary
may only have one verb in it "Build"
with all of the Types of Builds being attributes of the Build.
This is something that needs
to be discussed. Also, where the Build is to occur
would be an attribute as well.
There would many Service Flows defined for how the builds are to
be orchestrated inconjunction
with the other activities, ie. SCM Vocabularies. These
Service Flows allow the customer
to tailor the Build to their processes which is what makes
ALF such a strong framework. Some examples of the Build use
cases that would establish the vocabulary would be:
Build a Change Request -
The problem management tool would provide the change request info
which would execute a check out of the corresponding code from the SCM
tool. The SCM tool would request an incremental build of only
the changes or request a full build. The build results upon success
would be checked back into SCM tool via an ALF notification. On
failure, the problem management tool and development team would be
notified.
Build a Requirement
The requirement tool would provide the enhancement request info
which would execute a check out of the corresponding code from the SCM
tool. The SCM tool would request an incremental build of only
the changes or request a full build. The build results upon success
would be checked back into SCM tool via an ALF notification. On
failure, the requirements tool and development team would be
notified.
Change Request Impact Analysis -
The change request tool would provide the change request info
which would execute a check out of the corresponding code from the SCM
tool. The SCM tool would request an impact analysis report and
return he information to the Change Request tool.
Audit Build for Non-approved components
The SCM tool would request a build that displays all components
not managed within the SCM repository. The build would execute
with dependency gathering, listing all components that were used in
the build, but not managed within the SCM repository and return he
report to the SCM tool.
Build with IT Compliance Audit
The SCM tool would request a build that created a audit trail
showing all components used in the compile/link process and create a
footprint validating matching source to executables. The
footprint would be embedded in the executables and the executables
would be checked back into the SCM tool.
As you can see each Build Use Case will call a build passing it
attributes that define the type of build, i.e, production incremental
build, production full build, system incremental debug build, subset
build, etc. The build engine itself will return
dependency information, impact analysis, build results, built targets,
build time metrics, footprints and build audit reports. The work
products of the build such as impact analysis and
dependency relationships will be shared and used by the other ALM
tools to enhance the overall ALM workflow.
These are just a few of the Use cases that have been discussed.
These use cases will define the Build Vocabulary. So our goal is
to define the Use Cases, which in turn will create the
vocabulary.
Thanks for your contribution. We look forward to having IBM
participate in ALF.
Steve
At 4:15 PM -0500 5/18/06, Doug Fierro wrote:
>Date: Wed, 17 May 2006 16:05:58
-0700
>From: "Tim Buss" <TBuss@xxxxxxxxxx>
>Subject: [alf-dev] Build SCM Use Cases
>To: "ALF Developer Mailing List"
<alf-dev@xxxxxxxxxxx>
>Message-ID:
>
<55646D9DC2748E4CACDD632FF2E53982019FEAED@xxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="us-ascii"
>
>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
As a detail, scheduled builds can be either recurring, or
one-time.
>
>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
I would not limit describing on-demand builds to just
"unusual" circumstances. Reaching a certain milestone
may be reason to do initiate a build for example. And as you
point out, an automated build failing is not unusual.
>
>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.
There are two underlying methods to achieve this from a
functional perspective- polling method and triggers/raised events.
They each have their pros and cons, but generally I think the
trigger method is more efficient and has more benefits.
Typically polling is done by the build tool, whereas a trigger
would be initiated by the SCM tool.
>
>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.
So in 1-3 are outlined ways to initiate a build at a functional
level, and with #4 now this is more of a category or type of build.
I agree that typically a patch build would not be initiated via
a continuous build event. However there are other categories of
builds you may want to consider if you are introducing such a
notion:
unit builds
integration builds
incremental builds
system builds
clean builds
test builds
release builds
production builds
milestone builds
nightly builds
special builds
debug builds
etc.......
I don't know how deep you want to go into this, but you can
see introducing categories of builds opens up the discussion quite a
bit :-)
At the end of the day all these types of builds are
initiated in 1 of 3 ways outlined earlier, but they all have different
use cases, some varying more than others.
>
>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
There are some build categories where this makes sense, if
you want to preserve the derived objects created from the
build.
Other categories of builds, like an incremental build, you
do not want to necessarily check in all the derived objects if they
existed prior to the build. A simple timestamp comparison of the
derived object relative to the beginning build time may resolve this
however in the build logic itself. Debug builds are another
example- these derived objects may have extra compiled data in the
executables that could behave differently, such as writing to
temporary files, produce extra system or warning messages, expose
internal data within the application, etc. just for the purpose of a
particular troubleshooting exercise. The common use case is you
provide a user or customer a debugged version of an application your
software team develops to help uncover an issue. It may be
applied as part of a packaged install, but it could be just a
standalone artifact like a DLL or EXE that the user copies to the
designated location manually. These types of debug-built objects
are transitory in nature, and you may not want to save them,
especially since they are typically much larger than their
corresponding non-debug versions, and may have no use beyond that
troubleshooting exercise. A debug build would be almost
exclusively initiated on-demand.
>
>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.
This can be described as the scope of the build possibly as well.
This also encourages best practices to have all needed artifacts
for a build under source control. It may be just me on the
use of the term "query" , but that is not a standard SCM way
to think about retrieving files to populate a workspace, even if the
tool in fact uses an underlying RDBMS to store them internally :-)
But I get the idea of what you are saying, just trying to think
if there is a better way to describe it.
>3. What they do with the result. Check it in, prepare difference
report
>etc.
I would say builds also differ by category, which
corresponds at a higher level to the underlying reason for the build
and how will it be used or consumed. This may even be aligned
with the business objectives of the organization in addition to
internal consumers of the build output. A very common use case
for internal build output consumption is to initiate a suite of test
cases, smoke tests, upon a successful build. Touching on
the testing domain is out of the scope of discussing use cases for how
SCM and build interact, but there is no doubt that build and test are
tightly coupled within the application software lifecycle because test
consumes the build results.
I would add that builds also need to provide a status result that
in the ALF world would be an event raised - typically success or
failure. Success could be broken down further into two
sub-categories: warnings (non-fatal errors, conditions, etc.) or no
warnings. However I don't think the SCM system would need to
monitor or act on such build status result - the SCM system is passive
when dealing with the build system except for the case of continuous
builds where it directs the build system to do something (is my
assumption there correct?)
I want to note here that an important task builds must
perform also includes environment setup among other things, but that
happens outside the scope of the SCM repository. So making sure
a particular library version is installed at the right location could
be one such example. This library can be under version control,
which is extracted first into the workspace as part of the build
process, then from there the build logic takes care of any necessary
setup. This also implies that the build logic must also keep
track of the results, should that involve the SCM system again later
in the process such as checking in files mentioned in (3)
above.
>
>>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.
This is the right way to think about it- you then need to
map a define object representing a set of files in the SCM system to a
corresponding build to initiate.
>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.
Basically anything that changes the source namespace, or
the contents of the namespace, should trigger a build. Some of
these metadata items associated with SCM may or may not result in a
build being needed. And actually it gets a bit more complicated
than that depending on how you define "source". For
example, it is a best practice to version documentation with source
code on a project and logically group versions of them together
somehow with a label or baseline, but you don't want to initiate an
unnecessary build when your doc set changes. So something to
think about is a way to exclude or ignore certain files from
triggering a build.
>
>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.
Is defining a query language more complex than just
defining a small set of common SCM operations that need to be
supported?
I guess until we flesh out the other domain interactions with SCM
such as tracking, test, deploy, etc. we don't really know the full set
of use cases of an outside service requesting something from the SCM
system, as well as what types of events the SCM system should be
raised for another application/service to act on that event. The
good news is I think most of the SCM tools can support common basic
file / version type of operations. Introducing task-based SCM
into the picture is where are the lowest common denominator starts to
go away.
>
>"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.
To examine all the possible event definitions
relating to SCM, you need to analyze all the other constituents,
stakeholders, domains, etc. in the envisioned ALF ecosystem that would
need to interact with SCM before you have your full picture.
Between build and SCM specifically, identifying the use
case categories of builds might be helpful to get the big picture, but
I think the underlying SCM actions they boil down to for initiating a
service request, or having the SCM system raise an event, will be very
common, again not factoring in task-based SCM scenarios. You can
only initiate a build a certain number of ways, and the set of files
the build needs to act upon or depends upon are in the SCM system that
you need to extract somehow. When you are done building, you may
or may not need to manipulate the resulting derived objects.
>
>Thoughts, Volunteers?
>
>Thanks,
>Tim Buss
>Serena
Doug Fierro
Director of Product Management
Buildforge / IBM Rational Software
dfierro@xxxxxxxxxx
512 225 0436
http://www.buildforge.com
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
--
Catalyst Systems Corporation
Ph: 800-359-8049 x114
505-424-6439
Fax: 505-424-6438