Archive for January, 2012

Effective software delivery–Tips for keeping your releases predictable

Sunday, January 29th, 2012

In my last post I illustrated the advantages of short consistent release cycles but in order to achieve this, you often need to build your software in a way that helps ensure that releases cannot be missed.

  1. Support enabling / disabling features without deployment or rollbackHaving atomic feature configuration for new or risky features reduces the need for a rollback, helping safely deploy new or risky changes. This prevents the friction caused when a deployment containing 5 new features fails because of an undiscovered bug being found in a single feature. Rather than rolling back the code, costing you business confidence and a disrupted development flow, instead prefer disabling the feature and taking a story into your current iteration to fix the problem. You’d be doing this anyway, but rather deliver value with the other 4 features while you’re diagnosing the problems.
  2. Use tiny, frequently integrated feature branches to isolate development of features.Any form of long running feature branching should definitely be considered an anti-pattern because any un-integrated changes that diverge from your trunk can potentially cause problems with other features. However, small and short lived feature branches consisting of a day or half a days work on a single atomic feature can help you compose a build of integrated features excluding one that is causing problems in QA.
  3. Stick to MVP: Always cut features, never change your release dateThe temptation to fire fight a broken feature in a release is always strong, but it’s often the core reason of a delayed release. Frequently developers and product managers will want their new shiny feature in the release it was expected and will operate under the belief that “holding the release for an extra day” is the right thing to do. It’s never the right thing to do.By doing this, you prevent any other features in the release from delivering business value on time, and this is always the wrong decision. It’ll hurt, but you should always disable the feature and release, or compose a new build without that feature integrated to keep the steady canter of your release and development cycle.

    If you don’t do this, your next iteration will slip by the time it takes to fix the issue you’re currently facing. Rather, prefer pulling the feature and adding a story to fix it at the top of the next iteration.

    It’s a much more transparent and accountable way of dealing with slippage, otherwise people will expect a larger delivery than is possible come your *next* release, costing you trust.

  4. Deployment as a first class citizen: Automate your deployment and rollbackAs you tighten your development and release cycles, any form of manual deployment will become a chore on your development and operations team, possibly counterbalancing the benefits of a tighter focus on releasing. You should always treat deployment and installation as a first class citizen. All your software, from day one, should support continuous integration and automated deployment. If you configure software with these characteristics when it’s new and inert you can prevent any large arduous tasks configuring it later.
  5. Configure old and new behaviour side by sideIf you’re touching particularly sensitive or high traffic portions of your software, ensure you can switch the behaviour between the two implementations trivially and without rollback. Remove the configuration when the new code is “trusted” to prevent costly rollbacks and patches.
  6. De-scope existing bugs in order to shipIf an existing bug is threatening your release, de-scope the bug fix to the next release or hotfix it later. Always ship if you’re adding value rather than wait for unconfirmed fixes.

Always prefer de-risking releases for the sake of consistency, it’s a more honest way to deliver software on time.

Effective software delivery–Short, consistent release cycles

Sunday, January 29th, 2012

One of the greatest challenges facing any software company is the risk associated with new releases. As a responsible software development team, you should put just as much emphasis on delivery of the software as you do on development.

The most direct and deliberate way to mitigate the risks associated with software delivery is to stick to the mantra of “Release early, release often”. The surest way to accomplish this is to repeatedly build *and* deploy the minimum viable product and the smallest possible change. Doing this mitigates risk by reducing the impact of a rollback to “just a single feature”.

The reason that this is so important is that it allows you to stick to short and simple release dates, which encourages and enforces predictability into your software development. Your release cycles should be small and take place at the smallest sensible interval on a sliding scale between “as soon as the feature is QA’d” (which represents the least possible risk and the smallest possible change) to “as soon as the current iteration or sprint is complete” (which is often a fair compromise allowing a more coherent shipped change).

Ensuring that your releases happen on simple and consistent dates (for example “Every Tuesday”, “Every day at 7pm”, “Every time QA signs off a feature”) maximises transparency for the rest of your organisation and helps build trust in too-often-opaque software development departments. In addition to transparency you will also gain a tight appreciation for scripting your release processes and increasing your comfort in your deployments due to the increased and and consistent nature of installing software. This focus will quickly surface any points of friction in your software release process that need improvement.

iTunes Persistent Id Cloner – Sync one iPhone / iPod with many computers

Wednesday, January 25th, 2012

I frequently have trouble trying to copy music onto my iPod due to iTunes’s draconian binding and synchronising rules. These rules exist to ensure that only “authorised” files can be copied onto any given device. Apple implement this by binding your device to a specific instance of iTunes using a randomly generated Persistent Id that’s registered on your computer and on your device.

I have 3 computers that I use regularly, and I regularly rip CDs in different places and want to put that music on my iPod for travelling imminently. By default, iTunes restricts me from being able to do this.

Tonight I hacked together a little command line app to clone your persistent Id’s across multiple machines.

In order to use it, you need a copy of iTunes bound to your device installed on a machine. Once you have that, you run the program in –extract mode, which will show you the persistent Id for that machine. You can then use the program on other computers to patch any installed iTunes libraries to believe that they have the same persistent Id as the “master” machine. It’s a pretty trivial process.

If it breaks anything, don’t come crying, but “works on my machines”. Happy listening.

Source code / detailed instructions: https://github.com/davidwhitney/itunes-persistent-id-cloner
Executable: https://github.com/downloads/davidwhitney/itunes-persistent-id-cloner/4f7dd551998d515108d937d5b39f28a7b2a058ff.zip

The iTunes Persistent Id Cloner!

Small command line app to:

1) Extract the persistent Id from an iTunes library (this is the thing that your device is bound to)
2) Patch up an iTunes library with a persistent Id you supply (I bet you can see where this is going).

Usage:

Compile.

1) Quit iTunes on machine that you want to be considered your "master" persistent Id.
    I'd suggest the one you've already got your iPod / iPhone registered on.

2) Run itunes-persistent-id-cloner.exe -extract
    Write down the Persistent Id it gives you.

3) Install a fresh copy of iTunes on another machine
    Run it once, and quit iTunes.

3) Run itunes-persistent-id-cloner.exe -patch on another machine
    When prompted, enter the persistent Id supplied by the other Id.
    Ensure iTunes isn't running.
    Hit enter.

No friendly error messages or error handling at the moment.
Don't make typos, things might crash. Worse case, you can run / patch a second time.