5

Currently the company I work in gives each developer their own development virtual machine. On this machine (Windows 7) they install the entire stack of the product (minus database) this stack is normally spread amongst multiple machines of differing OS (although moving towards windows 2008 and 2008r2)

So when a developer has a new project they are likely to be updating only a small piece of their stack and as such the rest of it can become out of date with the latest production code. The isolation from others means some issues won't be found until the code goes into shared test environments/production.

I'm suggesting a move from functional testing on these isolated machines to plugging machines into a shared environment. The goal being to move towards a deployment thats closer to production in mechanism and server type.

Developers would still make code changes on their Win7 vm and run unit/component testing locally but for functionally testing they would leverage a shared enviornment.

Does anyone else use a shared development environment like this? Are there many reasons against this sort of sandbox environment? The biggest drawback is a move away from only checking in code when you've done local functional testing to checking in after static testing.

I'm hoping an intelligent git branching strategy can take care of this for us.

Improve this question
6
  • 3
    A shared develpment environment is the de facto standard approach most places I've worked, and the ones I've been that didn't work that way had huge problems. The ones which used shared environments were quite harmonious with devs always cleaning up any messes or mistakes they make on those environments. The places I've been where they didn't use shared environments their general arguement is it'll be so chaotic with everyone causing eachother problems, but that's just pure FUD and something I have never seen in practice. Engineers generally like to take responsibility and fix their oopses.
    – Jimmy Hoffa
    Nov 13, 2012 at 16:31
  • 2
    @JimmyHoffa: I've seen exactly that in practice and have just finished standing up an isolated environment for a group that was experiencing chaos caused by sharing the development environment. It wasn't that people weren't being responsible for fixing their oopses, but the other people using the machinery got stymied while the oops was in place and productivity suffered.
    – Blrfl
    Nov 13, 2012 at 16:59
  • @Blrfl In the years I've seen shared environments in place, I have rarely seen a system having trouble for longer than 15 minutes, and never longer than 1-2 hours (that happens once every 4 or 5 months maybe?), if 'productivity suffered" I'm guessing the devs weren't taking their responsibilities to correct things immediately seriously. Or perhaps you were referring to QA working in the same environment which is a different situation altogether; I'm referring to a shared environment for devs to work in an integrated fashion where QA has their own separate more stable environment.
    – Jimmy Hoffa
    Nov 13, 2012 at 17:13
  • @Blrfl on another note, the fact that there was so much trouble keeping a system in development functioning may be a sign of a much deeper problem in the software and the ease to do things correctly in it to begin with... I would say in that way shared environments with frequent developer integration (they still use their local for most of their work thus the 'frequent') will cause problem spaces in the system to make themselves more apparent, which is a good thing for quality.
    – Jimmy Hoffa
    Nov 13, 2012 at 17:19
  • 1
    @JimmyHoffa: I'm referring to development. I prefer that problems be fixed carefully and not slapped together in a rush because three other devs are trying real hard not to have their trains of thought derailed. We do very frequent rebuilds of systems with the latest, so the developers do get their stuff pushed around for everyone else to exercise. Sharing may be less of a problem in CRUD and web app shops, but it's a much bigger world than that. Point is, don't call it FUD because you haven't seen it personally. I've seen instances where your way fails and others where mine does.
    – Blrfl
    Nov 13, 2012 at 17:47

3 Answers 3

Reset to default
2

I'm not sure if enforcing a shared development environment is a good idea, but I would like to suggest that you are focusing on the wrong tool.

It seems to me that what you really need is a well setup dev environment with nightly builds/continuous integration and automated testing.

It wouldn't matter if I'm coding with vim in Ubuntu or with Eclipse in Windows if when I make a mistake the build/unit test system sends me an angry email that I broke something. By the same token, the said system would ensure the goal of better quality software much better than dictating a development environment.

It seems to me that whatever effort you would put towards a shared dev environment would be better spent setting up what I have described here.

Improve this answer
1
  • Interesting points. The dev environments currently are taken from source control and built locally on that machine. The stack itself is around 15-16 in house projects and it seems like if someone is only touching 2 of those projects in their current project that is the only components they want to upgrade (i guess for time saving). We have a CI system and a shared test environment but I guess the big thing for me is what the developers perform functional testing bears no resemblance to the current production server make up.
    – PatrickWalker
    Nov 14, 2012 at 10:28
2

Whether or not development should take place in a shared environment is a subtle question. My preference is not to, simply because that scales better. But I am also an advocate for making it as easy as possible to update the environment, and like to see it happen as often as possible. If everyone checks in early, checks in often, and syncs up regularly, you effectively have a shared environment except without resource contention or as big a window for oopses. If people aren't doing that, then a shared environment may help.

If devs are failing to keep their environment up to date, and then relying on deprecated behavior, that may be a symptom of a deeper problem. Namely that devs are breaking each other's code. In that case a shared development problem might solve the immediate problem, but could bring the underlying problem to the surface. Be aware of that, and be aware that people may blame the shared environment because it is an easier target.

But QA should definitely take place in a shared environment. It sounds like you're doing that. To catch more the integration issues, I would highly recommend setting up https://wiki.jenkins-ci.org/display/JENKINS/Unit+Test to make sure that unit tests actually happen in a timely fashion, in a way that can track down problems to the commit that is at fault. Making sure that you have enough unit test coverage to actually see problems is a second issue, but is one that is highly worthwhile to tackle.

Improve this answer
1
  • +1 for people may blame the shared environment. I've seen people complain about the integration causing problems instead of taking their time not to write bad hacks which cause the integration issues many times which is why I'm in ardent support of the integrated development.
    – Jimmy Hoffa
    Nov 13, 2012 at 22:14
0

I've seen this happen... there were benefits, but some major drawbacks made it an unrealistic long-term solution when I saw it.

  • Co-ordination between testers
    • "Hi everyone, I need to do an IIS reset..." and the whole team waits
  • Regression testing branches (ie. testing against a previously released/supported build)
    • Unless you can host multiple versions of the software on the same hardware, you need a new environment.
  • Testing fixes
    • Dev makes a fix, and gives it to test... how do they deploy? Redploy to the shared environment? Wait until tomorrow to test it? What if it's a high priority fix? It's a simpler and safer scenario for QA to just deploy to a private environment... and if the latter is the most common scenario, it's trivial to perform especially with automated deployment.
  • Performance testing
    • You need consistent and specific hardware with consistent and specific loads (ie. no other testers on it, only simulated ones) to get repeatable and stable performance results

That said, it was a great way to hammer 1 specific build, using all testers manually testing functionality. Got the team through a couple fire drills. Long term though? It's really messy.

Improve this answer
2
  • 1
    I would say you have identified why multiple shared environments are a necessity, either extreme of ONE shared environment or all non-shared environments fail. For performance testing you need a real clone of production that does not have people meddling on it while load testing is being executed, this should be an independent environment. For QA regressions they should have their own environment separate from dev. But for actual dev the early integration can have some major benefits of working through pains early in the process saving lots of time later.
    – Jimmy Hoffa
    Nov 13, 2012 at 22:11
  • I think I maybe wasn't clear originally so apologies. We have a seperate shared test environment, infact two as well as a seperate perf testing environment. When I say a shared Dev environment I mean a large environment with pools/clusters of servers so there should be some freedom between developers to not step over each other they will be integrating with newer versions of the software earlier. Each team has their own dedicated enviornment as well so some regresison testing etc should be possible especially as we're moving towards automated deployment software.
    – PatrickWalker
    Nov 14, 2012 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.