Deploying from a development environment into another environment for testing or production uses is a large topic on its own. This section deals primarily with how to configure your development environment, but we have prepared a whole section on deploying.
Development team with several small projects
A development team found themselves working on several small projects that really only warranted one or two developers per project. Generally, the developers would only work on one or two of these projects at a time, but occasionally would be brought in to work on some aspect of another project.
In order to limit the setup time for these one-off sub-projects, the team elected to use the centralized development approach to avoid the step of setting up the database each time.
Global team working on one project
In this case, a global company had multiple development teams in several countries.
In order to keep development running smoothly they went with the distributed development approach so that local developers would be able to operate independently without needing to connect to some centralized system that would likely be slow for one or more of the development teams.
Separate front-end development team
This development team had two teams, one that primarily focused on back-end development and one that primarily focused on the front-end development.
As the front-end team didn't need or want to have local copies of the full site running on their machines, they would do their work locally on static HTML/CSS files and then replicate the changes directly on the integrated development environment. As such, in order to prevent changes from being lost, they went with the shared development approach because they didn't want to worry about checking in changes from the integrated development environment into source control.