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: 42% [?]

Share This

I came across a strange behaviour of Selenium and wanted to share my pain with someone really. But first couple of words of introduction. I use Selenium in my current webapp project which I am working on. The application uses quite a lot of javascript (Dojo framework mostly) which can be tested using D.O.H. framework but the Selenium is giving us the final sanity checks, acts as integration test framework and may be used by product owner in an agile environment to drive acceptance on user stories via automated acceptance tests.

Selenium is an excellent package. I really love it. Just to mention integration with various browsers, Selenium IDE, support for integration with build (Selenese ant task) and really easy way of creating and storing the tests as HTML. It is a framework which cannot be ignored by anyone working on webinterfaces.

There is previously mentioned selenese ant task which helps with integration of the Selenium tests and an ant build. You can grab the jar from the Selenium RC distribution.

However as most of the things around us it is not a perfect software. Anyone had the famous “Permission denied to get property Location.href”? Cross domain scripting issues?
In my case I figure out two reasons for above problem and I wanted to share it:

Problem 1:

Let’s look at the following selenium command:

• open
• http://host/some/url

Looks good, doesn’t it? So it might work, but it can as well break on another box with the “Permission denied to get property” and some other scary warnings. The solution in this case was simply to remove the host definition from url leaving just:

• open
• /some/url

Problem 2:

One of the pages I was testing had redirection in case of the authorization violation. So esentially after single HTTP request the browser was receiving single response with redirection and then performed another request to the URL defined in the redirection. Selenium couldn’t handle that correctly. But again, it wasn’t deterministic, it could work on one box but fail on another. Timing issues etc. Hate that. Neither of the combinations worked in consistent way: openAndWait, open + pause.

The solution in this case required change in the webapp to remove usage of the redirection (which I believe was an ugly way of dealing with the problem anyway).

Hope it will help someone with similar issues. If you know another tricks or something to avoid when using Selenium please contact me or leave a comment here.

Popularity: 94% [?]

Share This

I believe in testing, I really do. Combined with continuous integration, daily builds and automation of all aspects of build process, those are for me mandatory elements of a software project which has got any aspiration to be a successful one. Joel thinks there are more.

I believe in unit tests as well as integration and acceptance tests. I can see value of that and I use TDD happily for last two years and unit testing without being so strict about that for much longer time. It just works for me, gives me something.

However I still have questions regarding this subject. Let’s just put up first of them:

Should we or shouldn’t we unit test private methods of a class?

There are valid reasons for both of them. From one hand if we limit ourselves to a public interface and we test our class as a black box which behaves in a certain way and we don’t care how it is implemented then the tests are easier (read cheaper) to maintain. Whenever we have to change implementation we don’t have to change tests. Neat.

But there is other side as well. What about this word unit? What about TDD? If TDD can actively help us with process of developing a single unit of code why not to use that? As we all know the first red - last green routine of writing test, making it fail, developing code, making the test pass might be painful, might take long time to switch to that way of development but and the end of the day gives code of the better quality. But now what shall we do if that single unit of code by design is a private method? Shall we change that following philosophy of design for testability? It again might lead to innocent changes like converting (Java):

private void foo() {
...
}


to:

protected void foo() {
...
}

Then we can create unit tests for that method in the same package. It was really innocent. What if we have to reach to a toolbox with dirty tools? We can’t really use the same solution for C#. Let’s first have a look at the method access modifiers for that language:

• public indicates the method is freely accessible inside and outside of the class in which it is defined
• internal means the method is only accessible to types defined in the same assembly
• protected means the method is accessible in the type in which it is defined, and in derived types of that type. This is used to give derived classes access to the methods in their base class
• protected internal means the method is accessible to types defined in the same assembly or to types in a derived assembly
• private methods are only accessible in the class in which they are defined.

As we can see our dear friends from Microsoft have done it in even more problematic way. We have a choice of converting private methods to internal but our tests have to be placed in the same assembly as the production code or we can use the public modifier or we have to use some tricks with reflection. Not perfect, wrong or smells.

I understand that there is no universal answer for the question above. Applying common sense usually pays off but I wonder what is your opinion about testing in general with focus on testing private methods.

Popularity: 23% [?]

Share This