Friday, January 7, 2011

Many a nights before , I was going through this site . http://agilemanifesto.org/ (name sounds familiar , isn’t ?). I was trying to understand the basic concepts behind this “AGILE” thing. The explanation written in this site is pretty concise and to the point.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Interestingly , I completely endorse to what have been said above. However , last two lines stand out “That is, while there is value in the items on the right, we value the items on the left more.” Hence Agile never recommends that we should have no documentation in place , no processes in place. I have been faced with lot of criticism regarding Waterfall methodologies. Repeating same words like “we are Agile” does not solve our purpose and it just make us oblivious to the fact that every methodology has its pros and cons and nothing is perfect. One need to understand Waterfall or other methodologies before criticizing them and hence favoring Agile is good but getting obsessed with Agile doesn’t help us stand in good stead. My 2 cents here is if we don’t have a grip on what you are criticizing ,then we will dig ourselves into the same hole we thought we are getting out of. One need to be careful using "People over Process" to prematurely reject a practice.

It is imperative that we understand a basic underlying principle behind Agile rather than making Agile just an excuse of what we don’t want to do. To give an example , Agile manifesto does states that right amount of documentation is required. Being Agile does not mean that the documents like functional specification(user stories alone doesn’t solve the purpose) is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. However , Developer tend to use Agile just an excuse to code with no documentation or following no documentation. We need to do what makes sense and what adds business value but no documentation at all DOES NOT make any sense at all.

It is a proven fact that great people with a good flexible process ad tools are always hyper productive.

In my short career spanning 8yrs with companies of varied domains , I have come across the following line many a times :

"No we can't do that, because it's not Agile. This definitely is not Agile".

Following an Agile process religiously (that too being proud of it) even though the current situation or business need doesn’t warrant it, is definitely doesn’t justify us being Agile. If process is the most important thing , above all else , then I guess we need to go back to the agile basics and definitely that’s not AGILE. We need to debunk this myth once for all.

I am not a critic of Agile , however I think that if used in the right context catering to a relevant business need , then it’s great methodology to develop software’s .

Agile is a wonderful thing that has happened to the software industry but let’s not undermine its value by using it as a poor excuse for lack of processes , methods , direction and strategy.

Wednesday, January 16, 2008

Cruise Control


What is Cruise Control?

CruiseControl.NET is an automated continuous integration server for the .NET platform. It is a free open source software and also contains the plug-in like email notifications.
It can be integrated with one of the source safe tools (VSS in the present scenario) and a build tool (visual Studio .net).

The tool will automate the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications, the tool will automatically launch an integration build to validate the changes.



What are the advantages of using Cruise Control?

When the build is complete, the tool can notify the developer whether the changes that they committed integrated successfully or not.

Optionally, we can include unit tests in the codebase as part of the project.

It would help us identify any errors sooner rather than later, since we can either back out the offending commit or take other appropriate action to alleviate the problem without having to dig through our memory and our source control repository for the exact changes that caused the problem.

By doing this, you would be able put in place a way to receive rapid feedback at steady intervals. Though, we would still want all the developers to run their own local builds and unit tests, and perform their own integration testing before they check in their source code changes. But with the help of this tool, we have a way of communicating the project’s status to everyone all the time. This will also help prevent our developers from getting lazy or sloppy about their source code check-ins, because they know that tool will always report the truth. This will also help us produce higher-quality software.




Sequence Diagram for the Continuous Integration Process





Working with Cruise Control ( Installing and Configuring).

Installing CruiseControl.NET is straightforward; you'll want to have the .NET Framework and IIS with ASP.NET installed first.

Step 1 :

Download the Cruisecontrol.net from the following website.
http://sourceforge.net/project/showfiles.php?group_id=71179
You can download any one as shown in the sceenshot below ( the only difference being the msi installer/ zip file and with/without source code ) . I downloaded the one as highlighted below i.e without the source code.




Step 2 :


Click on the downloaded setup.exe file and install the ccnet ( CruiseControl.Net ) server along with all of its components.
Make sure we chose to select the ccnet server to be installed as windows service. Though it is not necessary but is recommended as it would help us automate it completely by scheduling it to run automatically after a specific interval of time. Please refer to the screenshot below.
WebDashboard is the application which provides the user interface to see the results of all the builds long with their logs and other information.





Step 3 : CruiseControl.NET uses the XML files produced by various tools in order to produce styled results. Unfortunately, MSBuild does not come with a XML Logger by default, so you need to use an external logger to get this functionality. The tool for the same can be downloaded from
http://ccnetlive.thoughtworks.com/MSBuildXmlLogger-Builds/
As shown in the screenshot below. Downlaod the dll file save it in the server folder.




Since now, we have installed all the necessary tools for implementing CruiseControl.net, we are off and running to implement the continuous integration.

As this being our first cruisecontrol.net project, we would prefer to run it manually as and when required, so open the services window and make sure that we change the “startup type” of the installed ccnet service from automatic to manual. ( Dashboard application is not available if the ccnet service is not up and running). Please refer to the screenshot below.





Step 4 :


ccnet uses an xml configuration file to drive the build process: ccnet.config. This file is included in every 'server' folder in our ccnet setup.

All the code that is being written like code to fetch the latest from sourcesafe and integrating the unit test cases etc are to be written in the configuration file of the ccnet server application. So , the next step is to open the configuration file ( refer to the screenshot).



There are different components in the configuration file to discuss about. I will be discussing the same on a sequential basis. First I would discuss about the section which is responsible for establishing the connection with sourcesafe and retrieving the latest from the same.



The lines highlighted in green in the screenshot are the comments/explanation for each of the tags necessary for integrating the sourcesafe and retrieving the latest from the SourceSafe.


The next section is the “Trigger” section as shown in the screenshot below.


In the above screenshot , the forcebuild is scheduled for every 60 seconds. We can also do the other way around to have a build every 60 seconds only incase of any modifications in the VSS and have a forcebuild once at one specific time of the day. We would need to use the tag “Scheduletrigger” as well for the same in the above section.

We can also include “modificationDelaySeconds” element which puts a ten-second delay into things so that multiple checkins in a short span of time don't trigger multiple builds; it waits until things are quiet for a little bit before getting underway.
Please note that the time duration entered in the configuration file is in seconds.


Any steps for executing any tasks like calling any command-line executable, invoke Visual Studio .NET directly, and so on. are included in the “tasks” section in the ccnet configuration file.


The first step in “tasks” section is to call the msbuild executable and build the code that has been retrieved from the sourcesafe followed by running the test cases. For further details , please refer to the screenshot below.



For running the test cases , I have used the mstest ( we can also implement nunit).
Build arguments passed are ::

1. The path of the dll of the test project.
2. The name of test run config file which is niohting but visual studio test configuration file which is automatically created by VS.net and contains the details of all the test to be executed.
3. Name of the test results file ( it is of extension .trx ) which is created in the working directory after the unit test cases have been executed.




Please note that the .trx file need to be deleted everytime the ccnet is executed. The reason being MsBuild doesn’t delete/overrite the existing trx file and generates an error if .trx file already exists. As a mitigation strategy , we would create a batch file which deletes the .trx file if exists and call that batch file in the tasks section before running the build executable from ccnet config file itself. ( This will do later , for the time being please make sure that we delete the .trx file everytime we run the ccnet )


The last section is the publishers section which is required to merge the contents of the generated results file into the xml style sheets inorder to be displayed on the webdashboard. For further details , please refer to the screenshot .



Once the ccnet.config file is saved, our configuration for the ccnet server is complete.

In order to view the results of the ccnet config file on the dashboard , we need to make couple of changes in the configuration file of the dashboard application as well which are as follows.

Open the dashboard.config file as shown in the screenshot below.




Since we are using MSTEST , so we need to use the mstestsummary.xsl stylesheet and the same needs to be communicated to the dashboard application. Hence , please make the necessary changes as highlighted in the screenshot below.



Save the configuration file and we are through with configuring the ccnet server and webdashboard application as well.



Running / Testing the above Installation


Run the ccnet.exe ( you can use the desktop shortcut as well). Please note that if the service is running , the ccnet.exe will not run manually.


Once the ccnet is executed completely , restart the Cruisecontrol.net Service as shown in the screenshot.













Click the link
http://localhost/ccnet to open the dashboard application.



Click on the “MaerskCat” project which is followed by the screen as shown in the screenshot .






Click on the “Latest build” as highlighted in the screenshot above to see the comprehensive details of the last build as shown in the screenshot .




This is what according to me would suffice when you are start getting your hands dirty with CruiseControl.
One of the admiring features is that we can also play with the version of the assemblies which i would cover in my next blog soon.
Hope this would be useful for people who are just trying to explore what cruise control is !!!