Feature Branches vs Release Branches

Lee Dumond (http://leedumond.com) posed a question earlier regarding the advantages and disadvantages of using source code management (SCM) feature branches over release branches. I can’t fit my response into a single tweet so I thought I’d blog my views on the matter.

I don’t really think feature branches and release branches can be compared as they are two types of branching methods employed at different stages of an iterative development process.  Feature branches are generated off the trunk or another branch for the sole purpose of allowing a team to add a single feature to a product in complete isolation from the branch it was created from. When the feature is complete the branch can then be merged back into the branch it was originally sourced from.

A release branch is created to build a shippable version of a product. It generally consists of one or more features and therefore may have multiple feature branches merged into it.

How the release is shipped is then is a team decision based on the scale of the project and the number of branches being ran concurrently. If no other branches are running off the trunk, the release branch could be merged back into the trunk and a shippable build generated off the trunk. Alternatively, a shippable build could be generated off the release branch prior to merging the branch back into the trunk.

Lately, I’ve generally manage development of National Rural using release branches consisting of two to three features, developed sequentially where possible for the following reasons:

• A working demo version of the release can be available for the stakeholders as soon as possible showing one or more of the features working.
• Developing in small iterations generates less pain when the time comes to merge the branch back into the trunk!

As I only tend to run one release branch at a time, the branch is then merged back into the trunk and a build and release is generated off the trunk. I then tag the trunk with the release number so I can always revert back to the tagged version if the next merge goes horribly wrong.

When working in a team on a branch…

• Always update your working copy after another team member has checked in and the branch has built ok to keep your working copy up to date.
• Never, ever, check in code that you know will break the branch build. An unbuildable branch stops other developers jumping into the branch to help out and generally pisses off the work force.

I think this methodology is flexible enough to adapt to much larger teams developing on multiple branches but would welcome any alternative views on this.

Tooling Up to Develop Without Team System

I had a three-way conversation on twitter today comparing the use of Visual Studio Team System with other freely available development tools.  Rather than tweeting my responses, I thought I’d blog about the development tooling I use and why I don’t think VSTS is necessary to develop. Here’s an outline of my development infrastructure:

1. Source Control -  SVN using Tortoise SVN on my client machine. Have a look at this earlier post on source control for more information on how I use it.

2. Automated Build System – Cruise Control. What can I say? The key element for any development environment. If there isn’t a build, there isn’t a product. As a complete CC virgin,I setup a cruise control server from scratch and had a build up and running within half a day and haven’t looked back. A cruise control server can manage multiple projects. Being web based, it can be accessed remotely and a client application can be installed on the developers machine to indicate the build state of one or many projects from the the system tray.  The build tasks for each project are held in an xml-based config file and can easily be edited when required.

3. Unit Testing –  I’ve used NUNIT on and off since I started writing unit tests for my code. I augment NUNIT with NMOCK, a mocking framework which enables modules to be effectively tested in isolation.

4. Bug Tracking/Reporting – I use TRAC for bug tracking and reporting which interfaces with SVN and many other SCM systems so code check-ins can be associated with ticket numbers. CVSDude offers SVN and TRAC together in a SaaS bundle. Its quick to setup, secure and reduces the TCO for my  projects (No, I’m not on commission!).

I’m not anti-Microsoft and completely acknowledge that no one ever gets the sack for recommending Microsoft products…

VSTS gives you all the functionality mentioned above wrapped up and integrated seamlessly into the Visual Studio IDE. It also utilises office applications for reporting and if I had the budget, I’d use it. There, I said it.  I still see it as a nice to have though and hope , that this post raises the awareness of alternatives to TFS that won’t break the bank but will still help you to develop and ship products effectively.

HTTP Response Code 411 - when making an AJAX call

This issue arose using FireFox while making an ajax post to an ASP.Net MVC site using jQuery. The issue did not arise using IE or Chrome.

The bare bones of the ajax call I was using is displayed below :

   1: $.ajax({ 

   2:     error: function() { alert("error!");},

   3:     success: function() { alert("success!")},

   4:     url: settings.Url,

   5:     type: "POST"

   6: });

The function returned a status code of 411 and a status text of “Length Required”(?). After doing some digging around I found that I had to explicitly state that the data property of the $.ajax object is empty as so (line 5):

   1: $.ajax({ 

   2:     error: function() { alert("error!");},

   3:     success: function() { alert("success!")},

   4:     url: settings.Url,

   5:     data: {},

   6:     type: "POST"

   7: });

I thought I’d blog it here for future reference and in case anyone gets this problem.

Passing functions as arguments in JavaScript

I’ve been thrashing Javascript a bit lately and one of the language features I’ve been using involves passing a function as an argument to another functions. Have a look at this example:

   1: function Greet() {

   2:     alert("Hello User");

   3: }

   4: function Farewell() {

   5:     alert("Goodbye User");

   6: }

   7: function Action1() {

   8:     PromptThenAction("Do you want the browser to greet you?", function() { Greet() });

   9: };

  10: function Action2() {

  11:     PromptThenAction("Do you want the browser to bid you farewell?", function() { Farewell() });

  12: };

  13: function PromptThenAction(msg, fcn) {

  14:     if (confirm(msg)) fcn();

  15: }

Greet and Farewell are functions that display a relevant message.

PromptThenAction (line 13) accepts two arguments, msg and fcn. The confirm function is called which displays a modal message box displaying a message(in this case, the value of msg) and an OK and Cancel button. If the user presses OK, fcn is invoked.

Function Literals

The function is invoked this way due to a feature of javascript called function literals. A function declared using a function literal can successfully be passed as an argument, as it is stored as a variable and therefore not invoked when the arguments are evaluated. Here is another way to use function literals to declare the function as a variable.

   var f = function() { Greet() };

Were we to do this, we could pass f in as the second parameter to the PromptThenAction function. If we replaced line 11 above with the following:

PromptThenAction("Do you want the browser to bid you farewell?", Farewell());

Farewell would be invoked prior to the confirm function as it is evaluated as a function rather than a variable. Using function literals in the manner described above, improves code flexibility and leads to increased code reuse – always a good thing!

Technorati Tags: javascript