Thursday, March 30, 2006
The building process
Few years ago, I read an article of Joel on Software about daily builds. In that time, it was Greek to me, when I thought building a program was only picking "Project - Build" option inside my IDE.
However, after few years, I realize that "compiling a programing" has nothing to do with "building a product", although both should be done with only one step.
Compiling a program means only convert source code into binary executable code, and that's a repetitive and mechanical work (although quite complex) solved by compiler. That's why it was invented isn't it?
Even though, building a product involve much more. For example, in our situation, in order to build The Fourth Seal, we have following tasks:
In other side we have Battlewizard building, with its own steps, quite different, mainly because Battlewizard has a desktop application with its installer, executable file, etc.
Perhaps we forgot something, but it's just a sample and we get used to the idea of it.
All these steps we described form product building process, however, we need something more: it should be automatic. Yes, the most important thing about it is building process must be:
Another benefit: building completely and periodically our product, we can detect wrong code very early. Let's assume one of our libraries hasn't been modified for months, and when we're going to compile it and run its unit tests, it fails. If we would compile and test that library every day or week (together with the rest of the product), that error would be detected earlier, a few hours or days after someone introduced it, and it would be easier and faster to fix it.
And finally, making automatic building, we'll allow everybody, even new team members, will be able to generate all product components. Building process will be responsible to get file from somewhere, doing necesary copies, modify whatever libraries and so on, but user only makes a simple step.
Well, tomorrow we'll talk about famouse "continuous integration" recommended for agile methodologies like eXtreme Programming.
Meanwhile, you go further in this subject reading these recommended issues:
However, after few years, I realize that "compiling a programing" has nothing to do with "building a product", although both should be done with only one step.
Compiling a program means only convert source code into binary executable code, and that's a repetitive and mechanical work (although quite complex) solved by compiler. That's why it was invented isn't it?
Even though, building a product involve much more. For example, in our situation, in order to build The Fourth Seal, we have following tasks:
- Compile the Battlewizard abstract engine.
- Compile specific implementation for desired handset: MIDP 2.0, nokia and so on. (By the way: I owe you one explanation about Battlewizard and its architecture :)
- Increment current version and create manifest file
- Pack everything inside a JAR file.
- Compile game source code, using specific resources (images, sound effects, text strings, etc) for desired device and language.
- Launch unit tests for all our code base (using JUnit and J2MEUnit)
- Obfuscate everything (using ProGuard or RetroGuard, depending on current situation)
- Optimize and compress resulting bytecode (with specified libraries)
- Create JAD file with JAR file size, MIDlet name, and so on.
In other side we have Battlewizard building, with its own steps, quite different, mainly because Battlewizard has a desktop application with its installer, executable file, etc.
Perhaps we forgot something, but it's just a sample and we get used to the idea of it.
All these steps we described form product building process, however, we need something more: it should be automatic. Yes, the most important thing about it is building process must be:
- automatic, without human intervention, or at least with minimum intervention (you can ask for data to the user, like asking if version should be demo or release, for example)
- as simple and easy as a single click (ok, we'll admit running a console command or even a double click :)
- complete (it's invalid recompile only certain libraries or use incremental compilation)
- and whenever possible: daily, launched every nigh (don't you know famous nightly builds?) or at least run in a periodical way.
Another benefit: building completely and periodically our product, we can detect wrong code very early. Let's assume one of our libraries hasn't been modified for months, and when we're going to compile it and run its unit tests, it fails. If we would compile and test that library every day or week (together with the rest of the product), that error would be detected earlier, a few hours or days after someone introduced it, and it would be easier and faster to fix it.
And finally, making automatic building, we'll allow everybody, even new team members, will be able to generate all product components. Building process will be responsible to get file from somewhere, doing necesary copies, modify whatever libraries and so on, but user only makes a simple step.
Well, tomorrow we'll talk about famouse "continuous integration" recommended for agile methodologies like eXtreme Programming.
Meanwhile, you go further in this subject reading these recommended issues:
- Daily Builds Are Your Friend from Joel on Software, where I began to discover the building world.
- Daily Build and Smoke Test from Steve McConnell. He talks about the approach used in Microsoft for daily builds and QA process.
posted by JM : 1:03 pm
