Since I’ve heard many conflicting definitions on what a software “build” actually is/is not, I figured I’d come up with my own definition to muddy things even more! Someone on Wikipedia has described a software build as “the process of converting source code files into executable code or the result of doing so.” Without parsing words, I think that this is, currently, the generally accepted definition of a build. However, I’d like to expand this definition to include much more than the mere compilation of source code files into something that can be executed. Unfortunately (for many it seems), compilation is often the end of the development line as a developer moves onto his next task. Some people will also “unit test” their code, which means they test a small part of the application functionally (btw, this is NOT a unit test). I think a build is converting source code files into executable code and validating and verifying that it works as expected. What does this mean? To me, it means that a build should consist of compilation coupled with execution of automated developer tests (unit, component, system, and so on), execution of automated inspections (code coverage, cyclomatic complexity, duplication checks, and so on), and packaging/deployment (to a server or other environment). The “compilation” piece may include rebuilding the database and test data to provide a consistent environment from which to execute tests. You’ll often hear people refer to “build and test”. It seems to me this terminology is used because most people still think of a build as nothing more than the compilation (and linking, etc.) piece. I think “builds” should refer to much more than the compile and, in fact, the flimsy use of the word leads many to think they’re done with their development once they click the “Run Build” button in their IDE. What do you think?
May 22nd, 2007 at 2:04 pm
This may be taking it too far. Your builds will take forever if you were to run this every time you want to build it.
May 22nd, 2007 at 3:53 pm
Henry - You may or may not be running these processes with *every* build. For instance, you could run a private integration build on your workstation just prior to committing your code to your version control repository. Furthermore, you can stage the builds to run a fast “commit” build that runs the compilation (and database integration), unit tests and deployment followed by a “secondary” build that performs longer running tests and inspections.
May 24th, 2007 at 1:30 am
i agree wholeheartly and cant wait to get your book into my hands
May 24th, 2007 at 6:53 am
So are you saying that if I use some tool to compile and package my source code into an executable binary, it is not a build if there aren’t any tests?
If you are, then you need to come up with a new word for that process without tests and that doesn’t IMHO make any sense.
May 24th, 2007 at 7:29 am
John - I’m saying a build *can* and *should* include tests — among other things. I don’t want people to get hung up on whether the formal definition of a build is “such and such”. I’m referring to the general discussion we have as developers on our projects. A build *may* include compilation, automated test execution, automated inspections, database integration, deployment and so on. Maybe there should be a new word for it because it seems that when some people refer to continuous integration (which runs the automated “build”), they should just call it what it is on their project: “continuous compilation”. Not a bad thing, but as we know there can be so much more to ensure we are building the right thing in the right way.
May 29th, 2007 at 6:48 pm
We have daily posted builds, which compile and can be packaged successfully. Very often, we end up with builds which are not testable, and are dead in the water shortly after all the installation and configuration steps have been taken. We consider these *bad builds* even though it was *built* sucessfully.
A successful build does not guarantee a testable environment, which is what I think you are really refering to, having something to test.
May 29th, 2007 at 7:16 pm
David - My view is that it’s not a successful build if you can’t test it functionally. I am also saying that things such as internal quality attributes (like maintainability) can also be part of what is considered a successful build. For instance, a team may consider that X% duplication is a failed build. This is because duplicated code can lead to defects and it’s considerably cheaper and less painful to fix problems as they are introduced or even *before* they are introduced. In my opinion, the build is a great central place to discover these issues - Paul
May 30th, 2007 at 3:57 pm
Another way I look at it is expanding the concept of a “defect”. Clearly, there is a defect if code does not compile. We try to introduce the concept that even code which compiles can be considered “defective” if it doesn’t reach certain standards: for instance, coding standards, complexity standards, coverage standards, etc.
By continually raising these standard in the aggregate, we see the overall value of the source code asset (itself) increase…code becomes more flexible and maintainable.
When first introduced, these standards are “extra” gates you have to jump through to get your code accepted. Over time, these standards become the *base level* at which code is judged — as commonplace as compilation.
Continuous improvement in capability enables a team to say: “For us, a ‘build’ is much more than just compilation. It is a verification that our uniquely defined standards were achieved with the existing code base at a specified point in time.”
February 18th, 2008 at 11:30 am
[…] Clearly, in the Java space, Ant is the de-facto build platform; consequently, the future of build languages will most likely need to leverage the extensive infrastructure in place to support Ant– dropping XML is key should you require a more imperative style of building things. Dependency management has always been a splintered solution ranging from Ivy to Maven’s declarative dependency framework to Ruby’s gems– all interesting and viable solutions, which makes his statement all the more interesting. […]