+972 52-548-6969
NH Prof, Error Handling, Continuous Integration and RTM per commit
One of the nice things about NH Prof is the way that it is setup from an infrastructure stand point. Take a look at the following email:
I got this email, along with an additional one containing the actual crash information (this email is generated from the user’s input about the reason for NH Prof crashing).
This isn’t the first time that I get this bug (it is an annoying threading issue) but this time I was able to finally pinpoint the exact place where this is happening, trace it back to where it is used and get to the slap-fore-head-OMG-I-am-stupid moment.
Then it was adding a few locks, refactoring to make it clean, and commit.
At this point, my work is done. We have a CI infrastructure that will compile everything, run the tests and push it out as a released build.
With NH Prof, we take the stance that every single commit is a release. Sometimes we will do some work on branches, but most of the work is done on the trunk, and any commit to the trunk result in a new released build.
Out of close to 400 builds that we have so far, I believe that we had about 5 – 10 lemons (builds that fail on user’s machines). In all cases, it was fixed within a few hours.
The implications for me are huge. I don’t have to worry about managing things. I set it up once (sometimes in December or November, if I recall correctly) and stopped worrying about releasing stuff.
And it means that I can literally fix a bug, commit and tell the user that they can pick up the changes as soon as it is done.
Comments
And that's the way CI should be done!
BTW what's the best way to get into contact for some NHProf issues? I have troubles getting it to run in my Mac Fusion virtual WinXP.
Kay,
http://nhprof.com/support
Release on every build, even if only to a subset of users for whatever reason, is such a boost for a product team.
The whole team (including the customer) feels the progress intimately and its much easier and quicker to gather feedback. Seeing the product delivered almost generates momentum of productivity.
At Lokad.com, we are basically doing the same EXCEPT that the build get published only when forced, not just triggered by a commit. In our experience, continuous release is too extreme, because as our users get actually notified that a new release is available (through some auto-upgrade feature), we don't want to drive them mad with a new release every day.
If you had a QA department (not sure if you do or not), how would they get a build to test? Off of the branch commit?
I think this is awesome conceptually, but would it work for a commercial software product, with large enhancements being made and several different people working on interrelated functionality?
Phil,
How do you think we are working on NH Prof?
There are several people working on this, and we tend to add features quite often.
Heroku ( http://heroku.com/) does this with Ruby and web apps. I've been using it a bit, and I love it.
Oren,
I guess I don't see what happens when one person is done with their part, and another isn't finished yet. Do they have to wait to check in until everyone is ready?
Also, what if a new feature takes six weeks to complete, do you not check in for six weeks? Or do you control this with unit tests (i.e. unit tests failing indicate the release isn't complete)?
To be clear, I'm not suggesting it's not a good practice. I just can't reconcile this methodology with the projects I work on, with a QA department that gets builds before they are officially released, and multiple developers working on interrelated tasks (like the UI code AND database code need to be completed in parallel).
Phil,
We rarely work in horizontal slices. Usually we will work in vertical ones. That means that we very rarely have a situation where one is waiting for another.
If we do, we handle it like all dependencies, the dependent task isn't started (or started in a branch with a mock back end).
New features that takes a long time to deliver are usually done on the trunk, with the feature being disable for release. In some cases we did major work on a branch.
If I had a QA department that needed to vet my releases, I would have each commit generate a build, and the QA would grab one , test it, certify it, at which point it would become really public.
Ayende,
What CI system do you use?
cc.net
How does the upgrade process works? From the customer perspective. Do I (as a customer) need to install a new version everyday? I think this is important for the user experience.
Comment preview