Another approach is creating a set of shared services that developers can use rather than deploying their own instances. This article by a LinkedIn engineer describes their internal Quick Deploy system:
Personally, though, I'd go the route of creating a self-contained Vagrant setup if possible. This helps folks become familiar with the entire system and fix bugs anywhere in it, rather than drawing strict lines of ownership around specific services.
Comments
One approach is stubbing out the services you don't need. This article by a Heroku engineer describes how to do this at the Rack level:
https://brandur.org/service-stubs
Another approach is creating a set of shared services that developers can use rather than deploying their own instances. This article by a LinkedIn engineer describes their internal Quick Deploy system:
http://engineering.linkedin.com/developer-productivity/quick...
Personally, though, I'd go the route of creating a self-contained Vagrant setup if possible. This helps folks become familiar with the entire system and fix bugs anywhere in it, rather than drawing strict lines of ownership around specific services.
yeah we've used stubs in the past and it's often awkward and creates silos within the team. I'm not a huge fan of this approach.