Usually the reason we (myself and my fellow developers) go through a
build server is because we can't guarantee the developers have the
latest versions of our software installed on their machines. The build
server always pulls from source control from the latest label in source
control, so it should be the most recent version of the code that is
built and moved to production.
We also run our tests on the build server to double-check to make sure
everything still works before we move to the next phase, such as moving
the code to production.
On another note, while initially working with CruiseControl.NET and
MSBuild may seem daunting, through some work on standardizing and making
common blocks, it can get much simpler to work with over time. What
this means is that while one or more build administrators might have to
learn the complex details of the MSBuild and CruiseControl.NET XML
languages, in the long run everyone else should benefit from the
resulting simpler language that the build administrators will develop.
MSBuild and CruiseControl.NET both support the concepts of variables,
and CruiseControl.NET supports include files for breaking up the
configurations into smaller reusable chunks. These concepts can be used
to produce standard build, test, and deploy structures for your
projects, and then all developers need to speak is the language of the
common standards.
Using ourselves as an example, we have gone through the process of
automating our build processes, including standardizing how the code is
built and tested, including:
1. Build in debug mode
2. Run tests against the debug version, including code coverage
analysis
3. Build in release mode
4. Move the code to the location where the software gets installed
from
When we went through this process, our MSBuild build scripts became
highly standardized by using variables, to the point where only 2
variables change between build scripts:
1. The name of the project
2. The name of the project that contains the tests
At that point, we were able to templatize the build file as part of a
custom project template, so that even these variables are managed
automatically when creating the project. As a result, we rarely have to
touch the MSBuild build script (only for adjusting what is considered
pass-fail for code coverage).
We were also able to use the CruiseControl.NET variables and include
files in ccnet.config, to standardize the build and deploy process as
well, so our CruiseControl.NET configuration became very simple as well.
For example, a config section for building one of our projects might
look like (just an example):
<cc:scope Project="ProjectName"
SourceControl="$(BaseSourceControlPath)SourceControlProjectFolder">
<cc:define name="DeployLocation">
<cc:DeployLocation_TestServer />
</cc:define>
<cc:BuildTestAndRelease />
</cc:scope>
DeployLocation_TestServer and BuildTestAndRelease are include files that
contain the standard instructions for building the project, running the
tests, rebuilding as a release version, and moving the code to the next
phase.
Also through the use of include files, we were able to separate the
individual builds each into their own files, so not everything was in
the ccnet.config - just the variable definitions and the include file
references so CruiseControl.NET knew where to read all of the files.
To make a long story short, while this seems daunting and overwhelming
at first, there is hope - it can be made much simpler and easier to work
with in the long run.
From: [email protected] [mailto:[email protected]]
On Behalf Of Katherine Moss
Sent: Thursday, August 18, 2011 1:31 PM
To: [email protected]
Subject: RE: [ccnet-user] Re: Chicken and egg build dependency
Oh. Well maybe I don't yet (probably quite likely), don't understand
the full CI concept. Why would you have extra build processes if the F5
key was already pressed from developers working via their local
desktops?
From: [email protected] [mailto:[email protected]]
On Behalf Of Michael Powell
Sent: Thursday, August 18, 2011 2:25 PM
To: [email protected]
Subject: Re: [ccnet-user] Re: Chicken and egg build dependency
In the current context, I believe we're talking about MSBuild as a
server-only thing, which CC.NET would kick off. It's nothing that
developers would necessarily need from their local desktops, per se. In
other words, we would still work through our solutions as per usual.
On Thu, Aug 18, 2011 at 11:59 AM, Katherine Moss
<[email protected]> wrote:
I think it comes with the framework. It's hard when development is
based on VS 2010 though, not to flip your finger on the F5 key and get
your solution built. I'm jus using that at this time in terms of
development.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Brad Stiles
Sent: Thursday, August 18, 2011 1:31 PM
To: [email protected]
Subject: Re: [ccnet-user] Re: Chicken and egg build dependency
While it's true that Visual Studio uses MSBuild behind the scenes,
MSBuild can be installed separately with the .NET Framework. It's been
long enough that I don't remember, but it's either included with the
framework, or at least some packages, or is available in a separate SDK
download.
On Thu, Aug 18, 2011 at 12:55 PM, Katherine Moss
<[email protected]> wrote:
> But remember how MSBuild is built into Visual Studio. And it's just
> XML like you all should be familiar with.
>
>
>
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Michael Powell
> Sent: Thursday, August 18, 2011 12:31 PM
> To: [email protected]
> Subject: Re: [ccnet-user] Re: Chicken and egg build dependency
>
>
>
> Sounds like we may be on an MSBuild track anyway. I'm trying to avoid
> much of that because that's just one more script we need to become
> knowledgable about, but like you said, if it's a matter of licensing
> what not, then plausibly we look into the targets and setup our
> MSBuild environment for the build.
>
> On Thu, Aug 18, 2011 at 7:36 AM, Brad Stiles
> <[email protected]>
> wrote:
>
>> 1. Having it be part of the Svn solution is sufficient for now.
>> Minimally, we let the thing travel with the tools part of the project
and let it be.
>
> If you're using a standard installation of Visual Studio for your
> developers, you shouldn't really need to do this type of thing.
> Installing Visual Studio components on a build server *may* require
> you to have a Visual Studio license for that server. This *may* be
> covered by an appropriate MSDN volume license, but you need to verify
> that with your compliance folks.
>
> Oftimes new Visual Studio project types are supported in MSBuild using
> new "targets" files and sometimes additional or modified assemblies.
> If you can discern (perhaps using an installation watcher program)
> what those changes are, you might be able to make just those
> modifications on your build server and eliminate the need to install
> either Visual Studio or any addins on the server itself.
>
>> 2. The setup.exe requires some user interaction anyway. It asks at
>> least one or two questions that require end-user input.
>
> Using the command line can often eliminate the user interaction
> entirely. Another option is to modify the MSI file itself to change
> the queried values to the ones you want. This requires tools you may
> or may not have.
>
>> 3. This adds a project type to the Visual Studio environment that is
>> required by one of the solution's projects. Definitely more than I
>> want to get into for any CI configuration concerns.
>
> If it's solely a matter of additional assemblies, that can usually be
> managed by source control, in your case, Subversions svn:externals
> capability. If it's a matter of targets in MSBuild build files, then
> you have a slightly different problem. Making those changes one time
> and forgetting about them is likely to be much easier.
>
>> All that said, good to know about the <msiexec/> block.
>
> To be clear, I was talking about using MSIEXEC.EXE, the program to
> which msi files are tied in Windows, not anything in NAnt or CC.NET.
>
> Brad
>
>
