1

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?

GarethOwen
  • 6,075
  • 5
  • 39
  • 56
  • I don't see the need to checkin the bundle into the svn or at least accompanied with the source code. and why do u need to checkin a bundle that doesn't correspond to source code. won't it make more sense tag the bundle into the svn? – Moataz Elmasry Sep 19 '12 at 13:28
  • @MoatazElmasry - correct, checking the bundles into source control is causing problems and that is why we need another solution. – GarethOwen Sep 19 '12 at 13:38
  • how about a nightly build. the build script will create from the svn a bundle and upload it to a web server, but not check it in into a web server to download. you can tag a bundle once a week/month or something – Moataz Elmasry Sep 19 '12 at 14:31

1 Answers1

1

"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.

Deestan
  • 16,738
  • 4
  • 32
  • 48
  • 1
    Thanks for the advice. I like your take on "Best practice", sadly I think I used the phase this morning with a colleague to defend something that I couldn't explain clearly. – GarethOwen Sep 19 '12 at 13:51