Setting up a build
If you’re reading this you should know about encapsulation, the process of restricting outside knowledge of the inner workings of a component. In large systems this is a fundamental “Good Idea”. In compiled systems it’s simple to encapsulate classes and then have them compiled into more monolithic chunks to make them easier to distribute (DLLs, JARs, EXEs, whatever). Usually your IDE/compiler will take care of this for you.
The core build script
I’d recommend using ANT, (or NANT if you’re using Dot Net). ANT is a flexible, modular, and powerful build program that you can configure to do just about whatever you want. It feels a little strange to write procedural instructions in XML, but once you get over that it’s simple. Using a basic ANT script you can get the latest code from source control, compile it, move it around, rename it, run tests, send an email with the build result to your team, FTP it to your server, or pretty much anything else you can think of.
- Iterate the build number and add it to the code’s config file
- Running unit tests
- Concatenating code and language files into packages
- Running code compression on packages (removing comments, whitespace, etc)
…but you could also include
- Regression testing
- Code duplication analysis
- GZip pre-compression
- Deploying code to specified server
Build script configuration
If you’re writing a build script you probably ought to think about running it in a couple of modes, because you usually have more than one use case for your build.
Firstly you’re going to want a relatively quick dev build that does quick testing and spits out your compiled code to a local development environment. This might also run some analysis depending on your requirements.
Secondly you might want an occasional analysis build that runs code hygene analysis, runs more in-depth tests, that sort of thing.
Lastly, you might want a deployment build, that retrieves only a specific version (latest, codebase version X, or codebase as of date Z) and outputs a zip or tarball of the compiled codebase ready to be archived and/or copied to servers.
If you want to run JSLint over your source, you can do that. If you want to write your own code analysis tool in JS you can do that too.
I’ve tried not to get into too much detail this time. When I get round to it I might write up areas in more detail. Let me know if you’re interested in something particular.