Category: Team System

Continuous Integration, SDLC, Software Configuration Management, Source Control, Team System, TFS

Continuous Integration : the Value Proposition

The topic of Continuous Integration  has gained a lot of ground in the past few years in the Software Development world – several high quality tools have emerged . Some companies have adopted it as integral part of SDLC methodology. Some I think are still trying to understand it , however a lot have not yet just made it their daily practice due to either lack of tools within the company or lack of a process. I have worked in this industry for more than 20 years and there are several reasons why I think CI adds immense value to software development process to make it efficient and productive. After going through many sucessful and some unsuccessful projects , here is how I conclude CI brings in value:

1 ) Bugs are detected on a daily / regular basis and remedied right away by integrating code checked in by different developers into Source Control . Continuous Integration works by kicking off a build process on your build server based on check-ins made by the team . CI tools give you the option to build as a check-in is made or at a certain frequency or at a certain time etc. So you get to control how you go about it. If a Build is required to be done as a check-in is done by a developer , right away bugs / integration problems get detected – they are remedied as you go along daily, reducing many integration hassles and mitigating risks earlier.

2) In medium to large scale projects there are different groups , stake holders . DBAs who work in conjunction with Application Developers sometimes want to look at GUI or application in action to see what type of data was entered that caused a SQL / Stored Procedure to fail. Although DBAs don’t necessarily need to look at application running in Dev Integration server to detect data related problems , however it gives them a great way to Visualize what an application developer has to say about why a SQL exception may have occured. It expedites problem detection by running the application as well as other runtime SQL method call capture tools like SQL Profiler concurrently.

3) A little while ago I wrote a blog about how the gap between UX Designers and Developers can be bridged by following certain practices with the development cycle. Continuous Integration can play a key role in shortening the gap : UX Designers often or almost always need to see the final integrated UI after the UI developers take UX designer’s Mocks / CSS / Javascript and integtrate their code with it. If you have a CI in place the UX designer can just go to the dev server and look at the latest dev build helping him see how the final UI looks without having to sit next to the developer. Obvious as it is , this will aid in UI layout related debugging and early detection of any cosmetic problems as well as work flow related issues.

4) Progress Track and Control are an integral part of Project Management and SDLC. PMs , BAs and Management stake holders need to be kept in the loop as regularly as possible for better Control management of any software project. A great way to measure development progress by non technical groups is to look at the actual application taking shape on the Dev Build server. Needless to say how this will help very early in the Iteration of a project. Any problems , risks or change requirements can be made early on saving time and money which are the two crucial cornerstones for a Project’s success.

5) In this age of globalization and distributed enterprise , CI can play a crucial role in bringing different groups together . Developers could be in India , UX team could be in US and other stake holders could be anywhere. If dev build servers can be accessed via the company Intranet or VPN from anywhere then the communication and collaboration gap is not widened by geographical distances and Project can be delivered on time even with a distributed arrangement like this. Here is a diagram that visually conveys the idea….

Continuous Integration Integration with Project Team
Entire Team Interaction with CI

The reasons above qualify enough for every organization to adopt and invest in CI – especially for medium to large projects . There are several tools available – form Open Source to Proprietory . Cruise Control is a well know open source tool as welll as TFS by Microsoft which ia an end-to-end SDLC tool. These are just examples. Web is full of articles, blogs and tools that you can use for CI. If you have not taken the time to integrate it into your team’s dev process , wait no more it’s worth your while and money.

Cruise Control

SDLC, Software Configuration Management, Source Control, Team System, TFS

TFS : Make the most of it

The decision to buy TFS or Team Foundation Server is not an easy one ; it’s an expensive product, although Microsoft has introduced TFS Basic as of this writing , however several larger organizations with budgets have already invested in the TFS full version. Interestingly enough , where I was before I worked for different groups who all used TFS , but barely tapped it’s potential. TFS almost immediately gets adopted as a Source Control because of  it’s  containment inside Visual Studio IDE. It easily becomes a developer’s everyday tool where developers use it for Source Control as well as Continuous Integration. The Continuous Integration support works off of the IDE again and you need not use any other tool to configure it. The only other configuration that happens is on the Server side where you are hosting the Team Foundation Build Service. So , this is still in the Developer’s paradigm or a Build Master who interacts directly with Developers.

However , this is barely any use of what TFS can offer – TFS is an End To End SDLC tool which can be used for the entire Life Cycle Management of the Project by all team members without having to use anything else. Team members include non developers like Business Analysts, Project Managers , Testers , End Users and other Stake Holders. However the problem with all these non developers using TFS comes with TFS client being Team Explorer which installs a shell of Visual Studio and uses the Visual Studio interface for TFS connectivity . This can turn off a lot of non developers in the team from using it because most of these people are not used to having Visual Studio as an application on their machines.Even the Developers ended up not making full use of it because Project Managers or BAs don’t use it where Requirements and Work Items can be created, against which development can be done and tracked.

If your organization has already invested in TFS , I think you must make a dedicated effort in getting everyone to make use of it so the entire SDLC can be managed efficiently with just one tool.  This blog is not meant to be an advertisement for TFS : the idea is if you have chosen to invest in TFS , get most on your investment by getting the Team to use it as SDLC tool so you get the right value for your money. TFS integrates with Sharepoint and MS Project Manager – two very popular enterprise Project Management and Collaboration tools. The adjustment needs to happen mainly in installing the Team Explorer client which is Visual Studio GUI interface . I have used VS 2008 Team system and started using the 2010. Team Explorer for 2008 is free and a seperate install. Once that’s done you can connect to TFS server and your Team’s project and  manage everything from there itself.

We used TFS for our entire cycle as well as Post Production support for one of our projects. One major issue we found was we had our customers create issues in Sharepoint site of the Team Project . As of this writing the 2008 version lacked a good integration where the Work Items or Issues created by Sharepoint users could not be easily imported into the Visual Studio client interface. We had to Excel export the Sharepoint items and then import them back into Team explorer through Excel, which is a kind of round about way to achieve something that could have been offered as simple one click function from the tool itself. I am not sure if they fixed this in the newer 2010 version , if so then completes the product without any holes for SDLC management.

PS: we used TFS for all of our .Net projects . I know that TFS can be used with other stacks as well , like Java for example – however not sure if the Continuous Integartion would work correctly for Java because TFS Build engine uses MSBuild and the .Proj files to make builds. Anyways if you are a MS shop with .Net projects then TFS is definitely a great project management and collaboration tool.