Tag Archive for: CruiseControl.NET

Deploying files with CruiseControl.net using xcopy

Each CruiseControl.net job that needs to deploy files to a web server, does this through a batch file.  Inside that batch file is an xcopy command.

Here is an example

xcopy /exclude:..Scriptsexcludes.txt /E /F /Y /M .DerbyDerby.Website*.* \SBD-WEB-1inetpubDev1.derby.reurgency.netDerby

NOTE: the current working directory is always the folder called “Working” in our standard folder structure.

You will notice that the xcopy command uses a variety of switches that require some explanation and some WARNINGS.  Look at documentation here: http://support.microsoft.com/kb/289483

Here are my notes regarding these switches:

/exclude allows to exclude certain files. Those file names are listed in the excluded.txt file. At a minimum this should contain one entry for web.config.

/E copies any subfolder, even if empty.  This ensures that the proper structure exists on the web server.

/F displayes the full source and destination file names will copying.  This is helpful when looking at CC.net logs.

/Y overwrites existing files without prompting.  Important not to prompt since this runs automatically.

/M copies files with the archive attribute set.  This switch turns off the archive attribute.

That last switch /M works great as long as you only have one deployment script for this website using that switch.  i.e. if you have both a dev1 cc.net project and test1 cc.net project you will have a problem with that switch.

Here’s the way it works with dev1:

  1. CC.net gets latest files from SVN. Any new or modified files get their archive bit set.  This is not a CC.net thing, this is a basic feature of every OS file system.
  2. CC.net builds DLLs.  All DLLs build have their archive bit set.  Again, just basic file system behavior.
  3. CC.net runs the deploy batch file that contains the xcopy.  The xcopy  uses the /M switch which tells it to only copy the changed files (archive bit set).  It also resets the archive bit so it is not seen as changed the next time it runs.

This process makes deployments much faster.  However, it only works if there is one entity clearing that archive bit.  As soon as you have another environment (e.g. test1) you cannot use that trick for those other environments.  The issue is that two jobs are stomping on each other’s record of what has changed.  After a few runs, they will BOTH have out of sync files.

Therefore, here is best practice:

  • Dev1 will always use the /M switch because those deploys happen more frequently and we benefit the most from only copying changed files.
  • All other environments (Test1, Demo1, etc) will NOT use the /M switch because those jobs are run less frequently and it is OK if all files get copied each time.

 

CruiseControl.net Basics and Setting Up a New Project

The basics of using CruiseControl.net start with using the GUI to manage the different builds for each environment. Within the web app there are a few tips that can help in diagnosing problems when the build is broken. We will cover those items along with the basic items that need to be set up on a new project in this blog.

CruiseControl.net Web App

CaptureCC.NetGUI_Home

I will forego much of the obvious on the CC.NET home page. A couple  items worth noting is that this page can become stale very quickly especially if you keep it open in your browser. Each time returning to the home page it is a good idea to go ahead and click the Refresh button located in the upper right hand corner of the page to make sure that you have the most up to date information about the builds. Its also a good idea if you are waiting for a build to complete or have just forced a build that you go ahead and click the Refresh button to make sure you see the latest changes as quickly as possible. Another item to note is that when the build breaks all the people who commit after the build breaks will be listed as a breaker.

CaptureCC.NetGUI_ProjReportPage

In order to see who is responsible for breaking the build / bringing donuts to the next meeting click on the project name to dig into the details for the project.  If the build is broken then under the Build Overview chart  clicking on the first that broke(where the color changed from green to orange) will show the details of what was committed and by whom.

Once drilling into a build there are some important items that can be helpful in trouble shooting what is breaking the build. On the left navigation click on Latest Build and then on the left navigation click View Build Log will show the scripts that are run by MSBuild to build the dlls for the project along with all other scripts set up to run such as deployment scripts that will create backups and deploy the dlls to the web server. You can look at what is failing on each script that is run but usually its best to scroll to the bottom of the page to find quickly what is causing the build to break or causing other scripts to not work properly.

Setting up a New CruiseControl.NET Project

Step 1:

Create a new build project in CC.Net config and configure

To configure a CC.Net project first navigate to the config file located on the build.reurgency.net VM at  C:Program Files (x86)CruiseControl.NETserverccnet.config.

An example of the configuration for a project in the ccnet.config:


<project name="Youngevity" queue="Q1" queuePriority="1">
   <webURL>http://localhost/ccnet/</webURL>
   <workingDirectory>E:CIYoungevityWorking</workingDirectory>
   <artifactDirectory>E:CIYoungevityArtifacts</artifactDirectory>
   <modificationDelaySeconds>10</modificationDelaySeconds>
   <labeller type="assemblyVersionLabeller">
      <major>1</major>
      <minor>0</minor>
      <build>0</build>
      <incrementOnFailure>false</incrementOnFailure>
   </labeller>

   <triggers>
      <intervalTrigger seconds="60" name="continuous" />
   </triggers>

   <sourcecontrol type="svn">
      <trunkUrl>https://source.reurgency.net/svn/Youngevity/trunk/</trunkUrl>
      <executable>C:Program Files (x86)CollabNetSubversion Clientsvn.exe</executable>
      <username>CruiseControl</username>
      <password>21M6yI750528B7</password>
      <timeout units="minutes">30</timeout>
   </sourcecontrol>

   <prebuild>
   </prebuild>

   <tasks>
   <msbuild>
      <executable>C:WINDOWSMicrosoft.NETFrameworkv4.0.30319MSBuild.exe</executable>
      <projectFile>.Youngevity.sln</projectFile>
      <targets>Build</targets>
      <buildArgs>/p:Configuration=Release</buildArgs>
      <timeout>900</timeout>
      <logger>C:Program Files (x86)CruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
   </msbuild>
   <exec>
      <executable>E:CIYoungevityScriptsCopyDLLsToLatestBuild.bat</executable>
   </exec>
   <exec>
      <executable>E:CIYoungevityScriptsZip.bat</executable>
   </exec>
   <exec>
      <executable>E:CIYoungevityScriptsDeployWebServiceDLLs.bat</executable>
   </exec>
   </tasks>

   <publishers>
      <!--
      <buildpublisher>
      </buildpublisher>
-->
   <merge>
      <files>
      </files>
   </merge>
   <xmllogger />
   <statistics />
   <modificationHistory onlyLogWhenChangesFound="true" />
   </publishers>
</project>

Start by copying a project already set up in the cc.net config and renaming it. There are quite a few things that can be configured but for many projects much of the configuration will stay the same. The items that must be configured are:
1) Paths to the Working and Artifact folders
2) The interval trigger in the triggers section can be commented out if you want the build to only be updated when it is forced manually. This can be uncommented for a Dev1 environment that should be continually updated whenever any new code has been committed.
3) The trunkUrl under the SourceControl section should be set to the path of the correct SVN repository
4) Set the projectFile under the MSBuild task to the correct solution file
5) Change the path for batch files for all the executables for the new project

Step 2:

Allow permissions for the project  folder on the web server to allow CruiseControl access to deploy new files for the project

1) Navigate to the folder through windows explorer(this folder is usually under the default inetpub IIS folder)
2) Right click on folder, click on Properties, select the Sharing tab. Under Network File and Folder Sharing click on the Share button. In the drop down type in CruiseControl and hit enter. Make sure to change CruiseControl’s permission level to Read/Write, select from the list and click the Share button. Copy the Network Path as this is the path that you will need to use for the deployment batch file

Step 3:

Set up folders and scripts  for the new project

1) Create a new project folder under E:\CI on the build server
2) Create folders for Artifacts, Builds, Scripts, and Working files under the new project folder
3) Copy over batch files from another project into the Scripts folder and configure for the needs of the new project – there at least needs to be batch files for copying and zipping up latest dlls into the builds folder and a batch file for deploying dlls and files to the web server.

Step 4:

Allow User permission for CruiseControl to read from the SVN repository through VisualSVNServer

1) On the build server open up VisualSVNServer Manager
2) On the left section of the VisualSVNServer Manager expand the node of repositories and find the repository for the new project, right click on the repository, and click on Properties. Under the security tab add CruiseControl as a user with Read access.

If everything is configured correctly the project will be set up and can be managed from the CruiseControl.NET web app.