Wednesday, 8 May 2013

Why CI Build

There is lot of talk on CI builds nowadays. Have you ever thought why it has become a hot topic? Or is it really important? What is the benefit of it? OK to answer all above I will take you through a very simple demo with even simpler sample.

For simplicity let's say we only have two developers in our team. The Developer A and the Developer B. They both are working on a windows forms application referring to a class library from that.


Our Developer A starts development and he creates a method "GetWelcomeMessage" in Class1. Then he uses it in his Form1 he is developing in the Windows Application.



Developer A compiles this code successfully and checks-in the Class1 and Form1. Now the source control server (TFS) has the files as below.


Now our Developer B takes the latest version from source control server and he adds another form, Form2 and use the method developed by Developer A.


Developer B compiles his code successfully in his development PC and checks-in the code. Now the server copy will be like below.


The source control server (TFS) now have the code checked-in by both Developer A and Developer B. This source code is valid and compiles without any issue if latest version is downloaded to any of the developers' PCs.

Now our Developer A becomes a little bit lazy next day morning and do not bother to get the latest version from the server. So he still has only Form1 and the Class1 in his solution.


Developer A starts modifying code from yesterday WITHOUT getting the latest version from source control server. He changes Class1 "GetWelcomeMessage" method to accept a parameter (username) and include that in the return message. Then he modifies the Form1 method call to Class1."GetWelcomeMessage" to send the username.

The Developer A compiles the code in his development PC, and it looks good and compiles successfully. Developer A checks-in the modified Class1 and Form1 code to the source control server(TFS).

Now what is the status of the code in source control server. The Developer A has checked-in set of changes which is causing build errors in the solutions latest copy in the source control server.



Now if developer A or B download the latest version from source control server, none of them will be able to compile the solution. If both of them lazy enough to not to get the latest version, they will keep on developing and adding new files for their respective tasks without knowing about the errors in the latest copy of the solution. May be they will discover this just before, when they try to release to QA.

Wouldn't it be nice to have someone who compiles the source code checked-in to the Source Control Server (TFS) and alert the two Developers A,B about the broken build status, and the changes that caused the build break.

Exactly that is the job of a CI build in TFS world. CI build will build the Source Control Server version of the source code for each checked-in, change-set and alert if there is any build failures. This will give lot of benefit to the developers to easily identify the issue in the build by detecting the change-set caused the build break.

In my next post I will explain how to setup a CI build , for a solution with TFS 2012 & VS 2012.

No comments: