[Discuss] Remote builds

[tmetro+blu at gmail.com (Tom Metro)]

Rich Braun wrote:
> In 2012 the big thing seemed to be Vagrant, Macbooks, VirtualBox, and
> all the complex moving parts that go with that.
[...]
> Right now, developers are expected to spend their first days (perhaps
> a couple of weeks) wrestling with getting a couple of VMs set up with
> vagrant on their MacBooks, dealing with permissions issues, and using
> that mess of code to install other masses of code on a dozen
> different Amazon EC2 instances.

It is rather amazing what some companies are willing to put their new
developers through in order to get set up with the required development
environment. It's the nature of the problem that this sort of thing gets
neglected. Developers are added rarely (on most projects). The people
with the knowledge of how all the parts fit together have long since
gotten past this pain point, and thus there is little motivation to
improve it.

I haven't yet had a client hand me a VM image as a way of addressing
this, but it sounds like it should work better than what you describe.
While it may be impractical to get rid of all the pain points through
automation and simplification, there may be a middle ground between
"easy setup" and Richard Pieri's description of "a steaming pile of
crap" that you can get to with an acceptable effort.

Perhaps you can elaborate on some specifics of how this approach is
failing so we can learn from your experience.


> ...am faced with the same toolchain (but this time on
> a django/python stack...
> ...and most of all server builds that take 20 or 30 seconds instead
> of 15 or 20 minutes.

So what's being built? Do you mean spin up a server instance?

If Python is your primary language, then you aren't really talking about
a build problem, but initial setup problem to get libraries, web
servers, etc. installed and configured.

That's more of an up-front problem, and distinctly different from the
challenge Greg posed where it sounded like there was a substantial
compilation phase.


> Rather than larding up more stuff on a beefier Mac...

You haven't mentioned whether the workstations are owned by the
developers or company provided. If the latter, then supplying them
pre-configured seems like it would be another option.

If not, then I agree that the company should be providing some sort of
remote development environment. I've never been a fan of loading up a
bunch of project-specific tools on a developer's personal machine. I
guess the VM approach could address that.


> But then the latest discussion about VNC had me intrigued...
> They'll love repeatability, being able to disconnect at will...

VNC wouldn't be my choice, but I'm not saying it is a bad one. A couple
of people have mentioned 'screen' as a way to get resumable sessions
without the GUI overhead. That's what I've been using for a long time.

If you are developing web-based software, rarely will there be a
requirement for a GUI development tool. I tend to view IDEs as largely a
developer's personal preference. And if I was inclined to use one, I'd
be reluctant to do so over VNC, even if on a fast local LAN. (There are
inevitably some lags and rendering artifacts with VNC.)

I've done many projects where developers shared a common development
server, and either used screen plus a console text editor, or using a
locally hosted IDE talking to their working directory via sshfs (or SFTP
built-in to the IDE). This keeps individual machines clean, except maybe
for a generic IDE, and puts all the project-specific setup on the shared
server.

It does require developers that aren't afraid of the command line. It
won't work if your target server is Windows.

If you are working with an interpreted language and don't have a big
compile phase, such a server can easily handle a pile of developers. In
some cases the common server has been one or more VMs in a private cloud.


> ...or pushing more stuff into the horribly-slow EC2 cloud...

Chose a different cloud vendor?


> Pull the rat's nest of stuff into a central repo, stabilize the VMs,
> have everything built on an easier-to-manage cluster service
> (initially with LXC, probably with OpenStack if it ever becomes 
> viable) on a few cheap SSD-based servers in our wiring closet,
> optimize the heck out of things, and give developers / QA folks /
> operations folks the exact same "Build Now" and "Deploy" buttons.

So your idea boils down to "use a private cloud." That's great (and I
recommend it) if your organization is big enough to take on that overhead.

Regardless of whether your development environment is a VM or a one-off
server, it's generally a good idea these days to have a VM image for
deploying your product to facilitate QA, as you mention.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/