Greetings, all:
In addition to being able to specify a persistent working copy for SCC
checkouts, I'd also like to see an absolute polling option (in addition
to the existing relative behaviour). I mentioned in a previous message
that we prefer incremental builds for their speed. Well, that's not to
say we don't ever want to do pristine builds. We do. Sort of. =)
Our idealised process would go something like this:
Our Draco config file would have two modules: one for incremental
builds, and one for complete builds (both of them poll the same
repository):
<builds>
<build>
<name>Incremental</name>
<pollperiod>60</pollperiod>
<quietperiod>30</quietperiod>
<nant>
<buildfile>master.build</buildfile>
<targets>windows release debug tests build test</targets>
</nant>
<svn>
<url>http://svn.server/repository/trunk</url>
<user>draco</user>
<password>draco</password>
<workingcopy persist="true">c:\draco.svn</workingcopy>
</svn>
</build>
<build>
<name>Deploy</name>
<polltime>4:00</polltime>
<quietperiod>30</quietperiod>
<nant>
<buildfile>master.build</buildfile>
<targets>windows release tests build test doc deploy</targets>
<properties>
<property name="tag.on.success" value="true" />
</properties>
</nant>
<svn>
<url>http://svn.server/repository/trunk</url>
<user>draco</user>
<password>draco</password>
</svn>
</build>
</builds>
Now, perhaps a bit of explanation is in order. We have two types of
targets in our build scripts: those that only set properties, and those
that actually do things (think nouns vs. verbs). Examples used above of
the former are "windows," "release," "debug," and "tests." Examples of
the latter are "build," "test," "doc," and "deploy." Therefore, the
incremental build performs two actions: it builds (it builds the
windows release and windows debug configurations, and also builds the
windows test assemblies) and tests (it runs NUnit against the windows
tests, which implicitly reference the debug configurations).
So the "Incremental" module polls SVN every minute for changes. If it
finds any, it does a checkout (at which SVN, being a "proper" SCC
system, and a rather advanced one at that, only sends the diffs over the
wire), and forks off a build. The build scripts know that when they
build, they only do so incrementally. Furthermore, they know that when
they test, they also only do so incrementally. Since the "Incremental"
module checks out to a persistent working copy, the build scripts will
be able to determine what needs to be re-built and/or re-tested.
Additionally, we point the build server's path to this "tools" folder of
this working copy, so that it always points at the latest binaries of
the build tools, along with any custom tasks or other customisations
that have been committed.
We'd also like the build server to handle our nightly release. This
will occur at e.g. 4am, when, by the Mercy of God, no developers will be
committing changes and triggering incremental builds. This build is
different than the incremental build. For one, it is totally pristine.
We have quite a bit of time, so we'll check out a fresh copy, and build
and test from scratch. We don't care what directory our working copy
ends up in, because a) it's _supposed_ to be a pristine build, and b)
our path is already pointing to the latest build tools in the trunk,
which the incremental build will have ensured is up-to-date for us. The
second distinguishing feature of this build is that we set a property
which will trigger the build scripts to tag this build upon success. We
also generate documentation and deploy the application (it's a web-app,
for all intents and purposes, so our clients will get instant
gratification if they happen to be using it at 4 am). We've decided
against tagging every single draco build (which we're currently doing),
but we do want to tag the revisions that actually make it to live
deployment.
Now, I have seen it suggested that a way to accommodate our "nightly
release" scenario is to set the polling interval to 0 and schedule the
draco commandline client to force the build. Well, what if it's a
holiday, and there've been no new commits in the last 24 hours? Forcing
the build would result in the generation of two tags that contained
identical source, and a needless redeployment of the application. We
therefore do want to preserve the "polling" nature of the existing
relative poll: only fork a build if there have been changes since the
last time I checked. We just want it to happen at a specific time.
"Well, okay. Maybe we could just modify the commandline client not to
really force it." Well, there may be times when we want to force a
redeploy (at some time other than 4 am). We still want the build server
to act as the gatekeeper--in order to redeploy, I think we want to force
a re-test. That is, no code sees the production server until the build
server has built it and tested it, and all tests have passed.
Therefore, the commandline client still has its purpose. We'd like to
use it to kick off a manual deployment process.
I hope that illustrates the potential use for scheduled/absolute
polling, and how it would nicely complement the persistent working copy
idea. The developers don't have to worry about testing before
deploying. Heck, unless it's some urgent bug fix that they want
deployed ASAP, they don't have to worry about deploying at all! For
rapid build/test turnaround, do so incrementally. For automatic, yet
cautious, releases, deploy through the build server.
I think I've seen this kicked around over on the developer list; I
apologise if this would have been more appropriate there. My rationale
for posting it here is, well, I'm a user, not a developer. =)
Regards,
Liam Davis-Mead
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Draconet-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/draconet-users
