Version Control For An Agile Team

Version control for an agile team A version control system is not just a tool to manage the content of a project, it's defines how the project team collaborate and interact with each other. And it plays an important part when the team decides how they are going to manage the changes to the code. Version controlling systems started with lock based version controlling with RCS, SCCS in 70’s. And the next generation CVSwere CVS in 1986, Perforce (1995), CVSNT (1998), and then we got Subversion (2000); they were commonly referred as centralized version controlling systems which means they have a central repository which keeps all the content and the history. Individual clients (team members) have their local code which can be sync with the central repository. And also a client can get the historical versions of the files as well.

Figure1: Centralized version controlling
In this type of version controlling systems every change had to be submitted to the central repository. Let's say A needs to some change and B need's to get that change to proceed his work. Then A should check-in or push the change to the central repository and B need's to get or pull those changes from the central server. These changes will also be visible to C, whether this is desired or not. This model is called a centralized version control systems. Arch, Monotone and Bitkeeper were the first Distributed version control systems (DVCS). In December 1999 Linus Torvalds, the creator of Linux kernel, chose Bitkeeper in order to manage the mainline kernel sources. At that time Bitkeeper was the only truly distributed version control system which had repositories for every user of the source control system. That means in a DVCS all the clients have a repository which can be called a local repository containing all historical revisions and branches.

Figure2: Distributed Version Controlling

So in this model since each endpoint has the total repository it can be act as a server itself. There is no central point which controls everything but each endpoint can directly push or pull updates from any other endpoint which makes it kind of a peer to peer network.

Figure3: DVCS in operation

 One of the advantages of having a local repository for each endpoint is that we can work offline without connecting to a central repository like centralized version control systems. Since all the historical data is in the local repository we can get older versions and even merge them offline. This make developers work easy because developers can work where ever they are. And in distributed version control systems branching and merging is an easy task compared to other version control systems because every change acts as a kind of a branch and we need to merge that to the main branch. This is because DVCS's keep change sets instead of versions of the file. When we do a commit what it stores is the change we have done instead of a new version of older file like most of the centralized version control systems. This makes merge easy since it's just applying sequence of changes to a file instead of merging two versions of a file.
 By encouraging branching and merging DVCS offers flexibility for the developers to experiment new ideas without affecting the main branch. For agile teams it's really important to have flexibility to change the code and experiment new requirement in different ways. Let's say for a new requirement or a feature team needs to do some R&D on several ways of doing it. Then with the DVCS team can create experimental branches to experiment different methods and if one experiment is successful then it's just a matter of merging that one in to the main development branch. For agile teams it's really important to have flexibility to change the code and experiment new requirements in different ways. For example, the team needs to do some R &D to figure out the best approach to implement a new requirement or feature. Then with the DVCS team can create branches to experiment different methods and select the branch having the most successful experiment and then it's just a matter of merging that branch in to the main development branch.

Figure 4: Diagram showing experimental branches

 This allows developers to work freely. It doesn't really matter that a developer breaks the build in an experimental branch because he can work independently on their branch. And it increases the collaboration of the agile team because it's really easy to push the changes directly to any other member without affecting any other members in the team. This gives us another important advantage of DVCS for agile teams.

Figure 5: peer to peer communication

And this increases the collaboration and the effectiveness of agile teams. With the centralized model, if one team member needs to share his version of code with someone else, he needs to push his changes to the central server and then the other one needed to pull changes from the central. But in DVCS there is no central server to control; therefore one user can directly push his changes to any other user because it enables. This increases the effectiveness of an agile team in several ways because sometimes it is really important to work independently for two or three people in the team. And most importantly this enables two people to to do pair programmingwork withoutindependently without affecting other team member's code. And if you want to pair program remotely then the Dropbox will be the ideal tool.
 Figure 5 shows a model with one central repository and several team members. The central repository has the stable version of the code. This is somewhat similar to a centralized model. But the link between A and B is enabled by the DVCS. If A and B needs to some pair programming they can directly push and pull the changes. This is more important, because sometimes they need sync unstable code. Of course you can do it with other centralized version control systems as well .But in that case the changes need to be emailed to the other developer.

 Once we have chosen DVCS over centralized version control systems as the best option for our needs, then we need to consider which tool to use. Git and Mercurial are the well-known and widely used DVCS. Both of them are open source and have some similar functionality. Git is more complex to use rather than mercurial because it has more complex and more flexible model. Therefore mercurial is easy for someone coming from a centralized version controlling background to adapt to quickly. You may find links to good articles on git and mercurial at the references section. A version controlling system for an agile team should be agile too. That means the tool should be flexible enough for the team to use as a successful version controlling and a collaboration model. Choosing the right tool for a particular job is really important but it can be difficult task as well. Because we are familiar with one tool and mastered how it can be used, we tend to be bias towards it instead of looking at how a different tool can be more productive. But if we can change our mind set for exploring the different options we have and to choose the best tools that will help us, we can improve efficiency and the effectiveness of the team.

 Reference:

1.  http://www.infoq.com/articles/dvcs-guide&num=30
2. http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Distributed Version Controlling with Murcurial

Real Time Messaging On Web - Sample Using Socket.IO and Node.Js

Socket.io enables real time synchronization across browsers while using different underlying transport methods.It uses different transport mechanisms to support multiple platforms.To understand how it works we need to get some basic principles behind socket.io .First thing is it can use several transport mechanisms like xhr-polling,xhr-multipart,htmlfile,websocket,flashsocket, jsonp-polling.The client will decide what transport method to use .To start the connection it will do a basic http hanshake and then based on client it will decide the transport method. Then it will use a lite weight protocol to communicate.

I'm doing this example on node server on windows. If you are new to Node.js it's better if you go through my previous article Node.JS Sample Application On Windows. . Here I'm going to use socket.io on Node server.

First we need to install Socket.io on Node server. For that go to your project folder and use npm command npm install socket.io . It will install socket.io in to your folder as a node module.

Now you can see a folder has been(node_modules) created in your project folder.
Then we need to have our web page. Create the Index.html page and save it in the project folder ,

 
 
  
   
   
    
Welcome to socket.io .....
    

Next step to create the server app to serve the HTML page , Create the Server.js with following code and save it in the project folder.

var app = require('http').createServer(handler)
  , io = require('socket.io').listen(app)
  , fs = require('fs')

app.listen(8012);// give a port not used by other apps

function handler(req, res) {

    fs.readFile('index.html',
  function (err, data) {
      console.log(err);
      if (err) {
          res.writeHead(500);
          return res.end('Error loading index.html');
      }

      res.writeHead(200);
      res.end(data);
  });
}

So now we have all required files in project folder,

Then we can run our server, Go to the folder from comman prompt and exacute command node server.js

Then we can use the browser to see our index.html page user the url http://localhost:8012/

Then the important part, integration of socket.io for real time communication, There are several reserved event for the socket.io server, 'connection' - initial connection from a client.
'message' - "message" is emitted when a message sent with socket.send is received. function.
'disconnect'- fired when the socket disconnects.


For our sample app we can use the 'connection' event to send something on any connection , Append this code to the Server.js

io.sockets.on('connection', function (socket) {
    socket.emit('Initialdata', { hello: 'world' });
});

And then change your client (Index.html) to communicate with socket.io server with flowing code,

   

 Welcome to socket.io .....

Then restart the node server (Again exacute node server.js command). Now you can see the alert by refreshing the web page,

So now we have up and running socket. Our next step is to make real time communicating clients. For that we need to add a text box and a button to the client and javascripts to send the message to the server to broadcast for other clients,

    
    


    


        Welcome to socket.io .....



    

Now our client is ready for sending and receiving messages. Next step is to change the server to broadcast received message from any clients to all the other clients connected. Change the server with following code,

var app = require('http').createServer(handler)
  , io = require('socket.io').listen(app)
  , fs = require('fs')

app.listen(8012);

function handler(req, res) {

    fs.readFile('index.html',
  function (err, data) {
      console.log(err);
      if (err) {
          res.writeHead(500);
          return res.end('Error loading index.html');
      }

      res.writeHead(200);
      res.end(data);
  });
}

io.sockets.on('connection', function (socket) {
    console.log('Socket Created...');

    socket.emit('InitialData', { Message: 'Hello World !' });

    socket.on('sendMessage', function (data) {
        socket.broadcast.emit('messageRecieve', data);
    });
});

We are ready with our client and the server. Restart the server again using node server.js , and open two browser windows( http://localhost:8012/ ) to demonstrate multiple clients scenario ,