I'm a strong believer that when developing an application, your main source tree should contain everything that is required to build and run the application. Getting up and running should be as simple as getting the latest version of the code from the repository, running a build and that should be it.
Yes, i am aware of the pragmatism of real world always means there are exceptions.. but i still believe this should be the ideal.
In order to achieve this ability, most projects I've been involved in use the concept of a tools or lib folder at the root of your source tree. These folders contain external dependencies needed by your project in order to build/test/deploy the application.
For example:
projectname
|---trunk
|------- db
|------- docs
|------- src
|------- tools
|----------- nant
|----------- nunit
|----------- nmock2
This works great...except when you have to use Microsoft related technology tool.
95% of Microsoft tools I've attempted to use still have a dependency on an MSI needing to magically install something somewhere to make it work. Which, pardon my french, is crap.
For example... I had a small requirement that the ASP.NET AJAX framework appeared to solve quit nicely. Seemed as simple as adding one line to an aspx page would have done the trick. Plus its an AJAX framework, should be simple to add to the tools folder, add a reference, build and deploy it out.
Nope.
First you have to run an installer, then you have to download and extract another zip file... then you have to repeat on any machine hosting the web application. And have the rest of your team do the same the next time they get the latest version of the code. Crap.
Am i alone in my frustrations of how Microsoft suffers from severe "Installitis" with their developer tools??
7 comments:
You're absolutely right, it's an annoying habit. 99% of these tools just seem to be MSIs so they can show you a license to click on. Beyond that, they're just DLLs or .exes and don't actually require anything fruity like registry entries etc.
One tool I've found useful is 'lessmsi', which extracts the contents of MSIs. But you can of course install the software, grab the DLLs and uninstall it again.
So, for example, I've been able to keep Web Deployment Projects, FxCop, MSBuild Community Extensions etc in source control alongside the project. I assume this is the also possible with the AJAX bits.
Obviously the extra effort sucks, but at least only _you_ have to do it. :)
My analogy is that I want to be able to do a fresh trunk checkout on a USB drive, fly to the moon and be able to build the system. Everything required for the build is in the trunk.
I've done a project with MS AJAX, and I was able to get it in the trunk.
Nope. Definitely not alone. Trying to set up a project so that it doesn't require a special windows image for some .Net applications can be very frustrating.
Putting binaries in a versioning system is a poor idea, and doesn't scale. What you need is a shared file-system, not a versioning system which is a specialized tool.
I am currently on a project where it takes over 2 hours to checkout from the versioning system because everyone thought it was a good idea to stuff it with over 3Gb of 'tools'. Thanks.
Malcolm.
You're entitled to your opinion but you're example of a 3GB tools directory is a symptom of a bigger and very different issue.
I would look at why is there so much in the tools, are they all needed? is that a sign this project is doing too much? Should it be broken into smaller projects?
The folder being so large it slows don't a checkout misses my point.
The principle I'm arguing is that you should not have to rely on manually installing numerous (possibly unknown) msi's in order to build a project. And more importantly every new developer joining the team shouldn't have to discover the process on their own.
Solve the problem once and look to have the ability to quickly get others up and running in a consistent and repeatable way.
The 3GB tools directory is a misuse of the concept. And the misuse of a concept isn't justification not to use it all together, IMHO.
I'm a satisfied user of "zc.buildout". It's a pretty easy to use system designed to do reproducible "buildouts". It's written in Python (but can of course build non-Python systems with it).
See http://pypi.python.org/pypi/zc.buildout/1.0.0b30 for info.
I'm a big fan of reproducible developer builds, but you do have to draw the line at some point, you can't include the entire OS in your repository.
Some things are part of the environment, some part of the project being built. Those two classes of things require different management mechanisms.
Post a Comment