Piotr Woloszyn

Me and my new team preparing now to starting a new greenfield project in month or so. Starting something new is very exciting itself and lets us put new processes in place. But how to decide about the processes? Simply by collaborating, discussing and exchanging ideas and previous experience. In this post I will focus on the development/release process and choices we are facing at the moment.

Just to give some perspective… In the past when working on the BT SDK with Web21c team I was using ScrumWorks for managing user stories or, as some other people would call it, features, improvements or bugfixes and mapping those to particular releases. The public releases were very infrequent and scheduled every 3 months. Emergency releases with bug fixes could happen more often. Of course as for an agile team internal releases occurred more often, usually every 2 weeks ended with an acceptance session with a product owner. The Subversion has been used as the source repository, with all active development happening usually in parallel in the trunk. Some time before release the code was frozen in a branch by copying an active trunk and only bug fixes were applied to the release branch, subsequently merged back to the trunk. I could call this process “Develop in trunk, release from a branch”.

At my current project we use only JIRA for managing bugs/features/improvements and matching it to particular releases and the releases will occur much more often (every week or two) with possible multiple emergency releases in meantime. Source is kept in Subversion as well. The team is not calling itself “agile” however I think it has to be very agile to cope with the schedule and a right process should be established to support it. It could look like:

Development time

1. In JIRA we create a bunch of tickets for new features, bug fixes or improvements. A developer is assigned (hey, who likes that phrase?) a task to work on.
2. Before starting work a new branch is created from trunk with the JIRA number as a name
3. Work on that task commences and all changes are committed to the new branch. If there are several dependant tickets then JIRA should have a parent ticket created and all dependant tickets assigned as children. It resembles higher level user story with tasks from Scrum.

Build/Release time

1. In JIRA a release or version will be set up and given a name (i.e. 1.0.1). This will contain a list of tickets that are to be used for this release
2. A new branch will be created in SVN from trunk, matching the name of the JIRA release.
3. The branches that match the JIRA tickets for this release are merged into the new release branch.
4. A continuous integration build is pointed to the newly created release branch.
5. The build should pass unit tests, integration tests, automated acceptance tests, is then deployed to UAT environment for final user acceptance tests.
6. When ready for release, a tag is created from the branch matching the JIRA release name. The software is deployed to production.
7. The code from the tag is now merged back to trunk

It is clearly “Develop in branches, release from trunk”. Sounds weird at the beginning. Have to admit that I didn’t use exactly this process before but my first impression is that it is really structured methodology which:

• gives superb view what actually is currently deployed (via mapping tickets to releases in JIRA)
• allows adding/removing changes easily – we can always take a previous tagged version and apply selected modification by merging
• supports external auditing

In the same time my gut feel tells me that:

• merging before release might be a nightmare (volunteers for a release manager?)
• the process seems to be too regulated, “boxed”, “walled”

It will very much depend on the release schedule and how often the changes will be released which means how often the trunk will be up to date with the latest code. Let’s assume we have biweekly releases. It will mean that at the average a developer will be working with a one week old code. With an application in a maintenance mode with occasional bug fixes which doesn’t change dramatically it would be acceptable but taking as example a new project with many contributors, dependencies between components and a lot of expected changes in design and implementation I think that might be problematic.

It really doesn’t encourage refactoring neither. Just imaging what would happen if two branches taken from the same version of TRUNK were exposed to wider and more intensive refactoring? And for me refactoring is a necessary factor which means continuous and gradual code quality improvement leading to system quality improvement. I know, we should do everything right first time. Why I didn’t think about this before?

Other downside which I can see is that we might completely lose transparency and visibility what is happening with the code. People will commit to “own” branches without a continuous integration. I have to say that I like to monitor changes to current source code via email from continuous integration with last check-in comments. It gives me a way of quickly assessing if the ongoing development is related to my current task, I can merge incoming changes one by one with my changes which means that I don’t do something which someone already has done or something which doesn’t make sense any more.

So, I have mixed feelings. The biggest advantage of the process I can see is easy adding/withdrawing pieces of functionality at short notice. And it (at least in theory, not mentioning the merging hell) fulfils the role very well. The process actually resembles the way how open source communities work. Each contributor branches from trunk and does development on his/her own without breaking anyone else code. When feature is ready then it is (after code review) merged back to trunk or release branch.

It appears that the problem here is caused by subversion not being the best at the merging job. So as we can see a good tool for merging is essential here to make the life easier. It looks like open source guys moved towards GIT and BAZAAR now with GIT getting a lot of traction as it has support for SVN as well.

The process described is not final and would look into refining it to better support given development/release practises. If you have suggestions, comments or you have been using similar process please free to contribute and share.

Popularity: 33% [?]

Share This

Yes, it will happen today! Exactly now, at 8.15am GMT on 10 September scientists at the European Organization for Nuclear Research (CERN) in Geneva, the same place where the lovely web was born, will attempt to circulate a beam in the Large Hadron Collider (LHC) for the first time. It took a while and some money, literally 14 years and 4 billion pounds. When back in 2004 I was working on LASER, the alarm system for LHC, I could see how big, how complex the accelerator is. The software engineering is easy and predictable comparing to such big hardware project however we are doomed to miss deadlines, I am not that bothered that it took couple of years longer to have the first beam that scientists envisaged. Talking about money, that’s the price of research and moving forward as civilization. It certainly will not change an average Joe’s life straight away but it will help scientist to answer some big questions about the universe: why particles have mass, what dark matter may be made of, and why matter survived its brush with antimatter when the universe was young.  Just to remind you that the LHC is the world’s most powerful particle accelerator, and will produce beams seven times more energetic, and around 30 times more intense than any previous machine. There will be official live webcast from Geneva which you can follow.
And no, noone will die and the world will not disappear in any black hole!

Popularity: 16% [?]

Share This

First 10km done, 21km to go.

Last Sunday I took part in a Nike project: The Human Race which was aiming to get million people worldwide to run 10km. Here in London the race started at the Wembley Stadium and the finish line was located on the Olympic Way next to the stadium. I have to honestly say that despite a heavy rain before and during the race it was really good fun! Pretty amazing feeling to take part of such a big run starting at the pitch of famous Wembley and to run along with Paula Radcliffe. Me and my girlfriend managed to finish in 01h 01min 53sec (6.43sec/km - 2.5km, 6.16sec/km - 5km, 5.48sec/km - 7.5km, 5.58sec/km - 10km). London managed to get 2nd fastest average time of all the cities taking part in the race with result 57min 47sec, just 1min 13sec more that Madrid. Well done to everyone! Here are some photos from the day.

I wanted to apologize to everyone who had a wrong impression that I will run a single 31km run for the Starfish charity. I believed I made this clear but probably not. So… I was planning to run Nike race (10km) and then a half marathon (21mk). I am really doing my best! :)

Popularity: 21% [?]

Share This