Table of Contents

Working in teams

This article discussed how to work with DynamicWeb 10 in teams

Almost all DynamicWeb projects are developed by teams, so figuring out how to work effectively in teams is an important part of successfully completing a customer project.

This article covers some fundamental considerations before getting started. We will then dive deeper into the subject in the next article in this series about setting up CI/CD.

Source control

One of the most important tools for collaborating on code is a solid source control system. This article - and DynamicWeb itself - is not opinionated about which system you should use, but for the sake of simplicity throughout these articles, when source control is discussed, it's assumed to be git. The principles, however, are universal.

Local vs. shared database

Objectively, setting up an external shared database used by all developers is the easiest way to get started: simply clone the repository and start the solution.

For some project types this approach may be sufficient, but for more complex solutions - especially when content changes are made - it is not recommended, as the changes made by one developer to the database can interfere with changes made by another developer. And due to various caches, the individual solutions won't necessarily know about those changes until they are restarted. This can cause confusion and frustration and - in some cases - lead to data loss.

Therefore, when working in a team with multiple developers, we recommend that each developer has their own local environment with a local database.

Local databases and source control

One of the classic challenges when collaborating on a project is how to store local configuration without accidentally committing it to source control. Specifically, you need to treat the database connection settings separate from the rest of the code going into source control. This can be accomplished in a couple of different ways:

  • Create a GlobalSettings.Database.config with local database configuration
  • Use environments, e.g. a local appsettings.Development.json, where the connection is defined - see Environments & AppSettings for more information

If it's necessary to have many local configurations, it could be useful to group these together with a common naming format. Using a local identifier would make it easier to omit from source control: GlobalSettings.Local.[ConfigPart].config, for example GlobalSettings.Local.Database.config.

Note

The reason GlobalSettings.Database.config or GlobalSettings.Local.Database.config can contain a local database connection while GlobalSettings.config still contains the connection settings for the production database is that configuration is hierarchical: the first config file to define a setting "wins".

All .config files in the root of the Files folder are read in reverse alphabetical order, e.g., X.config is read before H.config which is read before A.config. This means that if a configuration is defined in both X.config and H.config, X.config takes precedence over H.config. GlobalSettings.config is always read last.

Files to ignore from source control

When running DynamicWeb locally, files are generated that shouldn't be committed to source control. Here's a list of files and folder you should strongly consider omitting from source control.

  • License files (*.license)
  • Local configuration (GlobalSettings.*.config, GlobalSettings.Local.[ConfigPart].config)
  • Parsed templates (/Files/Templates/Designs/**/_parsed)
  • Local appsettings (appsettings.*.json)
  • Log files (/Files/System/Log)
  • Diagnostics (/Files/System/Diagnostics)
  • Built indexes (/Files/System/Indexes)

Additionally, it may be worth it to avoid or minimize binary files such as images or archives in source control.

Onboarding new developers

One of the main challenges is how to get started as a new developer on the team. Code is easily replicated by cloning the repository, but getting data is a little more tricky. Some manual steps are required, but this can most likely be scripted to simplify the process. Additionally, this is made easier by using the shared test environment as the base.

In broad terms, the process is

  • Clone the solution repository
  • Download/export the database
  • Set up the solution locally using the steps outlined in the installing Swift guide

Next steps

Many of the topics discussed here are only covered in an introductory fashion. Setting up a workflow for working in teams is usually the first step in moving to a full CI/CD workflow. That and many of these topics is discussed more deeply in the setting up CI/CD article.

Improve this doc
To top