Archive

Posts Tagged ‘continuous integration’

Agile or Not-To-Agile

March 31st, 2009

All of you had definitely heard of a buzzword “Agile”. The mostly used words whenever some geeks discussing the development approaches, processes, management style blah blah blah. You will hear these terms Agile development, Agile design, Agile modeling, Agile testing, Agile project management, Agile roll out planning, Agile decision making, Agile Scrum, Agile languages, Agile database, Agile programming, Agile assembly, Agile game development, Agile thinking, Agile usability, Agile IT… You must be “Agile overload” now :)

I have all my sympathies with this word as its been used wrongly most often. Normally its being used to defend when someone is trying to hide his mistakes of violating company’s policies or processes etc. When I finally digged into real details for Agile after hearing a lot of differentiating opinions, I thought to share it with all of you as well.

Manifesto

First of all we should know who started thinking about Agile and what were the principles upon which its foundation had been built. In 2001 seventeen software anarchists met to agree upon the following principles that was later recognized as agile. These values are phrased as preferences for one aspect of software development over another:

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

For complete details, refer to this web page http://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html.

Is my project Agile?

After taking a look at manifesto, still what project should be regarded as Agile or non-Agile? Secondly, may we designate some part of a project as Agile and the rest as non-Agile? Does implementing continuous integration and unit test automation makes my project Agile? There are a lot of questions. I think we may come up with something like:

  • You have frequent releases and deliverable.
  • You welcome and manage change requests.
  • Larger projects changing into smaller applications is also a possibility you need to provide for.
  • You work closely with the client and/or business experts to provide a real business solution.
  • There are no fixed bids.
  • You wanted to be flexible and your client also wants the same.

May be you can add a couple of more items to the above list. The point is to know for yourself do you wanted to go for Agile and then really go for it. Remember one thing always “its not about Agile, its about success” as says Gary Pollice.

Drawbacks

Know for yourself what are the drawbacks or using Agile or let me re-phrase, when Agile should not be used:

  • Do not use Agile if your team size is more than 80 and increasing.
  • Do not go for Agile if the management style is not Agile. If the management is bureaucratic and you wanted Agile, you will definitely be pissed off.
  • People are inflexible and/or unable to react to change, using agile will be too hard for them to follow.
  • Stakeholders are unwilling to be involved actively. They like to invest time to make decisions.

At the end, before taking any decision do learn about it. Read this story about 6 blind men and an elephant, if you have not already read. As you take a decision think twice about this story to reach towards a good conclusion :)

admin Agile, Management , , , , , , , , , , , , , , , , , , ,

Build Automation

October 13th, 2008

You must be hearing and working as well on all the buzz about build automation, minimizing the chances for manual interaction by CC personnel. Yet it is a challenge to keep build scripts updated at all the times. I will talk about two tools that I have used for build automation and will share my experiences. I liked two aspects regarding build automation. These are:

  • Continuous Integration
  • Automated Build Generation

When I say continuous integration, I mean:

  • Monitor changes in the repository
  • Publish the results via web and email

When I say build automation, I mean:

  • Get source code from the repository
  • Build the complete application package
  • Executing unit tests
  • Coding standards validation using FxCop or some other tool
  • Creating documentation using NDoc or some other tool

My choice is to use CruiseControl.Net for continuous integration and NAnt for build automation. I feel more power & flexibility using NAnt. I am more comfortable using its tags. Its your choice you may make use of CruiseControl.Net tags if you want. In the following I would show you sample scripts for both of these tools to work hand in hand.

CruiseControl.Net (Continuous Integration)

This tool as I mentioned is used for Continuous Integration. Once the repositories are in place, we can make use of this tool so that on every change in the repository OR in a timely manner, this process could be started off.  You can download this tool from http://ccnet.thoughtworks.com.

It is purely xml based, you just need to configure its configuration file named ccnet.config. In the following, you will find a sample script which will contain tags for the repository to monitor, call NAnt & publish results on web and email.

<cruisecontrol>
<project name=”ProjectName”>


<sourcecontrol type=”vss” autoGetSource=”true”>
<ssdir>\\YourServer\vss\</ssdir>
<executable>\\YourServer\vss\win32\SS.EXE</executable>
<project>$/ProjectName</project>
<username>YourUsername</username>
<password></password>
</sourcecontrol>

<!– Changed to correct url –>
<webURL>http://localhost/ccnet</webURL>
<schedule type=”schedule” sleepSeconds=”60″/>
<build type=”nant”>
<executable>DrivePath\nant\bin\NAnt.exe</executable>
<baseDirectory>DrivePath:\projects\ProjectDir\</baseDirectory>
<buildFile>MyBuild.build</buildFile>
<targetList>
<target>build</target>
</targetList>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
</build>
<modificationDelaySeconds>10</modificationDelaySeconds>
</project>
</cruisecontrol>

The above is a sample script file that contains source control tag for VSS. Repository mentioned in this tag will be monitored for any changes. Then in the build type tag, NAnt has been invoked using build tag. NAnt will automated build generation. When cruise control is being invoked, this script gets executed.

Let’s look at NAnt now.

NAnt (Build Automation)

The above script will invoke NAnt whenever there is a change in the repository. NAnt is also open source, which is an equivalent for .Net like Ant for Java. Using NAnt we will generate the complete build and related processes. It could be downloaded from http://nant.sourceforge.net/.

Along with NAnt you will also need NAntContrib, its a contribution written over NAnt to provide you with some additional tags. NAntContrib can be downloaded from http://nantcontrib.sourceforge.net/. You will just need to copy all the contents of bin folder from NAntContrib to NAnt bin folder, and you are done. You will start getting all the advantages of NAntContrib as well.

NAnt’s configuration file is named like FileName.build. It’s an xml file as well, so no need to worry about any specific structure. Just need to get familiar with its tags. Sample script is as follows:

<?xml version=”1.0″?>
<project name=”ProjectName” default=”build” basedir=”.” xmlns=”http://nant.sf.net/schemas/nant-0.85.win32.net-1.0.xsd”>
<description>Write down any description</description>

<!– ********** –>
<!– Properties –>

<!– Solution.Filename represents the filename of the solution to build –>
<property name=”Solution.Filename” value=”DrivePath:\Project.sln”/>
<property name=”Solution.Configuration” value=”RELEASE”/>
<property name=”Build.OutputFolder” value=”Drive_Path\BuildLocation\”/>
<!– End Properties –>

<!– build will trigger main build –>
<target name=”build” description=”compiles the source code”>
<call target=”runGetLatest”/>
<solution solutionfile=”${Solution.Filename}” outputdir=”${Build.OutputFolder}${sys.version}\” configuration=”${Solution.Configuration}”/>
<call target=”runUnitTests”/>
<call target=”runFxCop”/>
<call target=”runCreateDocumentation”/>
<call target=”runCopyResults”/>
</target>
<!– End Targets –>

<target name=”runGetLatest”>
<vssget
user=”username”
password=”pwd”
localpath=”PathToGetCode”
recursive=”true”
replace=”true”
writable=”true”
removedeleted=”false”
dbpath=”\\Path\VSS\srcsafe.ini”
path=”$/DirNameInVSS”
/>
</target>

<!– runUnitTests will run the nunit task on the test dlls –>
<target name=”runUnitTests” description=”Runs unit tests on specified dlls”>
<nunit2 failonerror=”false” verbose=”true”>
<formatter outputdir=”${Build.OutputFolder}${sys.version}\” usefile=”true” type=”Xml” extension=”.xml”/>
<test>
<assemblies basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”*Test.dll”/>
</assemblies>
</test>
</nunit2>
</target>

<!– runFxCop will run the fxcop file of the same name as the nant project –>
<target name=”runFxCop”>
<exec program=”DrivePath\fxcop\fxcopcmd.exe”
commandline=”/p:${nant.project.basedir}\${nant.project.name}.fxcop /o:${Build.OutputFolder}${sys.version}\fxcop-results.xml” failonerror=”false”/>
</target>

<!– runCreateDocumentation will create msdn type documentation for the building solution –>
<target name=”runCreateDocumentation” description=”Will create documentation for Buidling Solution”>
<ndoc>
<assemblies basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”ProjectAssembly.dll” />
</assemblies>
<summaries basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”Project.xml” />
</summaries>
<documenters>
<documenter name=”MSDN”>
<property name=”OutputDirectory” value=”${Build.OutputFolder}${sys.version}\doc” />
<property name=”HtmlHelpName” value=”ProjectNAme” />
<property name=”HtmlHelpCompilerFilename” value=”hhc.exe” />
<property name=”IncludeFavorites” value=”False” />
<property name=”Title” value=”ProjectName” />
<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=”YourCompURL” />
</documenter>
</documenters>
</ndoc>
</target>

<target name=”runCopyResults”>
<copy todir=”${Build.OutputFolder}Latest\”>
<fileset basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”*-results.xml” />
</fileset>
</copy>
</target>
</project>

In the above you will find tags for getting latest source, building the solution, running fxCop & NDoc. I have shown in this sample some tags that may help to get started with CC.Net and NAnt.

admin General , , , , , , , , ,


Copyright © 2008-2009 W@rfi