Yesterday, we finished Iteration 7 of our Panacea development plan. And, true to our agile ideals, we elected early on in the project to embrace “frequent releases”.
Here’s how we work. Each iteration of the project is a one-month period (we’ve had two iterations take a bit longer). Each iteration is composed of two 2-week development cycles. At the end of an iteration, we cut a release of the application. Yesterday, we published version 1.7 of the Panacea application. Our plan is that fully-released versions get published to our production server — but to date, we haven’t used the production server for anything but demos so the official releases haven’t been hugely important.
Our internal Panacea “test” server, on the other hand, is currently supporting the HL7 development for a beta test customer. It’s currently getting a lot of use, with thousands of HL7 messages processed. And we deploy a new build of the application to that server every day.
So, last night, our first nightly SNAPSHOT of version 1.8 deployed out to the Panacea test server. Early in the life of the application, we built in a feature of the code that displays the current version of the application at all times. Down near the bottom of each Panacea page, you’ll see a version number like this:
This version number is used in a lot of ways — it gets sent along with any internal error reports, for example. But mostly, it’s nice to be able to get a clear indication of when the code on the server was last built.
One of the agile ideals is informed by the idea that you get the best feedback from clients once they’ve had the ability to touch and play with the app. Certainly, since new features roll out to our beta clients nightly, we’ve benefited from really short feedback cycles. This is one of those things that agile teams dream about, but which we often don’t achieve — often because client organizations can’t handle the implications of many frequent releases. But as Panacea developers, we’re likin’ it.