Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev] The role of source control in ALF

Hi Mark:

I think you have to separate out a bit the use cases that are modeled in the
POC and the long term possibilities integrating SCM and other tools. Issue
tracking is probably the most obvious: SCM integrates with ITS tools to
version and manage change packages/change palettes/change sets (insert your
tool's nomenclature here) that address specific defects across multiple
release branches. But for many of the other tools in the ALM suite, we think
there are plenty of cases where objects need to be properly versioned and
managed at the infrastructure level, and see SCM as fundamental to the
success of ALF-enabled workbench. 

The POC though has really only modeled the most superficial SCM use cases,
which I think reflects more urgent short-term priorities for the project and
does not properly model the role of SCM and the SCM repository in the
overall process flow. Richard Title here at AccuRev has submitted some cases
to build out the story a bit (and attempted to map out some common
vocabulary among several leading SCM tools)--these are still pending review
from the requirements group--but I think these will be a start to better
representing the role of SCM in the suite.

I believe Kelly has posted these cases on the ALF requirements site...take a
look and see what you think. We'd welcome some additional feedback and agree
wholeheartedly that the SCM needs some further attention in the ALF POC.

Best, Scott




Scott McGrath | Senior Product Manager 
AccuRev, Inc. | www.accurev.com
781.325.0652w | 617.834.2339m 
 
 
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark Phippard
Sent: Tuesday, March 07, 2006 9:15 AM
To: ALF Developer Mailing List
Subject: [alf-dev] The role of source control in ALF

Watching the POC demo and writing my web service for Subversion made me 
really start to question the role of source control in ALF.  I am sure 
that there will be cases where having it supported will be useful, and 
having a service interface to a source control tool cannot hurt, but I 
wonder how well it is really going to work in the real world.  I think the 
whole concept of an SOA kind of falls apart if ALL information that needs 
to be exchanged cannot be done via the service interface.  In the case of 
source control tools, the information that needs to be exchanged is 
ultimately the source itself.  Do you eventually envision defining a 
vocabulary or whatever, where the source control service would actually 
deliver the artifacts via the web service?  That seems like it would be 
hard to do and probably be overly resource and network intensive.

If all you can do is send an instruction to a source control tool telling 
it to get source to some folder accessible via the web service that is 
going to be very limited in how you can deploy and build your solution and 
service flows.  Take the POC demo as an example.  You are doing a GET of 
the source code so that you can build it, test it and scan the source for 
security bugs.  This only works in the POC demo because all of the 
services have access to the same location.  How is ALF going to move 
beyond that in the real world?  Are users going to have to have all of 
their source-related services deployed on the same server?  It seems like 
in a real world deployment you are going to wind up just using the 
features that are built into OpenMake, or Ant or whatever build tool is 
used to let it go get the source from the source repository and then build 
it. 

Is there a trick up your sleeve that I am not aware of, or is this always 
going to be a real issue?  If it is, then I think we need to start 
defining alternate reasons why ALF is going to provide value.  The problem 
with the POC demo is that there are probably hundreds of tools already out 
there that do the same thing much easier.  The only parts of that demo 
that you could not do with a simple Ant script are the parts related to 
the issue tracker and even that could be done relatively easily if the 
issue tracker had Ant integration.

Thanks

Mark








Back to the top