Continuous Integration v1.0
Continuous Integration v1.0
What this document is for: This guide is a learning tool and also a Written By:
detailed manual to reference for executives, managers and developers James Kaplewicz
on ‘Why and How to build a Continuous Integration Environment for Yousuf Baqir
Joseph Normandeau
the .NET platform’. It covers everything from the basics of Alex Begun
Continuous Integration to significant business advantages, as well as Eladio Martin
Andy Blum
overview diagrams to detailed setup. Documentation included covers Talha Anwer
requirements, processes, procedures, references and example code
involved in setting up an environment.
After building a set of requirements, this guide should be used as a framework to start
building a Continuous Integration environment tailored to a specific project(s).
This section is simply a brief and high level explanation of Continuous Integration.
Please refer to Section 8.0 References and Suggested Readings for more information.
The objective involves using a full version of a given projects code base whenever
any part of it changes, automatically run a build file (or manually), run automated
tests, report on the results for quick problem resolution, and quickly make all changes
available to teams involved.
2.1 Understanding
That Continuous Integration itself is a software development Best Practice – central
source file location, fully automated build, test and partly-automated distribution
process that allows teams to build and test their software many times a day.
2.2 Buy In
This process starts with buy in for CI with Executives, which leads to Development
Manager’s understanding; the end result being CI execution from Developers.
2.4 Back Up
Environment and Source File back-up and recovery procedures are properly followed.
Ref: http://www.theserverside.net/articles/showarticle.tss?id=ContinuousIntegration
The SOS Collab Servers directory does not contain any project data. All information
is stored in the SQL database, located in the SQL installation folder.
SOS servers need to have VSS database on same machine or same LAN as the SOS
Collab Server and VSS 6.0 APIs (installed with VSS 6.0 Client) on the same machine.
Ref: http://www.martinfowler.com/articles/continuousIntegration.html
Ref: http://www.15seconds.com/issue/040810.htm
With the Isolated model, development (edit, debug and run) is in complete isolation
on the developer’s workstation using a local Web server (http://localhost). Access to
the master source files is controlled via a Microsoft Visual SourceSafe (VSS)
database located on a network file share.
Ref: http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/tdlg_ch2.asp
3.8 NAntContrib
NAntContrib is the Project application for tasks and tools for NAnt. It provides extra
tasks and tools that are not present in NAnt.
3.9 Draco.NET
Draco.NET is a Windows Service Application designed to facilitate Continuous
Integration. Draco.NET monitors the source code repository, automatically rebuilds a
project when changes are detected and then emails the build result along with a list of
changes since the last build.
Draco.NET version 1.5 supports builds using NAnt build tool or via Visual Studio
.NET 2002/2003 solution files.
3.10 NDoc
NDoc generates class library documentation from .NET assemblies and the XML doc
files generated by the C# compiler (or with an add-on tool for VB.NET). It is used by
NAnt build tool to automatically generate library documentation.
3.11 NUnit
A Unit-testing framework for all .NET languages. NUnit is built within NAnt and
exposed as a NAnt task.
3.12 NUnitForms
NUnitForms is a tool extended from NUnit for automatically testing Windows Forms
applications written on .NET.
3.13 FxCop
FxCop is a code analysis tool that checks .NET managed code assemblies for
conformance to the Microsoft .NET Framework Design Guidelines. It uses reflection,
MSIL parsing, and calls graph analysis to inspect assemblies for more than 200
defects in the following areas: Library design, Localization, Naming conventions,
Performance, and Security.
FxCop includes both GUI and command line versions of the tool, as well as a SDK to
create custom rules.
Ref:
http://confluence.public.thoughtworks.org/display/CCNET/What+is+CruiseControl.N
ET
This section discusses high level details of Continuous Integration and outlines
terminology for server components of the CI model. Included are the basic
components in the Microsoft CI model and modifications ESP made. NOTE: The
attached environments are only “logical” and not necessarily “physical”.
Applications will run the same on a single server as they will run in a complex
network architecture.
http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_rm.asp
The following diagram outlines what the Microsoft article discusses as “In Scope” for
their “Team Development Environment” setup.
The image below shows the overview of ESP’s Continuous Integration Environment.
• The grey area identifies what is to be covered “In Scope” in the rest of the
documentation.
• The red text identifies differences between ESP’s CI model and the
Microsoft Team Development Environment model.
This architecture supports builds for Test, QA, and Production (End User) to be
pushed out automatically after testing is approved. All distribution at this point is
handled by the Build Manager(s). For more information about the Release Process
(Build Promotion) please refer to Section 6.0 Build Promotion Process.
Prior to configuring these tools this guide will step through creating sample .NET
applications to help demonstrate how these tools work and interact with each other.
The guide uses two sample .NET applications, one Windows Application and one
web (ASP.NET) application. The reason for using these two types of applications is to
demonstrate the difference between the way the tools are configured for web and non-
Web Applications.
Once these applications are created and added to source control (VSS) the C.I tools
will be configured and scripts created for some tools. Each script that is created is
discussed in detail.
Section 6.0 will discuss high level build promotion to different parts of the team
environment. Accomplishing this in the real world requires a tight build promotion
process and potentially an auto update (patching) feature for the Windows
Application using TrueUpdate.
Visual Studio.NET is not a necessity for server machine, but it is installed since the
guide uses Visual Studio.NET to create sample .NET applications.
These sample .NET applications can be created on some other machine with Visual
Studio.NET installed and then copied on to the server. Installation of .NET
Framework 1.1 is essential.
Other source control environments could be used as well, such as Subversion or CVS.
However, make sure the selected software is compatible with other CI Tools used in
this guide. The following scripts used for each tool assume the use of VSS.
The diagram below displays an installation architectural overview for general path
info.
NAntContrib provides extra tasks and tools that are not present in NAnt.
At the time of writing this document the latest version is 0.85 - nightly build. Version 0.84 has a
bug that does not allow compilation of Web Applications. Make sure to download Version 0.85.
NAnt is driven by an XML file that contains instructions about which projects to build
and the tasks to be executed. The task (a tag in the NAnt build script) is where NAnt
runs code and calls executables. Tasks can have multiple attributes or arguments.
NAnt expects these XML build file to be named filename.build.
The basic function of NAnt is to build or compile .NET source code. The path to the
.NET Solution file (.sln) is specified in one of the tasks of the NAnt script along with
the path to the output directory where NAnt stores the result of compilation.
Along with compiling the source code NAnt also performs many other tasks as well,
for instance to fetch source code from VSS and perform compilation on that source
code. This task is in the build scripts along with several other tasks.
NDoc can be directly used by NAnt script to generate class library documentation
through a task called <ndoc>.
To make class library documentation NDoc requires XML documentation files generated by Visual
Studio.NET when the application is compiled. This is for C# only (the C# Project needs to be
configured to generate XML documentation file in VS.NET). The reference of XML documentation
file is present in the .csproj file, which is required by <solution> task to generate this XML on each
compilation.
It is preferable to get familiar with NDoc before using NAnt’s <ndoc> task to create the
documentation. To get started with NDoc refer to http://ndoc.sourceforge.net/usersguide.html.
The <ndoc> task of NAnt creates documentation explained in Section ‘5.5 Creating
NAnt Build Scripts for the Sample Applications’.
5.2.4 FxCop
FxCop is a code analysis tool that checks .NET managed code assemblies for
conformance to the Microsoft .NET Framework Design Guidelines. It uses reflection,
MSIL parsing, and call-graph analysis to inspect assemblies for more than 200 defects
in the following areas: Library design, Localization, Naming conventions,
Performance, and Security.
Using FxCop through NAnt to perform code analysis is explained in section ‘5.5
Creating NAnt Build Scripts for the Sample Applications’.
To get started with NUnit refer to QuickStart.doc that comes along with the NUnit installation package.
Using NUnit through NAnt to perform unit testing is explained in Section ‘5.5
Creating NAnt Build scripts for the Sample Applications’.
When an engineer builds a car he first tests that every separate piece works together
before putting all the parts together to build a car. If pieces do not work separately,
then there is no chance of them working when they are together.
Unit testing is the process of testing each significant object and its method separately
to simplify overall integration testing later on and to minimize the number of bugs.
Any development process that implements rigorous unit testing standards leads to
higher quality code and less bugs during integration.
5.2.6 Draco.NET
NAnt is used to build the .NET Solutions manually. Draco.NET is used to automate
the build process.
Another option to automate the build process instead of Draco.NET is of using CruiseControl.NET
– http://cruisecontrol.sourceforge.net
5.2.8 TrueUpdate
TrueUpdate is a Dynamic Software Update System for integrating automated
updating capabilities into software products. TrueUpdate provides a framework for
determining required updates and retrieving and applying the necessary patch or
installation files via Internet, intranet or LAN.
TrueUpdate is not a freeware or open source like other tools. A 30-day trial version
can be downloaded from the link given below.
The TrueUpdate client contains a list of locations where the server file can be found.
At run time, the client executable downloads the server file from one of these
locations, and then uses the information in the server file to guide the rest of the
update process.
The server file contains version identifiers and actions. The version identifiers enable
the client to distinguish one version of software from another. They consist of criteria
such as the value of a specific registry key or INI file entry, the version from a file's
resource information, or the CRC value of a specific file. For instance, if the installer
writes the software's version number to the registry, a version identifier could be used
to compare the value at that registry key with a specific version number. If the values
matched, that version would be identified.
A similar folder structure is used to store the .NET Solutions as described under “Use
a Consistent Folder Structure for Solutions and Projects” section at
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/tdlg_ch3.asp
For this case create a directory ‘MyBuildSolutions’ in the root D drive and add
another directory ‘MySystem’ underneath this. Next create the two applications
mentioned underneath the MySystem directory.
The folder structure should look as such after the .NET Solutions have been created:
D:
--- MyBuildSolutions|
--- MySystem|
--- MyWinAppSolution|
--- MyWinApp|
--- MyWebAppSolution|
--- MyWebApp|
Make sure to add XML comments through out the code when writing the applications.
1. Open Visual Studio .NET, and on the File menu, point to New, and then click
Project.
2. Select the Visual C# project type and Windows Application as template.
3. Enter the project name, MyWinApp, in the Name field.
4. Set the Location field to D:\MyBuildSolutions\MySystem.
5. Click the More button.
6. Select the Create directory for solution check box. This causes the project file to
be created in a project sub folder beneath the solution folder.
7. Enter MyWinAppSolution into the New Solution Name field.
8. Click OK to complete the project and solution creation process.
9. Add new form to this project and add controls on the form to make it look like the
figure above.
10. Add code for each click button as shown below:
1. Right click the Solution’s name in solution explorer and select New Project from
Add sub menu.
2. Select the Visual C# project type and Class Library as template.
3. Enter the project name, MyMathProject, in the Name field.
4. Set the Location field to E:\MyTestProjects\MySystem\MyWinAppSolution.
5. Click OK to complete the project creation process.
6. Add new class to this project and name it MySimpleMath.cs
7. Add following static methods to this class:
public static double Add(double num1, double num2)
{
return num1+num2;
}
public static double Subtract(double num1, double num2)
{
return num1-num2;
}
public static double Multiply(double num1, double num2)
{
return num1*num2;
}
public static double Divide(double num1, double num2)
{
return num1/num2;
}
The next step is to create a NUnit test project to test the methods of MySimpleMath
class. The .dll created by this Class Library project will be used by the NAnt script to
perform unit testing.
1. Right click the Solution’s name in solution explorer and select New Project from
Add sub menu.
2. Select the Visual C# project type and Class Library as template.
3. Enter the project name, MyMathProjectTest, in the Name field.
4. Set the Location field to E:\MyTestProjects\MySystem\MyWinAppSolution.
5. Click OK to complete the project creation process.
6. Add new class to this project and name it MyTest.cs.
7. Add [TestFixture] attribute to this class.
8. Add reference of nunit.framework.dll to this project. This .dll is placed in
\nunit\bin
9. Add following test methods to MyTest class:
Notice that the [Test] attribute to each of the test methods. This is how NUnit knows
which method is a test method.
1. Open Visual Studio .NET, and on the File menu, point to New, and then click
Blank Solution.
2. Enter MyWebAppSolution as the solution name, and then set its location to
D:\MyBuildSolutions\MySystem.
3. Click OK. Visual Studio .NET creates the MyWebAppSolution folder beneath the
specified root folder location.
4. Use Windows Explorer to create a new subfolder called MyWebApp beneath the
D:\MyBuildSolutions\MySystem\MyWebAppSolution folder.
5. Use either Windows Explorer or Internet Services Manager to establish the
MyWebApp folder as an IIS virtual root.
Note: Visual Studio .NET requires that the virtual root name match the
project folder name.
6. Return to Visual Studio .NET, and on the File menu, point to Add Project, and
then click New Project.
7. Add an ASP.NET Web Application project.
New Solutions are added to VSS by being on server machine itself; although they can
be added to VSS remotely if Solutions are created elsewhere.
An important thing to remember about source control is always to use Visual Studio
.NET to create projects and solutions in VSS. Visual Studio .NET ensures that only
the appropriate files are placed under source control, and that files are updated with
the proper VSS-specific information whenever they are checked in, checked out, or
copied. Manipulating a solution with the VSS Explorer is a recipe for disaster. (Other
tools such as Source off Site, SOS, which links up with VSS can be used to
manipulate projects also.)
When placing a solution or project under source control, Visual Studio .NET adds the
following file types to VSS:
Visual Studio .NET creates many other types of files on developer workstations and
on the build server. These include solution user options, project user options, webinfo
files, and project build outputs. These files are not placed under source control.
The following files are not added to source control because they are developer
specific:
- Create NAnt build script to work on both the .NET Solutions created.
- Configure Draco.NET’s build script to run the NAnt scripts.
- Configure Draco.NET Web Viewer to display the result of each Solutions build.
Figure 2 below summarizes how these tools will collaborate once they are set into
action.
When NAnt compiles the source code, the build output is stored in the ‘Latest’ folder.
On successful build it will be copied to the folder of its version. Unsuccessful builds
are discussed later on.
D: --- MyBuildSolutions|
--- MySystem|
--- MyWinAppSolution|
--- MyWinApp|
--- bin|
--- Latest|
--- 1.0.0.1|
--- 1.0.0.2|
--- 1.0.0.3|
--- MyWebAppSolution|
--- MyWebApp|
The versioning system is not applied to the Web Application above. This is because
Web Applications have many different files such as Web.Config and .aspx files apart
from the executable. Since execution of a Web Application is dependent on the virtual
paths of these files, they have to be kept in one place.
(All the files required to run the Web Application can be copied to folder with a version number, the
same as for MyWinAppSolution. Directly executing the application will not be possible however, it
must be copied manually to the correct path before execution).
Note: Each source file can be labeled in VSS with current version number to keep track of relationship
between the build output and source files. But since Draco.NET service runs NAnt after it detects any
Next is creating two NAnt build scripts, one each the Windows Application and
another for the Web Application. Call them MyWinAppSolution.build and
MyWebAppSolution.build respectively.
Although these scripts can be placed anywhere, try keeping them in one place under
D:\MyBuildScripts\.
To get started with creating the build script check out the sample scripts that come
with the NAnt application.
To get details about the tag and their attributes of NAnt build script refer to:
http://nant.sourceforge.net/help and/or http://nantcontrib.sourceforge.net/help
default="build" states that the default <target> task is ‘build’ and that will be executed
if no task is specified on the command line when running this NAnt script. Everything
else added to the build script exists under this <project> tag.
Properties are used to set some of the values used later in the script. Add the
following to MyWinAppSolution.build.
Each name can be used as a handle to its value by referring it as ${property-name} for
example ${buildbase}.
The <target> task is an executable task that can do one or more things.
The build <target> task is the default task that uses <solution> task to compile the
application along with calling other <target> tasks to perform other operations.
<target name="build">
<call target="getLatestFromVss"/>
<call target="performVersioning"/>
<solution outputdir="${build.dir}\${sys.version}"
configuration="${build.config}"
solutionfile="${buildbase}\${solutionName}\${solutionName}.sln"
verbose="true">
</solution>
<call target="runNUnitTests" />
<call target="copyToLatest"/>
<call target="runNDoc"/>
<call target="runFxCop"/>
<call target="copyResultsToLatest"/>
</target>
Use <csc> task for C# Projects or <vbc> for VB.NET Project instead of <solution>
task to compile the build. The <solution> task is preferred because it automatically
determines project dependencies from inter-project references unlike <csc> task.
All the properties used in the <solution> task are defined in properties section except
for sys.version property. We will discuss about this property along with
performVersioning <target> task.
Now lets create each of the <target> called from within build <target>.
The getLatestFromVss <target> task gets the latest code from VSS by using
<vssget> task.
<!-- Get latest code version from VSS -->
<target name="getLatestFromVss">
<vssget user="Admin"
password=""
localpath="${basepath}"
recursive="true"
replace="true"
writable="true"
dbpath="D:\MyTestVSSDB\srcsafe.ini"
path="$/MyBuildSolutions/MySystem/${basename}/" />
</target>
The clean <target> task uses <delete> task to delete all the files in the delete ‘Latest’
folder.
After clean <target> task is executed the <solution> task compiles the source code
and stores the build files to ${build.dir}\${sys.version} where ${sys.version} is the
number set by <version> task. Remember that output of all the Projects within the
MyWinAppSolution goes to this same directory.
The runNUnitTests <target> task uses <nunit2> task to perform unit testing. Test
dll’s to run are specified under the <test> tag. The result output path and type is
specified in <formatter> tag.
<!-- run the nunit task on the test dlls -->
<target name="runNUnitTests" description="Runs unit tests on specified dlls">
<nunit2 failonerror="false" verbose="true">
<formatter outputdir="${build.dir}\${sys.version}\"
usefile="true"
type="XML"
extension=".xml"/>
<test>
<assemblies basedir="${build.dir}\${sys.version}\">
<includes name="MyMathProjectTest.dll"/>
</assemblies>
</test>
</nunit2>
</target>
The runNDoc <target> task uses <ndoc> task to create MSDN type API
documentation for the specified application (exe or dll) and its XML documentation.
The facility to create this documentation is directly built into NAnt and it is not
required to install NDoc on to the system.
<!-- Creates msdn type API documentation for the application -->
<target name="runNDoc" description="Will create documentation for Buidling Solution">
<ndoc>
<assemblies basedir="${build.dir}\${sys.version}">
<includes name="MyWinApp.exe" />
</assemblies>
<summaries basedir="${build.dir}\${sys.version}">
<includes name="MyWinApp.xml" />
</summaries>
<documenters>
<documenter name="MSDN">
<property name="OutputDirectory" value="${build.dir}\${sys.version}\doc" />
<property name="HtmlHelpName" value="MyWinAppHelp" />
<property name="HtmlHelpCompilerFilename" value="hhc.exe" />
<property name="IncludeFavorites" value="False" />
<property name="Title" value="An NDoc Documented Class Library" />
<property name="SplitTOCs" value="False" />
<property name="DefaulTOC" value="" />
<property name="ShowVisualBasic" value="True" />
<property name="ShowMissingSummaries" value="True" />
<property name="ShowMissingRemarks" value="True" />
<property name="ShowMissingParams" value="True" />
<property name="ShowMissingReturns" value="True" />
<property name="ShowMissingValues" value="True" />
<property name="DocumentInternals" value="False" />
<property name="DocumentProtected" value="True" />
<property name="DocumentPrivates" value="False" />
<property name="DocumentEmptyNamespaces" value="False" />
<property name="IncludeAssemblyVersion" value="False" />
<property name="CopyrightText" value="" />
<property name="CopyrightHref" value="" />
<property name="OutputTarget" value="HtmlHelp" />
<property name="CleanIntermediates" value="True" />
The FxCopCmd command takes in .FxCop project file as an argument which it uses
to validate against the default FxCop standards. Create an .FxCop file for
MyWinAppSolution by following these steps:
i Open FxCop
ii Click Project, Add Targets (Ctrl+Shift+A)
iii Browse to D:\MyBuildSolutions\MySystem\MyWinAppSolution\MyWinApp\bin\
MyWinApp.exe
iv Click file, save, and save as D:\MyBuildScripts\MyWinAppSolution.FxCop
<!-- Runs the command line ver of FxCop passing in the .fxcop file of this Solution. -->
<target name="runFxCop">
<exec basedir="${fxcop.location}"
program="FxCopCmd.exe"
commandline="/p:D:\MyBuildScripts\MyWinAppSolution.FxCop
/o:${build.dir}\${sys.version}\MyWinApp-FxCop-Results.xml"
failonerror="false" />
</target>
This task outputs result of code analysis against MyWinApp application as an XML
file called MyWinApp-FxCop-Results.xml created in the same directory as the build
files (current version directory).
The copyResultsToLatest <target> task copies the result files from the ‘sys.version’
folder to the latest folder. The result files can be any file ending in ‘-results.xml’. In
this case these are result files from FxCop (MyWinApp-FxCop-Results.xml) and unit
testing by NUnit, (MyMathProjectTest.dll-results.xml).
<!-- Copies the result files from the sys.version folder to the latest folder -->
<target name="copyResultsToLatest">
<copy todir="${build.dir}\Latest\">
<fileset basedir="${build.dir}\${sys.version}\">
<includes name="*-Results.xml" />
</fileset>
</copy>
</target>
The script below just shows how <solution> task is different in Web Application from
that of non-Web Application NAnt script. Other tasks for this script will be created
same as that for MyWinAppSolution.build except for changing the paths specific to
this application.
<target name="build">
<call target="getLatestFromVss"/>
<solution outputdir="${build.dir}"
configuration="${build.config}"
solutionfile="${buildbase}\${solutionName}\${solutionName}.sln"
verbose="true">
<webmap>
<map url="${MyWebApp.Host}" path="${MyWebApp.Path}" />
</webmap>
</solution>
<call target="runNDoc"/>
<call target="runFxCop"/>
</target>
As mentioned above versioning system is not applied to the Web Application. This is
because a Web Application has many different files such as Web.Config and .aspx
files apart from its executable file. And since execution of Web Application is
dependent on the virtual paths of these files they will have to be kept in one place.
<nant>
<buildfile>D:\MyBuildScripts\MyWinAppSolution.build</buildfile>
</nant>
<vss>
<project>$/MyBuildSolutions/MySystem/MyWinAppSolution/ </project>
<username>Admin</username>
<password></password>
<ssdir>D:\MyTestVSSDB</ssdir>
</vss>
</build>
<build>
<name>MyWebAppSolution</name>
…
…
…
</build>
</builds>
- The key elements in the configuration file are the <build> elements, which allow
Draco.NET to poll multiple Visual SourceSafe databases using different settings
including the <pollperiod>.
- The <pollperiod> is assigned a global position outside the <builds> node, but it
can also be set inside each <build> element.
- The <build> elements have a <nant> node that specifies the NAnt build file to use.
- On each build two types of notification are sent out by Draco.NET: one as email
to all the recipients in the <email> element and secondly as an XML file that is
saved to D:\MyBuildSolutions specified under <file>.
Note: Every time the Draco.NET build file is modified the Draco.NET service needs
to be restarted from the Control Panel\Administrative Tools\Services applet.
Draco.NET Web Viewer should now be accessible through the URL http://[server-
name]/DracoWebViewer and see MyWinAppSolution and MyWebAppSolution menu
on the left hand of the page.
The Server File Editor is used to edit the server-side update information file. This is
where the version identifiers are defined used to identify which version of the
software installed on a user's system. It's also where actions are specified to perform
when a particular version of software is detected on the user's system.
This setup is not in detail because it can be a very complex setup, please reference the
pdf below for more informatoin. To create the Client Configuration Utility and the
Server File Editor for the Windows Application developed earlier refer to one of the
following URLs:
http://www.indigorose.com/webhelp/tu10/index.htm Or
http://www.indigorose.com/files/tu10/tu10_userguide.pdf
Every development team may have a slightly different process for promoting a build
from Test through to Production, nevertheless, it is very important to have one! A
Build Promotion Process (equivalent to the Release Process shown in Figure 2 and
Figure 3), is simply a specific set of rules for how a version of a build of a project gets
moved from one location to another for a different set of clients to access.
As stated in Section 3.5, promoting a build means copying it to the target server. The
build must not be rebuilt but rather moved. Therefore there is the need to identify and
archive builds in a build promotion process (Section 6.0 Build Promotion Process) as
builds are created.
A level of complexity is added with the requirement for a Build Manager to not only
promote (move) the build, but tentatively manage the movement of multiple projects,
for multiple clients, Test, QA, and Production, for TrueUpdate delivery (See Section
5.7 Implementing TrueUpdate).
Section 5.5.2 demonstrates how ESP determines version build numbers at the time of
writing this document. The following diagram is an overview for implementing
TrueUpdate to work with three separate application clients for Test, QA, and
Production:
Future concepts are theorized and researched, but has not yet used in practiced.
In database systems the concept of a transaction guarantees that a set of actions are
atomic, which means that they either all succeed or they all fail. In CI, this concept of
transactions is not yet realized for multi developer environments.
http://www.xp123.com/xplor/xp0203a/index.shtml
In the mean time it is possible to “fake out” transactional builds through simply
having Build Promotion process defined tightly to move the most recent successful
versioned build directory to the Test area for Auto Updating.
- Continuous Integration
http://www.martinfowler.com/articles/continuousIntegration.html
8.1.2 NANT
- http://nant.sourceforge.net
- http://nant.sourceforge.net/help/index.html
8.1.3 NAntContrib
- http://nantcontrib.sourceforge.net/help/tasks/index.html
- http://nantcontrib.sourceforge.net
8.1.4 Draco.NET
- http://sourceforge.net/projects/draconet
- http://draconet.sourceforge.net/wiki
- http://blogs.biasecurities.com/jim/archive/2004/02/16/337.aspx
- http://ndoc.sourceforge.net
8.1.7 NUnit
- http://nunit.sourceforge.net
- http://nunit.org
8.1.8 NUnitForms
- http://sourceforge.net/projects/nunitforms
8.1.9 FxCop
- http://www.gotdotnet.com/team/fxcop
8.1.10 CruiseControl.NET
- http://cruisecontrol.sourceforge.net
- http://confluence.public.thoughtworks.org/dashboard.action
- TrueUpdate
http://www.indigorose.com/tu/index.php
8.3 Books
8.3.1 Open Source .NET Development: Programming with
NAnt, NUnit, NDoc, and More
http://www.amazon.com/exec/obidos/tg/detail/-/0321228103/002-1292323-
7959221?v=glance
Ref: http://www.mail-archive.com/nant-
[email protected]/msg04645.html
Used the latest version of NAnt (0.85 – nightly build) for
compiling Web Application and web service. Both work fine now.