Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
16Activity
0 of .
Results for:
No results containing your search query
P. 1
Cruise Control.net

Cruise Control.net

Ratings: (0)|Views: 2,780|Likes:
Published by semalaiappan

More info:

Published by: semalaiappan on Apr 07, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

05/11/2014

pdf

text

original

 
 
CRUISE CONTROL.NET
SLNo Content Page
Study & Overview
1.
Introduction to Continuous Integration and Cruise Control .Net
22.
Installation Process
113.
CCNet server configuration(CCNet.config)
124.
File Merge task 
225.
Configure CruiseControl.Net to Automatically Update its Config File
246.
CCTray
26
 
Build Configuration - Nant
7.
Integration on a project built using Nant
298.
 Nant element in configuration file
319.
 Nant O/p in XML File
3210.
 Nant and Nunit
3211.
CCNet build labels in Nant
3312.
CCNet build from Nant script
35
 
Build Configuration - MSBuild
13.
Integration on a project built using MSBuild
4314.
MSBuild element in configuration file
43
 
Build Configuration - Visual Studio
15.
Integration on a project built using Visual Studio
5116.
Visual Studio element in configuration file
52
 
Web Dashboard
17.
Installation
5318.
Configuring the web dashboard
54
 
 
CRUISE CONTROL.NET
19.
Using Web dashboard
6720.
Developing web dashboard plug-ins
69
 
Study & Overview
Introduction of Continuous Integration
Continuous Integration is a software development practice where members of a team integratetheir work frequently; usually each person integrates at least daily - leading to multipleintegrations per day. Integration is verified by an automated build (including test) to detectintegration errors as quickly as possible. Many teams find that this approach leads tosignificantly reduced integration problems and allows a team to develop cohesive software morerapidly.
Feature with Continuous IntegrationMaintain a Single Source Repository.
Software projects involve lots of files that need to be orchestrated together to build a product.Keeping track of all of these is a major effort, particularly when there's multiple people involved.So it's not surprising that over the years software development teams have built tools to manageall this. These tools - called Source Code Management tools, configuration management, versioncontrol systems, repositories, or various other names - are an integral part of most development projects.So as a simple basis make sure you get a decent source code management system. The currentopen source repository of choice isSubversion. (The older open-source toolCVSis still widely used, and is much better than nothing, but Subversion is the modern choice.).Once you get a source code management system, make sure it is the well known place for everyone to go get source code. Everything should be in the repository.The basic rule of thumb is that you should be able to walk up to the project with a virginmachine, do a checkout, and be able to fully build the system.You must put everything required for a build in the source control system; however you may also put other stuff that people generally work with in there too. IDE configurations are good to put inthere because that way it's easy for people to share the same IDE setups.One of the features of version control systems is that they allow you to create multiple branches,to handle different streams of development. Keep your use of branches to a minimum. In particular have a
mainline
: a single branch of the project currently under development. Pretty
 
 
CRUISE CONTROL.NET
much everyone should work off this mainline most of the time. In general you should store insource control everything you need to build anything, but nothing that you actually build.
Automate the Build
Getting the sources turned into a running system can often be a complicated process involvingcompilation, moving files around, loading schemas into the databases, and so on. However likemost tasks in this part of software development it can be automated - and as a result should beautomated.Automated environments for builds are a common feature of systems. The .NET community hashad Nant and now has MSBuild. Make sure you can build and launch your system using thesescripts using a single command.A common mistake is not to include everything in the automated build. The build should includegetting the database schema out of the repository and firing it up in the execution environment.I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.A big build often takes time; you don't want to do all of these steps if you've only made a smallchange. So a good build tool analyzes what needs to be changed as part of the process. Thecommon way to do this is to check the dates of the source and object files and only compile if thesource date is later. Dependencies then get tricky: if one object files change those that depend onit may also need to be rebuilt. Compilers may handle this kind of thing, or they may not.Depending on what you need, you may need different kinds of things to be built. You can build asystem with or without test code, or with different sets of tests. Some components can be builtstand-alone. A build script should allow you to build alternative targets for different cases.
Make Your Build Self-Testing
Traditionally a build means compiling, linking, and all the additional stuff required to get a program to execute. A program may run, but that doesn't mean it does the right thing. Modernstatically typed languages can catch many bugs, but far more slip through that net.A good way to catch bugs more quickly and efficiently is to include automated tests in the build process. Testing isn't perfect, of course, but it can catch a lot of bugs - enough to be useful. For self-testing code you need a suite of automated tests that can check a large part of the code basefor bugs. The tests need to be able to be kicked off from a simple command and to be self-checking. The result of running the test suite should indicate if any tests failed. For a build to beself-testing the failure of a test should cause the build to fail.
Everyone Commits Every Day

Activity (16)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Mahender Mahi liked this
Siva Kumar Kalva liked this
ameshlal liked this
ra_mesh241978 liked this
Naveen Lohchab liked this
jinnjee liked this
mrsavoury liked this
hatedbooks liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->