Even worse is that there are any number of less extreme but equally harmful things that can happen without warning. While those incidents may be at the very extreme end of the spectrum they can happen. Just as unfortunately, it also appears that nothing changes until a major incident occurs - you ship code to your most important customer that is a “ Frankenstein’s monster” amalgam of code from various earlier and future releases that completely kills all productivity at that client for an extended period of time or your network is hit by a pervasive and devastating virus that formats all of the hard-drives of the infected computer. Unfortunately, as Jeff points out, the idea of a build script that is outside of the IDE is not only alien to most development teams but it’s downright unthinkable. What that means is that when you are ready to release code outside of the development group, whether its to the QA group, some other internal group, or even an outside customer, if you still follow those same 3 steps you have a problem. The problem occurs when this is your only build process. Even in large development teams, the individual developers will still follow this process in their day-to-day work. While I agree with the reasoning, I think it’s applied at the wrong level. The very idea of a build script outside the IDE is alien to most of these teams. If you think this sounds ridiculous– who would possibly use their IDE as a substitute for a proper build process? – then I humbly suggest that you haven’t worked much in the mainstream corporate development world. If your “build process” is the F5 key, you have a problem.
0 kommentar(er)
