Playing in a sandbox: what every software developer should be encouraged to do

Updated 2019 : lolz… the modern ubiquity of git, config and env files makes this whole post laughable 🙂

Updated: 2009-12-24
It amazes me how often this simple practice eludes modern software companies.

A sandbox is a setup on your local machine which allows you to:

1. check out software from source control, and
2. build and test changes or additions.

To (2), I should perhaps add “without making a fool of yourself or jeopardizing the fruits of everyone else’s labour”.

Simply put, sandboxes prevent crappier iterations of your build from seeing the light of day. It’s your own little playpen for experimenting until you come up with an iteration that works… you can build your little sandcastles and demolish them and get covered in sand and mud. Nobody cares until you get to the point where you’re handing over your code (preferably back to source control).

The benefits

Sandboxes enhance productivity, because members of the development team are not depending on the same resources to get their work done.

Sandboxes promote experimentation and creativity by shielding immature solutions from premature judgement / appraisal.

Sandboxes allow team-members to employ different working styles and different pacing.

Finnicky

The problem is that for a complex n-tier application, setting up a truly personal sandbox can be finnicky. You may have to install memory-hogging web and database servers as well as other application frameworks on your own box. (Or do you? A-hahah.. Mwahaha haha haa!)

All this happens a lot more smoothly when the organisation as a whole recognizes the usefulness of sandboxing and actually sets up a sandbox server upon which there is a space carved for every developer on the team. In support of (or even in lieu of) a fully-fledged, organisational sandboxing system, a checkout script can be created that builds sandboxes on the fly, based on the latest version / HEAD in source control. All you’d need to give it are a target directory (for starters) and some other params.

Rolling your own Sandbox

If noone in your org gives a rodent’s posterior about sandboxing, I suggest you roll your own. Before you start, understand that a sandbox consists of 3 components:

  1. the deploy environment
  2. the build environment
  3. helper scripts (sandbox scripts)

This is the holy trinity of sandboxing, and if you remember nothing else from this article at least hold on to that.

OK. This is what you do:

1) Pick an existing deployment environment / server to replicate. Uhm, ideally one that currently works. By this I mean, find a box on which the app in question has been deployed to, and where it is actually currently running. Since it’s a good idea to not go poking about on production servers, you might want to pick the servers normally known as ‘STAGE’ or ‘DEV’ in your organisation.

2) Allocate time to discover the exact configuration of your chosen deployment machine: what server systems it uses, what it connects to, the location of configuration files, server files, its hosts files, directory structure, naming conventions and so on.

3) Make a list of the core components that seem to be needed to run the application in question. I say “seem to be needed” because if such things were actually quantified in your organisation at all, you wouldn’t be rolling your own sandbox, now would you?

4) Here’s the cheating part: how many of the items on the list from (3) can you pilfer from the existing baseline environment? Why use clock cycles on your machine to host an entire db, or space to host several files, if the environment you’re trying to dupe locally will simply *serve* those things to a connecting machine? If the 2 machines can communicate, and you have the right access protocols (you might need to sweet-talk your local BOFH)… then all you need is the appropriate clients installed to talk to remote servers… and pointers to remote files. In any case, your job is to replicate the deployment environment on your own machine (or whatever machine is going to host your sandbox).

5) test the deployment environment on your sandbox:  Get a release version of your application from source control, or a currently running version by copying the necessary files to the deployment environment within your sandbox. Now see if you can bring up the local instance of the application. If it does not come up / you can’t get it to run, then quite frankly you can’t proceed to do anything else. It is crucial that you get a known-to-be-runnable version of the app doing just that. This will be the most painful part of the sandboxing process, and will require lots of debugging, research, hairpulling and customisation of environment settings to make the app feel at home on your box.

So. Did you get past step 5? Well done! A third of the holy trinity of sandboxing is in place. Take a break. (seriously. Have a kit-kat. Go bother someone else for 5 minutes. Stretch your legs.

*** (whistling) ***

6) And…. we’re back. In this step we tackle the second part of the holy trinity: the build environment. Thankfully, it should be a lot less tricky. Check out the latest source for the app and try to build it. This may mean setting up new directory structures for the application source code and other assets, installing any preprocessor tools, or compilers, tweaking paths to needed runtimes, goodness knows what else. Remember: the source version of the app needs to be made to feel at home in your sandbox too, just as you did with the built version. Don’t proceed until the source builds cleanly.

7)Now, try deploying what you just built to your personal, sandboxed deployment environment (last time you touched it, in step 5, it was working. The point of this step is that you can deploy your own builds without hosing up your own deployed instance. You might need to restart a few servers or clear some log files but essentially, the new instance of the app that you just built should run EQUALLY HAPPILY as the stable/current release version you worked with in step (5).

That worked?! Wow! You’re really rollin’. There’s only one third of the holy trinity left to introduce you to:

8.) It’s time to make everything sing with a few sandbox helper scripts. Consider this: if you have several similar components or applications to build all the time, wouldn’t it be nice to have something like ANT to formalize your own sandbox structure? Or to automate some recurring tasks? Certain files will always need to be moved in a certain way while building, for example. So. Cobble together some scripts… they should help you to:

  • check out code
  • check in code (and maybe provide diffs)
  • archive / label / package and deploy builds
  • allow you to switch effortlessly between development projects… especially if they have some similarities that you can exploit.

Your sandbox scripts will evolve over time, so don’t try to make them do any more than the bare minimum at the beginning.

And that’s pretty much it! From here on you can just tinker and refine your sandbox, but you have now created an environment which allows you to develop code while abstracted from problems with the main build or problems introduced by other programmers (who in turn are abstracted from problems with your own build).

When your sandbox matures, you might want to add an additional step:

9) make your sandbox portable : generalise your scripts and folder structures such that you can take a special portable version of your sandbox anywhere with you.

Now go forth and build!

Leave a Reply

Your email address will not be published. Required fields are marked *