[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [alf-dev] The role of source control in ALF
|
It's certainly possible to do web service file transfers and for a
single file it makes sense. But if tools from ALF partners like
Urbancode and ViewTier are going to really take advantage of ALF and if
we ever wanted to bring CruiseControl on board, we need to be able to
tell ALF "get me all the source for this project" and get back hundreds
of megs of source, libraries, documentation, etc, etc. A web service
might be able to do this, but it's a less obvious fit. The Borland guys
do some of this in the StarTeam API, but I suspect some ALF
implementations would have to resort to using the SCM's command line
tool under the covers. To me that says that all the services have to be
able to access some place on some disk, but I'm not sure they need to
all access the same one. Couldn't data be pushed out to wherever a given
service wants it?
Let's pretend CruiseControl is ALF enabled. How would that work?
Presumably, instead of polling the SCM for changes like it does now, it
waits for check-in notification ALF. More specifically, code committed
on the SCM raises an event and ALF determines that a build should
happen. It tells CruiseControl to build project x. Lovely. Now Cruise
needs the source out of CVS. It seems to me, that it should be able to
ask a local ALF interface to deliver a module, using some branch, to
some local directory. Whether that happens via web-service or running
some commands could be an implementation choice.
Ah, but there's the rub. How is an ALF enabled metric tool going to get
to the code and build artifacts that Cruise is sitting on? Either the
the build information must go out to the tool or the tool must have
access to that same spot on the physical disk. The performance centered
approach would be to have the tool on the same box with access to the
same files, but either would work.
-- Eric
Richard Title wrote:
Again, why do you think it is a fundamental problem to return file-contents
in a SOA? It's just a stream of bytes.
By the way, another SCM-related standard worth looking at, in addition to
JSR 147, is WebDAV DeltaV (see http://www.webdav.org/deltav/ ). Again, it's
not SOAP, so it's not directly usable by ALF. But some of the ideas might be
useful. It's an extension of HTTP to support versioning. It does have a
"GET" and "PUT" operations to obtain/update file/version contents.
Richard Title
AccuRev
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark Phippard
Sent: Tuesday, March 07, 2006 9:51 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] The role of source control in ALF
Scott,
Thanks for replying. I will take a closer look at the requirements, I had
only scanned them in the past.
I didn't mean to imply that source control plays no role in ALF. For
example, I can see the source control system sending events to ALF, such
as when files are committed, so that ALF can perhaps initiate a service
flow of some kind.
What I was getting at is an issue that the POC demo actually raises. A
lot of the tools and areas that we are talking about for ALF operate on
source code. Would we ever envision a "GET" request delivering the
results via an SOA? I do not even know how that could be done.
WS-Attachments maybe? This seems impractical, so it seems like either all
of these services are going to need access to the same physical location,
or these tools are going to still need their own point to point interface
to the source control system in order to get the source code.
So perhaps my points were two-fold:
1) Source control-related vocabularly probably needs to focus more on
what types of events a source control system should raise. Since this
scenario obviously makes sense and can provide a lot of value.
2) When trying to explain ALF to someone, maybe it would make sense to
look for other areas to focus on other than source control?
Related question:
Would we envision a source control system being able to ask questiosn/seek
approval via ALF? For example someone wants to checkout or check-in some
source code. Could the source control system send a request to ALF to see
if it was OK? For example, maybe the related issue has not been approved
yet or something like that.
Mark
alf-dev-bounces@xxxxxxxxxxx wrote on 03/07/2006 09:38:42 AM:
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
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
____________________________________________________________________________
_
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email
Security Management Services powered by MessageLabs.
____________________________________________________________________________
_
____________________________________________________________________________
_
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs.
____________________________________________________________________________
_
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
