http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660How 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment12http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment12Tue, 25 Aug 2009 10:36:43 GMTcc.net http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment11http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment11Sun, 23 Aug 2009 18:05:23 GMTAyende, What CI system do you use? http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment10http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment10Sun, 23 Aug 2009 17:24:22 GMTPhil, 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment9http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment9Sat, 22 Aug 2009 04:06:52 GMTOren, 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). http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment8http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment8Fri, 21 Aug 2009 21:39:33 GMTHeroku ( [http://heroku.com/](http://heroku.com/)) does this with Ruby and web apps. I've been using it a bit, and I love it. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment7http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment7Fri, 21 Aug 2009 16:16:58 GMTPhil, 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment6http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment6Fri, 21 Aug 2009 15:29:28 GMTIf 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? http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment5http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment5Fri, 21 Aug 2009 15:20:13 GMTAt 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment4http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment4Fri, 21 Aug 2009 15:01:40 GMTRelease 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment3http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment3Fri, 21 Aug 2009 14:20:42 GMTKay, [http://nhprof.com/support](http://nhprof.com/support) http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment2http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment2Fri, 21 Aug 2009 14:17:59 GMTAnd 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. http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment1http://ayende.com/4135/nh-prof-error-handling-continuous-integration-and-rtm-per-commit#comment1Fri, 21 Aug 2009 14:11:40 GMT