What I mean however is a build which does not require an IDE and is not invoked by the IDE, so is thus probably ant though it could potentially be maven, or a shell script or an msbuild invocation - you can do headless builds with something other than ant.
To my mind having a headless build is a no brainer, but you'd be surprised how many development contexts do not have this. So why is a headless build so important and why do some context not have one?
1. Headless builds do not require the IDE
Why is this important? It's probably more an architectural/soft advantage. I mean why would you spend time replicating offline what you can do in an IDE. The primary advantage here is that it means that it allows a whole slew of other tweaks, so this is not valuable in and of itself but it is what allows other advantages.
2. Headless builds are repeatable - this is the no brainer reason why you want headless build - so that you can have repeatable builds. The problem with building from the IDE is that you never actually know what code the developer had in his workspace when he made the build. If you don't know what code is in a build you don't know where to go to fix the problems. Maybe the problem stems from that random code the developer was working on when he made the build. I would go so far as to say that a build made from a developers workstation is about as much use as old chewing gum.
3. Headless builds do not require a developer - the last thing I want as a developer is to be keep getting queries saying, please come and do a build for us. I don't think the downstream entities (testers, deployment people) want to do this, but in a context with no headless build they are forced into doing this. What is more is these people cannot do more than click a "build" link to make a build. They certainly cannot start the IDE, check the code out, select the project, select build all, then do an export etc. They certainly, since they are not developers, cannot use an IDE to make their own build.
4. Headless builds are automated - once you have headless build infrastructure in place, be it ant, msbuild or shell scripting, you can build on that basis by adding things like tagging of the code, tagging of the generated artifact. Maybe even include in the built artifact some mechanism to show the tester the version tag. No uncertainty as far as which version of the code you're running.
You might be saying, surely in some cases, in some small cases that it is not necessary to do the work of creating a headless build mechanism. I'm not so sure. Yes, developers could be disciplined and make sure whenever they build that the code has no changes, but even with that, it is still not clear what version of the code is deployed. On a recent project we did not have a headless build and there was always a degree of uncertainty as to what version of the code was deployed, what version of the code is running. I regret not being allocated enough time to implement a headless build for that context. It caused us pain, even if the project was really small. If it is automated by a script it will happen _every_ time and it can be trusted. I cannot trust a developer to always follow the steps they're supposed to - not because they're not trustworthy, but because the developer cannot prove to me after the fact that they did all the steps they were supposed to.
3. Headless builds do not require a developer - the last thing I want as a developer is to be keep getting queries saying, please come and do a build for us. I don't think the downstream entities (testers, deployment people) want to do this, but in a context with no headless build they are forced into doing this. What is more is these people cannot do more than click a "build" link to make a build. They certainly cannot start the IDE, check the code out, select the project, select build all, then do an export etc. They certainly, since they are not developers, cannot use an IDE to make their own build.
4. Headless builds are automated - once you have headless build infrastructure in place, be it ant, msbuild or shell scripting, you can build on that basis by adding things like tagging of the code, tagging of the generated artifact. Maybe even include in the built artifact some mechanism to show the tester the version tag. No uncertainty as far as which version of the code you're running.
You might be saying, surely in some cases, in some small cases that it is not necessary to do the work of creating a headless build mechanism. I'm not so sure. Yes, developers could be disciplined and make sure whenever they build that the code has no changes, but even with that, it is still not clear what version of the code is deployed. On a recent project we did not have a headless build and there was always a degree of uncertainty as to what version of the code was deployed, what version of the code is running. I regret not being allocated enough time to implement a headless build for that context. It caused us pain, even if the project was really small. If it is automated by a script it will happen _every_ time and it can be trusted. I cannot trust a developer to always follow the steps they're supposed to - not because they're not trustworthy, but because the developer cannot prove to me after the fact that they did all the steps they were supposed to.
No comments:
Post a Comment