3. 1. Developing in a team
As you start developing, you need to consider how the development team will work together to build the project. Team development in Kentico generally centers on how database changes are shared or synchronized across environments. The way your team approaches development depends on several factors. Let's first take a look at some general guidelines and then look at two approaches for team development in depth.
Distributed development approach
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.
- Developers have a completely separate environment and can safely experiment with things without affecting other developers.
- Database changes are tracked in source control and require merging (usually automatic).
- Allows for portal engine templates to be managed in source control.
- Allows for deployments of code and SQL changes simultaneously.
- Database changes can result in complex merge conflicts.
- Developers do not have access to real time updates to the data across environments.
- Not all Kentico objects are supported, so please check the documentation.
Centralized development approach
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.
- All settings, content, etc. in the database are the same for all developers.
- Only one database server is needed with only one copy of the database (lower resource requirements).
- Relatively simple to configure and maintain.
- Web farms must be configured (and licensed) in order for caches to be invalidated properly in all environments.
- This can be mitigated by using check in/out (locking) and versioning features for objects and content.
- Database references to local files can be out of sync. For example, a new web part added to the home page that hasn't been promoted to all environments yet would cause errors for environments that don't have the web part yet.
Using source control
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:
- Storing web.configs in source control safely
- Gitignore for Kentico
- Automating Kentico Continuous Integration with TeamCity and GitHub
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.