Well I really mean a build of the application I current work on. This is to say I am not talking about the actual construction of the application, but the putting together of the bits.

As it stands right now I have developed the process to deliver 4.0.0.??? to the client. This number and package will represent an incremental update to the code delivered before it. That works great until a client wants a cumulative patch. What if you wanted everything from us up until November? Well I would have about 500 patches to give you. My thought is that possibly this response could be improved upon!

So it isn’t entirely what I was thinking about while detailing my truck or indexing (throwing stuff away) my garage. I came into my house to find my loving family taking a nap and decided to read this: http://weblogs.asp.net/scottgu/archive/2005/04/17/402281.aspx

So at BIG I think we should also go to a build and revision system that is slightly more complex than the current version. What will this give us? Well we can talk about things like “I am working off build X” or “ I have installed the latest patch to build Y”.

The only addition I have to the article is that perhaps a fully qualified name is needed for the patches or builds. I would suggest something like YYYYMMDD.major.minor.revision.zip. This is what I use for things like http://www.kidbabble.com (thanks Shawn W.) or my family site. I use it for everything archiving in fact. It just works.

So to give something concrete that makes this entry stand on its own I have this: Lets add an actual build system to the patch process and give it a name that makes sense. We can then use this to build client machines and diagnose problems. We can more coherently address problems with a build or it dependencies and deliver a product somewhere in the middle of a cycle (we aren’t talking SDLC here so I wont go into it) in a way that make a little more sense to a client with IT knowledge.

No Comments
Uncategorized