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

Doug,

Overall, I tend to agree. When you list the large number of 'types' of builds, I think you start hitting on a pretty fundemental problem. There are lots and lots of ways to do builds and lots and lots of things that can be done with them. The direction we are seeing people moving is actually away from specialized build profiles (CI vs Nightly vs Release) and towards just 'the build'. Or perhaps just distinguishing between CI builds and 'serious' builds.

So long as the build happens the same way all the time, it doesn't really matter if it was triggered from an SCM event or was a special event build. It really just matters what tests have been run against it, what features are working in it, and where it has been deployed or promoted t. That's usually the real difference between builds.

That said, the I think the handle of build types that were laid out give us a framework for figuring out what kind of SCM integrations build tools need. CI builds need speed (updating a workspace) whereas a scheduled or on demand build probably is more quality focused (takes care of the clean build requirement).

As for the SCM trigger vs the polling debate, I think the trigger approach is definately more attractive, although polling is more practical today. But I wonder how a polling system would really work under ALF. Would the build system have to raise a 'please poll the SCM' event every couple minutes? Or would a constantly running ALF process handle the polling?

As for what to do with the results, I think we may need to form the Build vocab committee to handle this properly. My instinct though is that the responsibility of the build tool will be to let ALF know where the the resulting artifacts are, perhaps segregated by type (automated test result as opposed to generated library or executable). If the rest of the ALF workflow wants to run more tests on the results, check them in to the SCM, publish them to an artifact repository, or burn them to CD, that's the workflow's problem. From an SCM vocab perspective, the only issue will really be checking in the created artifacts and frankly, many teams won't take advantage of that choosing instead to manage the artifacts from within the build tool or in a specialized artifact repository like Maven, Ivy or something proprietary.

I think the plan for the SCM Vocab team is to look at high level at many different interactions, but the decision was made to try to get a high level view of build to put the various low level SCM tasks in some perspective.

I'm going to muddy the waters a bit and respod to some of your poins from the previous email.

I agree that the first use case could use work. Frankly, they were all pretty quickly thrown together. I'm not sure if "Create Workspace" is adaquate though. SCMs vary a lot as to whether creating the workspace populates it or not. The use case is meant to encapsulate the idea of creating and populating a workspace. The second is intended to operate on workspace that has already been populated.

SCM events initiated by the build tool are a major concern of ours as well. If nothing else, I imagine that the build tools could raise events mid-build to handle these kinds of things. Post build promotion is an excellent suggestion overall. While not terribly relevent to the CVS and Subversion type SCMs, the PVCS Professionals, ClearCase and Accurev style SCMs will benifit and there's definately user demand on that front.

Removing a workspace is also a good suggestion. I think I overlooked it since many SCMs just need to delete a directory to remove the workspace, but for others there are definately SCM commands to be used.

Thanks,
Eric

PS. Congratulations on the new email address. It's good to have some build and release management company in ALF. Slava from Viewtier has touched base too. As your transition calms down and we get our big release dealt with perhaps we can begin discussing a build server vocab.


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