Early Deployment

I read about early deployment in XP, I believe in early deployment in XP, still I didn't push it and now I am a little stressed out.

This is a project that we have decided to rewrite part of the functionalities, because of the crazy dependencies I mentioned in last several posts (which is, like, half a year ago). We figure, we are just writing new Java files. We are still going to create one jar file for which the deployment and install script will use. So at the beginning of the project (one month after it started), we did a manual deployment as a proof of concept, rather than focusing on making sure that the existing script works well with it, and then forgot about it.

Now it is time to deploy to testing server and making sure that we can do it easily (one click deployment). I started look into the existing deployment script. Then I realize that it makes some assumption and has to be changed to accomendate the changes we have made.

For one thing, the development environment here used to be Unix box with VI editors. So the CVS modules are really small, of less than 20 files. Each module has a build file that will update library (similar to Maven process), compile, archive, and upload the resulting jar (with build number at the end of the file name) into a central AFS directory. This leads to a very messy building process. For example, if module A depends on module B. At a point of time, a-1.4b100.jar is built using b-1.0b22.jar. And now you want to debug why the product does work (for release fix, for example), you will have to check out module A by its tag "ant-v1.4-b100" and check out module B by its tag "ant-v1.0-b22". Try some fix in B, run the build, upload the jar with the newer build number. Then you need to change the build number for b.jar in the build.xml of A so that the right jar file can be pulled during the build. Then run the build of project A.

Still with me? Now imagine module A depends on not only b-1.0b22.jar, but also c-2.5b23.jar, d-1.0b2.jar, e-1.5b2.jar... If that is not bad enough for you, c-2.5b23.jar can be built upon b-1.0b08.jar, in turn. Now what do you think of that?

Now that we want to encourage refactoring and usage of a real Java IDE (which is more than I can say about Eclipse). We introduced several main projects, each one contains the source directories of the existing modules so that we don't need to move files around (mainly because of CVS). However, having observed how bad it can get, we decided to build everything off the head. So we have one project called "unified" which is where the common library classes go, and several other projects depend on it (3 so far). So when we build, say, project document processor, we want the build script to call to unified build file to test and build the library jar first, then use that jar the compile the current project and run the test.

However, changing the deployment process is out of scope for this process, so we still want the current release script to work. But now that we need to upload two jar files (library jar and the project jar) rather than one, the exiting script has to be modified. And you know how tedious it gets writing scripts. So before I know it, it is already the end of iteration.

So, early deployment, get it out of the way, even if you think it is simple.