4

Goal: Get a small team using a standard development image rather than 4 software devs setting up their own environments.

Why:

  1. it takes a day or days to install a distro, build-specific libraries, tools like editors and IDEs, mysql, couchdb, java, maven, python, android-sdk, etc. It's a giant PITA that when repeated 4 times by 4 developers (not sys admins) wastes time and generates annoying divergences that crop up later (it-builds-on-my-box syndrome).

  2. There's no sharing of productivity, settings, tricks, scripts, set-ups.

Some of this is helped by segregating the build systems into headless virtualbox images. This doesn't really address tooling though or the GUI-desktop dev that needs doing.

So I see three basic strategies, ghosting, virtualization, and finally creating a kind of in-house linux distro (I guess Google does something like this).

The target dev environment is based on Debian OpenBox and must allow a mix of 3rd gen Core i7 notebooks 8GB-minimum to work both single and multihead. Important, the lappies are not the same, but a mix of 2012 macbooks and PCs. So:

  1. virtualization: is doing all of your work within a VM, like VirtualBox, practical on this hardware or annoying.

  2. ghosting: will laptops from different manufacturers make this impractical.

  3. DIY distro: short of scripting a bunch of package installs, I don't know if there's any "distro-maker" that could keep this from being an epic project of scripting package installs.

So any advice?

deakblue
  • 41
  • 1

1 Answers1

3

This is a tricky problem, and one that rams right into the political really, really fast. If the corporate culture is very strong in the "devs build their own, it's how they're best productive" vein it can be impossible to crack. However, as IT is definitely involved in at least the initial setup, it sounds like you're not quite that far down the rabbit-hole.

I have a similar problem, though all IT is involved with is the very most basic of setup of a new laptop. I'm not involved in setting up dev environments, each dev is responsible for that (which rapidly becomes a team effort, which is a good thing in its own way).

However, without explicit management support anything you do will be subject to convincing your supported users that what you're doing is for the best. That is a skill we can't teach.

Because of the nature of our work, we've found that VM-oriented development works really well. Since we also have a mix of OSX, Windows, and Linux laptops as dev-stations, and we develop towards a much more specific combination of tools and OS, virutal-machines are the most reliable way to be sure that new code will work on the target platform.

Historically we've had people develop on a MacBook, deploy to the Integration environment, then spend a few days working through mac-specific quirks that don't work on the target environment. This "spend a few days" problem went away once these users started using VMs.

Whether or not VM-oriented workflow works for you depends in large part on your development practices. This seems to work best if a dev:

  • Can a dev work on a feature-branch
  • Can deploy that feature-branch to their own set of VMs with ease
  • Can merge their feature-branch into integration/testing/qa with equal ease and little de-tuning
  • Has enough sense of style to not piss off the other devs

As for "GUI IDEs in a VM", this can also work. Several of our Mac users go this exact route, they have a full-screen VM in one Screen upon which they do all of their code-crafting and use the other screens for non-development things like browsing stackoverflow for answers. This works best if the clipboard can be portable between the desktop and the VM.

A good plan for now is to build a VM in whatever platform you're using that has all the goodies you always put in your fresh builds. Then wire them up to pull updates from a repo hosted by you, so you can better manage what software gets updated when and you get less version-creep. For best effect, include some tweaks that seem to be common to a few developers as that will make the hearts-n-minds battle easier.

You're battling entrenched practices, and that's always going to take some time to change. At least, without an order from On High.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • Approval is a ground-up matter, and the devs are willing to standardize, just need to adopt a strategy. It's good to hear that you've had some success with a VM based approach. I'm considering versioning a set of build images, they would simultaneously work as Jenkins slaves, but also check-out so that builds can run locally. – deakblue Sep 15 '12 at 14:36
  • (cont and amended) It's good to hear that you've had some success with a VM based approach. I'm considering versioning a set of build images, they would simultaneously work as Jenkins slaves, but also check-out so that builds can run locally. So each dev could check-out a dev tools image and a builder image. Maven has made java dev very portable (until Android), but a lot of our other work depends on library installations. So it remains to be seen if I can link libraries from the 'tools' to 'build.' – deakblue Sep 15 '12 at 14:48