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 Xperience 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 Xperience 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.
- Database conflicts can occur when multiple developers are editing the same objects resulting in lost data/changes.
- 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 MVC widget added to the home page that hasn't been promoted to all environments yet would cause errors for environments that don't have the code for the widget 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.