Currently we concatenate and minify our individual JavaScript files into one bundle locally – using Chirpy – and then check the bundle into version control (we are using TFS with Gated checkins).
Our installer then deploys this bundle.
But this is causing a number of problems:
- is it possible to check in a bundle which does not correspond to the source files.
- we have merge problems with our ‘Gated Checkin’. Because if two changesets in the checkin queue both contain a new bundle, the second will always conflict with the first.
We have a couple of other ideas: the installer could generate the bundles during deployment, or the server could generate the bundles at runtime as a startup process.
But surely this is a common problem, what is best practice?
“Best practice” is a scary phrase, because people will often wield it as a club to defend their own personal preferences.
Both solutions are good, and better than the current system. Which one is best depends on context:
The installer could generate the bundles during deployment:
This has the benefit that the deployed JavaScript bundle is guaranteed to be consistent and constant, and can be tested in isolation without firing up the entire system. In general, I would recommend this solution.
The server could generate the bundles at runtime as a startup process:
This has the benefit that JavaScript code can be replaced or tweaked directly on the deployed system without going through the build step. This allows you to fix bugs or improve things very rapidly. The downside is that this kind of activity results in a live system that is not in lockstep with the repository, which makes debugging and upgrading painful and error-prone. I personally think it is scary to allow for that.