Develop your project

Developing in a team

Set your team up for success by deciding how your team will manage changes and collaborate before diving in.

Distributed development approach

In this approach, each developer has a local copy of the project’s code, which is synchronized via source control, and their own copy of the database. Database changes are synchronized through Continuous Integration (CI). There is a continuous integration server (CIS) that monitors changes in source control. When changes are detected, the CIS builds and deploys code to an integrated testing environment.

The testing environment has its own copy of the database, and is used for previewing and testing.

Pros

• Developers have a completely separate environment and can safely experiment with things without affecting other developers.
• Database changes are tracked in source control, meaning developers can pick and choose which ones to commit and also use the repo to easily reset their local environment to a “clean” state.
• Code and database changes can be deployed simultaneously.

Cons

• Database changes can, on occasion, result in complex merge conflicts.
• Developers do not have access to real time updates to the data across environments.
• Not all objects are supported (you can see the list in 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 storage to keep content assets and other physical files synchronized. There is a continuous integration server (CIS) that monitors changes in source control. When changes are detected, the CIS builds and deploys code to an integrated testing environment.

The testing environment is also connected to the shared development database and media library storage, and is used for previewing and testing.

Pros

• 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.

Cons

• Database conflicts can occur when multiple developers are editing the same objects resulting in lost data/changes.
• Database references to local files can be out of sync. For example, if a new MVC widget is added to the home page that hasn’t been promoted to all environments yet, environments that don’t have the code for the widget yet will show errors.

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 Git is the most commonly used.

Scenarios

Here are some example scenarios to demonstrate how different teams have chosen an approach in the past.

Development team with several small projects

A development team found themselves working on several small projects that only warranted one or two developers per project. Generally, each developer would only work on one or two of these projects at a time, but occasionally they would help with 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, so they did not need to set up local copies of the database each time. The small number of developers working on a project at any given time facilitated easy communication about data changes.

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 chose the distributed development approach, allowing local developers to operate independently. If they had chosen to have each developer connect to some centralized system, it would have been slow for one or more of the development teams.

Separate front-end development team

This development department had two teams: one that primarily focused on back-end development and one that primarily focused on front-end development.

The front-end team didn’t want to have local copies of the full site running on their machines, so they did their work locally in static HTML/CSS files and then replicated the changes directly in the integrated development environment. In order to prevent changes from being lost, they went with the centralized development approach; they didn’t want to worry about committing changes from the integrated development environment into source control.

Implementing best practices

Save time and effort by encouraging your developers to remember key concepts like performance and security.

Security

There are two sides to security. The first is related to properly configuring access to content and functionality for authorized users.

The second is making sure that hackers are not able to exploit flaws in the implementation to gain unauthorized access to content and functionality.

With Xperience by Kentico development, you need to consider the following:

• User permissions and access control lists (ACLs)
• Proper configuration of controllers/views/page builder widgets
• Sanitization of user input to prevent SQL injection and cross-site scripting attacks
• Secure data storage/transfer

Xperience’s admin UI and APIs make it easy for you to secure your application by providing an easy to use interface, some automatic protections, and tools to make sure you are able to easily secure your code.

Performance

Many times, developers primarily focus on building something functional. This can lead to scalability issues, higher running costs, and dissatisfied users.

Xperience by Kentico does a lot of optimization automatically, and provides many ways to improve your project’s performance with features like:

• Output caching
• Data caching
• APIs that can be fine-tuned to retrieve only the necessary data

It’s important to note that while Xperience does a lot of things automatically, it can be very easy to introduce performance issues. Here are a few practices to keep in mind as you develop:

• Introduce as few SQL queries as possible.
• Make sure that you have a caching strategy.
• Use tools like SQL Server Profiler to verify that your cache is working as expected.
• Analyze and test the performance of your custom code.
• Review how the project is configured, as some online marketing features can add overhead to requests (only enable what you need).
• Consider first page load time as well as primed cache load time.
• Consider using third-party tools to gain further improvements, such as HTML minifiers.

Dependencies

When building something new, you need to consider what it depends on (data structures, third-party APIs, etc.) and what will depend on it (templates, custom modules, etc.).

It is important to plan how what you are building will interact with its dependencies in order to avoid re-work or extra effort. This is also important when considering how to deploy new features/functionality down the line.

Some examples of dependencies to think about in Kentico Xperience include:

• Content types, content, and components needed to build a web page, email, or headless item.
• Properly configured Cache dependencies.
• Code files and classes that need to exist before you can build a custom module UI.
• Third-party libraries that your application needs to interact with in some way, such as NuGet packages, API endpoints, etc.
• Relationships between custom-built features.

Maintainability

Whether the project will be maintained by the same team or not, implementations should be created with future maintenance in mind.

If something is built sloppily the first time, maintenance can be exponentially more costly. It is important to consider every aspect of what you are developing when it comes to maintainability.

For example, you will want to pay attention to some of the following things in Xperience:

• Name code files appropriately (e.g., use the class name of the class contained in the file).
• Use Xperience’s logging APIs to log success/failure/warning/information appropriately.
• Consider refactoring large methods to make code readable.
• Consider using abstraction to make your code more modular and resilient to changes.
• Use built-in extensibility points such as global event handlers and custom providers.
• Use an appropriate naming convention to avoid collisions with system objects, especially during refreshes and hotfixes (e.g., use namespaces or prefixes with the site/project name).

User experience

This applies to both editors and visitors. Your solutions should be built with ease of use in mind. Your editors will have an easier time keeping the site up to date, and your visitors will be more engaged.

Some examples of how you can create a good experience for editors and visitors are:

• Utilize personalization to allow your editors more flexibility when creating a page.
• Build integrations that require only simple interactions, or that run automatically.
• Utilize templates when building the UI for custom modules, to maintain a consistent look and feel for editors.
• Don’t require more information than necessary from visitors.
• Provide visitors with a customized experience based on their history or context.
• Make it easy for visitors to fall into the pit of success.
• Consider page load times for visitors (the faster, the better).

Extensibility

Projects are very rarely built once and never extended. Thinking about how a feature might need to be enhanced in the future can help save effort and time in the future.

However, do bear in mind that there is a need to balance the effort/time with the project’s budget/timeline. Be sure to think about:

• How data will grow and change in the future
• Future integrations or features that you will need to add

Consider using Xperience’s built-in extensibility points to help with this process:

• Use custom modules.
• Investigate event handlers to tie into events that occur in the Xperience system.
• Look for built-in providers that you can customize so that Xperience uses your custom implementation.

What’s next?

The next guide in this handbook covers the Testing phase of your project. It discusses what to consider when testing the functionality and performance of your site.