Monthly Archives: September 2014

Simple alternatives to feature branching – #1 Build alongside

With Continuous Delivery (CD) every commit is a potential release candidate and all pushes are to a single central trunk. For people new to CD it an be very hard to reconcile frequent commits with this concept; How can I commit twice a day when this feature is going to take several days to be in a state that I want it to be public?

A good example we had of this recently was a full reworking the registration pages for the https://www.your-loop.com energy monitoring website.The registration process requires the installation of hardware to do meter readings, ensuring that radio communications are working and serial numbers etc. have to be entered and the flow can vary depending on the type of meter a user has. The rework involved changes of page flow and content. The nature of the changes meant we didn’t see a clear way to break it down into smaller sizes that made sense to the user. It was also clear this is not something that could be completed in a single commit.

Why commit to trunk?

The key things we are trying to ensure by committing frequently to trunk are;

– New automated acceptance tests are developed as we go and run on the new feature in every CI build .

– Existing acceptance tests continue to run on the existing code in every CI build.

– Ease of manual testing so the changes can be viewed (without redeployment to switch for example) .

– Continuous integration and merging into all developers work .

Feature branching – just say no.

Its common for people to revert to what they know when presented with a challenge and some of the team were immediately reverting to suggesting a feature branch. The problem with this of course is that feature branches make all of the above desired objectives difficult, expensive or simply impossible. Every time you feature branch, a release fairy dies,  just say no!

Feature Toggles were not ideal.

One option discussed was to use a feature toggle. The problem with toggles is how to toggle them on and off. Feature toggles often take the form of a singleton property, perhaps in a configuration file or dependency injection that switches between different implementations at build time. The problem with this approach is test isolation, I want all my regression tests to run whether the feature is currently on or off, and this is an awkward thing to do in your CI environment unless you run tests sequentially, even then it requires duplicated toggles in test code that you must keep in synch.

There are other approaches to feature toggling that can happen at runtime which I will talk about in another post but this wouldn’t have been much help here as we needed a global new/old switch.

Build alongside

The approach we used is to “build alongside” by building the new registration pages with a different URL which is not linked to from the site;

So if the existing registration page entry point is;

http://www.example.com/registraion

We build

http://www.example.com/newregistration

Whilst the new feature is being developed all buttons/links etc. point to the existing registration pages entry point. We can write selenium tests that drive the new registration pages and leave all of the existing tests in place. QA and the product owner can access the new pages without any configuration (by simply going direct to the URL), but they are sufficiently hidden from the public to not get seen. In practice we called it a slightly more obscure name and there was really no risk beyond seeing a “work in progress” should a customer have guessed the URL which was unlikely.

Once all are happy with the new pages the new URL is renamed to the existing one and the old code is deleted.

It’s a simple approach that everyone understood and met all of the desired objectives regarding frequent commits, CI, manual testing and frequent merging with everyone’s code.

Tagged , ,

The thinkfoo test for Continuous Delivery – What does good look like?

Dave Farley makes an excellent point in his recent post that many people in our industry have never worked on an efficient project team and wouldn’t know good if they saw it. Indeed many are probably blissfully unaware of just how inefficient they are comforted in the knowledge that they seem to be no worse than anyone else. So how do you know if you are good?

Some fourteen years ago Joel Spolsky wrote an often quoted piece he called the Joel Test.

This was great stuff back in 2000 but we have moved on a long way since then and I propose an updated test that reflects modern development practices founded in the principles of Continuous Delivery (CD).

I’ve worked with some incredibly productive teams (and some not so productive ones) I prefer to work with productive ones and I have over the years formed some strong opinions of exactly what good looks like. I realised I have been informally using a set of criteria to evaluate teams for some time and thought I’d write it down and share it.

So here is my “thinkfoo test”; efficient development teams will be able to answer yes to most if not all of these questions, if your team can’t and you think you have an efficient team with a good process maybe its time to take the red pill and think again?

1. Do your developers push changes to a single trunk branch at least twice a day?

2. Do you practice ATDD and write automated acceptance tests for every feature?

3. Do you practice TDD?

4. Do you run your full set of acceptance tests, unit tests and performance tests on every commit to trunk?

5. Do you have automated single step repeatable builds and deployments?

6. Does your team release to production at least every two weeks?

7. Do you practice pairing as the normal way of working?

8. Do your teams self organise?

9. Is your team in a noisy collaborative environment?

10. Do you have cross functional teams of BA’s, developers, QA and operations responsible for end to end delivery of working software?

11. Do you have a single product backlog (with bug’s and features together)?

12. Do you use minimal stories as specifications rather than detailed up front designs?

13. Do you have regular retrospectives to continually improve your process?

Lets look at each of these in a little more detail

1. Do your developers push changes to a single trunk branch at least twice a day?

  • feature branching is evil, long lived feature branches doubly so. Trunk development is, for good reason, a key requirement for CD.
  • trunk should be in an always releasable state, every commit should be a release candidate.
  • To be continuous your integration must be frequent; committing to mainline twice a day should be considered a minimum.

2. Do you practice ATDD and write automated acceptance tests for every feature?

  • these should be built in advance and alongside the feature and treated as the source of truth or living specification. The feature isn’t done until all the acceptance tests pass. By doing this and keeping work in progress to a minimum the need for bug tracking is diminished.

3. Do you practice TDD?

  • many people are confused about what level to set their tests at that’s why I specifically want to know if you have both ATDD (are you building the right thing) and TDD (are you building it right).
  • The “red, green, refactor” cycle is critical to producing good clean code
  • Your whole team needs to practice TDD, I wince every time a development lead says “We don’t enforce it but sure you can work that way if you want”.

4. Do you run your full set of acceptance tests, unit tests and performance tests on every commit to trunk?

  • #1 is a prerequisite of this if you are not using a single trunk your continuous integration isn’t, end of.
  • performance tests are a critical part of your build pipeline many products fall under the pressure of their own success.

5. Do you have automated single step repeatable builds and deployments?

  • if you can’t do repeatable automated deployments there’s not much point in doing #1 through #4 as you won’t know that what you deployed is what you tested.

6. Does your team release to production at least every two weeks?

  • if you do iteration after iteration without release I don’t really buy that you are agile, this is usually a waterfall project dressed in agile clothing.

7. Do you practice pairing as the normal way of working?

  • see my post on pairing for my views on why this is essential to building quality software assets.

8. Do your teams self organise?

  • teams that do top down allocation of tasks in my experience always end up optimising resource usage over feature delivery, it discourages collaboration, common code ownership and pair rotation don’t do it!

9. Is your team in a noisy collaborative environment?

  • the opposite of Joel here I agree with uncle bobs views of headphone clad developers with their backs to each other, no single developer can be productive enough to jeopardise whole team productivity don’t allow it and don’t hire people who insist on working this way. Great software is built by teams not individuals beware the hero developer!

10. Do you have cross functional teams of BA’s, developers, QA and operations responsible for end to end delivery of working software?

  • and the roles should be blurred rather than designated, BA’s should write some tests, QA’s should write some code, developers should write deployment scripts and talk to customers, ops guys should be coding etc etc.
  • Your developers should be on first line support for your production systems.

11. Do you have a single product backlog (with bug’s and features together)?

  • do the most important thing first and optimise for flow of delivery over resource utilisation (see managing your backlog for more on this)

12. Do you use minimal stories as specifications rather than detailed up front designs?

  • stories are about enabling conversation not detailed specification see https://leanpub.com/50quickideas for some great thoughts on user stories.
  • Joel believes in detailed up front specifications sorry but he is just wrong on this, in any project lasting more than half an hour the specification will change, living specifications in the form of automated acceptance tests are the only way to keep specs current.

13. Do you have regular retrospectives to continually improve your process?

  • nothing is perfect; core to the principles of Continuous Delivery is continuous improvement retrospectives are an essential part of that learning and improving.
Tagged ,
%d bloggers like this: