Iteration 0

I started a new project at a client site this week.  I spent the first couple days on Iteration 0 tasks.  These are things you need in place before you can actually get to work.  Here are a few things we needed done.

Source Control

You absolutely must have some sort of source control.  My client happens to be a team of 1, so he wasn’t using any source control.  We set up a subversion repository and the necessary folder structure for the current projects we are working on.

Build Scripts

I absolutely hate writing build scripts, but I love executing them.  This is just one of those things you’ve got to suck up and do right at the beginning.  You will be executing several times every day when you are working on stories and tasks, so take some time to get them right.  For this project, the build scripts were not too complicated. They simply compile the projects and run the unit tests.  Normally I would drop and recreate any database that would be used too.  In this case, we’re accessing an existing database, but we are not working on that part yet, so I left it out for now.

Continuous Integration

We also set up the CI server.  While I really want to try out TeamCity (I tried once with no luck), I stuck with  CCNet can be difficult to get right the first time, but again once you get it you can usually forget about it.

We also did some story writing too.  I don’t consider this an Iteration 0 tasks, but is obviously important to have some stories and scenarios ready to go.

What are some of the the Iteration 0 tasks you do before starting a project?

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Your 3 are my usual. Infrastructure is the other one. I ensure that the servers, PCs and network is in place. If it can’t be done I make it a release task that has to monitored closely.

    We just got done introducing 3 new technologies into our iteration A this release. Some teams introduce new technologies in Iteration 0 by refactoring current items to use the new technology. One example, is to put dependency injection via Windsor or StructureMap in place. It still follows the definition of refactoring because the client/end user doesn’t notice a difference.

    Excellent post John.

  • To expand on Jason’s comment and your CI task, I find it to super helpful to include Deployment in your CI. Nightly builds are a good first step, but do it as part of your CI builds and you’ll have flawless upgrades/installs in the future.

    I personally also like to give my clients access to run the CI builds. There is no better way to close the feedback loop.

  • jcteague

    I personally do not put my deployments in my CI, but I’ve been on projects that do and it is nice. But they certainly ar automated.

    Right now, my project releases to QA every week (at the end of each iteration) and i do that with a simple bat file to run the necessary nant targets.

    The reason why I don’t put them in my CI is that I now have a deployment for each of my revisions, and on a big project that could be several a day. I feel that it is too granular.

    I worked with the guys on the Tarrantino project, and they built a deployer that is based upon the svn revision. And I hold the same opinion about that approach. SVN revision numbers are too granular. I prefer tagging my QA deployments and having a limited set of rollback points. Nightly builds I could see, but haven’t automated yet.

    Thanks for the feedback