Set your team up for success by figuring out how your team will manage changes and work together before diving in.
In this approach, all developers have a local copy of the code, which is synchronized via source control and their own copy of the database. Database changes are synchronized via continuous integration feature. There is a continuous integration (CI) server that monitors changes in source control. When changes are detected, the CI server builds and deploys code to a testing environment.
In this scenario, manual merges may be necessary in the event of conflicts for both code and database changes.
The testing environment also has its own copy of the database and is used for functionality previewing and testing.
With this approach, each developer has a local copy of the code, which is synchronized via source control and uses a single shared database. Developers also use shared media library storage to keep media assets synchronized. There is a continuous integration server (CIS) that monitors changes in source control. When changes are detected, CIS builds and deploys code to an integrated testing environment.
In this scenario, manual merges may be necessary in the event of conflicts in the code. Additionally, you must implement several techniques such as object locking and object versioning to avoid database conflicts and data loss.
The testing environment is also connected to the shared development database and media library storage and is used for functionality previewing and testing.
Regardless of the approach you take, you should use some form of source control to keep track of changes in the project and facilitate automated builds and even deployments.
There are a multitude of options for handling this, but probably the most common is to use Git. To help you get started with Git and Kentico projects, we've created a few articles to help you get your project into source control and doing automated deployments:
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.
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.
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.
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.