CI/CD repository structure

When using Continuous Integration or Continuous Deployment, the system serializes database data into XML and stores the results on the file system in a repository folder.

The files are further organized within the following folder structure:

• Channel level folders – the top level separates objects based on their relationship with channels: @global for global objects, <channel code name> for content and configuration objects related to individual channels (such as pages or emails).

  • Object type folders – the next level contains folders for specific types of objects, based on object type names (see Reference - CI/CD object types to learn more).

    • Object files – individual XML files are named according to the code name of the corresponding object. Object types without code names use the value of a non-unique field, followed by a unique hash. Object types without any easily readable identifying fields use their GUID value for the file name.
    • Binding data files – binding data is not stored in separate files for individual binding records, but combined for each main object in the relationship. The binding XML data contains an identifier of the main object (parent) in the relationship, and then identifiers of all objects that have the given relationship with the main object, along with any other data stored by the binding. The binding files are named after the main object in format: <object name>@<unique hash>
    • Parent object folders – object types that belong under a parent type use an additional level of subfolders – objects are separated into folders named according to the parent object in format: <parent object name>@<unique hash>. For object types that have multiple possible parent types, the folder name also contains a <parent object type>_ prefix.
    • Separated field files – certain types of objects store the values of specific data fields in separate files (placed next to the main XML file). For example, content items with a Content item asset field store the asset’s binary data as a separate file. The separated files use names in format <object name>#<separated field identifier> and have an appropriate extension.

• Lock files – the repository contains a .lock folder with temporary lock files used during store and restore operations. You can safely delete or ignore this folder in your source control system.

• Repository configuration file – the repository contains an XML configuration file (repository.config by default), which is used to adjust the behavior or CI/CD operations and exclude object types or individual objects. See Exclude objects from CI/CD.

Example - Repository structure

Note: The example does not include all object types supported by CI/CD.

Storage structure for specific object types

Content items

The system uses multiple object types to store the content and settings of content items. As a result, the resulting CI/CD files use a more complex structure than standard objects.

Content items are global objects serialized under the @global folder. Each item is divided into multiple folders and files:

• cms.contentitem – stores general system information about the content item.
• cms.contentitemcommondata – stores metadata about the item such as the current workflow and version statuses. Organized under subfolders matching the parent content item.
• cms.contentitemlanguagemetadata – metadata for specific language variants of the item. Organized under subfolders matching the parent content item.
• cms.contentitemreference – references to content items linked from the item’s fields.
• contentitemdata.<content type code name> – data stored in the fields of the item’s content type. Items with fields of the Content item asset data type also contain the referenced asset binary next to the XML definition.

For example, a "Bolivia Finca Illimani" reusable content item of the DancingGoat.Coffee content type could be, depending on the type’s fields and supported language variants, serialized into the following XML files:

Pages

The system uses multiple object types to store the content and settings of pages. As a result, the resulting CI/CD files use a more complex structure than standard objects.

Pages are serialized under a specific website channel. Each page is divided into multiple folders and files:

• cms.contentitem – stores general system information about the page.
• cms.contentitemcommondata – stores metadata about the page such as the current workflow and version statuses. Organized under subfolders matching the parent content item for the page.
• cms.contentitemlanguagemetadata – metadata for specific language variants of the page. Organized under subfolders matching the parent content item for the page.
• cms.contentitemreference – references to content items linked from the page’s fields. Organized under subfolders matching the parent content item for the page.
• cms.webpageitem – data about the page’s position in the website channel’s content tree. Organized into subfolders matching the parent-child hierarchy of the page tree.
• cms.webpageurlpath – stores the URL path data of the page. Organized under subfolders matching the parent content item for the page.
• contentitemdata.<content type code name> – data stored in the fields of the page’s content type.

For example, a “Coffee Beverages Explained” page with the DancingGoat.ArticlePage content type under the DancingGoat website channel could be, depending on the page’s fields and language variants, serialized into the following XML files:

Emails

The system uses multiple object types to store the content and settings of emails. As a result, the resulting CI/CD files use a more complex structure than standard objects.

Emails are serialized under a specific email channel. Each email is divided into multiple folders and files:

• cms.contentitem – stores general system information about the email.
• cms.contentitemcommondata – stores metadata about the email such as the current workflow and version statuses. Organized under subfolders matching the parent content item for the email.
• cms.contentitemlanguagemetadata – metadata for specific language variants of the email. Organized under subfolders matching the parent content item for the email.
• cms.contentitemreference – references to content items linked from the email’s fields. Organized under subfolders matching the parent content item for the email.
• contentitemdata.<content type code name> – data stored in the fields of the email’s content type.
• emaillibrary.emailconfiguration – stores the email purpose and other assorted metadata.
• emaillibrary.sendconfiguration – sendout settings for regular emails.

For example, a “Dancing Goat Regular” email with the DancingGoat.Email content type under the DancingGoatEmail email channel could be, depending on the type’s fields, serialized into the following XML files:

Headless items

The system uses multiple object types to store the content and settings of headless items. As a result, the resulting CI/CD files use a more complex structure than standard objects.

Headless items are serialized under a specific headless channel. Each item is divided into multiple folders and files:

• cms.contentitem and cms.headlessitem – stores general system information about the headless item.
• cms.contentitemcommondata – stores metadata about the item such as the current workflow and version statuses. Organized under subfolders matching the parent headless item.
• cms.contentitemlanguagemetadata – metadata for specific language variants of the item. Organized under subfolders matching the parent headless item.
• cms.contentitemreference – references to content items linked from the headless item’s fields.
• contentitemdata.<content type code name> – data stored in the fields of the item’s content type.

For example, an “Acme hammer” headless item with the Acme.Product content type under the AcmeStore headless channel could be, depending on the type’s fields, serialized into the following XML files:

Forms

The system uses multiple object types to store the definitions and settings of Forms. As a result, the files containing the serialized data of forms use a more complex structure than standard objects.

Each form is serialized into the following global items:

• cms.formclass
• cms.form

Note:

• CI/CD does NOT serialize form data submissions collected from visitors.
• Global cms.formfeaturedfield items hold the system’s definitions of featured form fields (options displayed in the Featured category when adding fields to forms).

For example, a form with the “UserFeedback” code name would be serialized into the following XML files: