Continuous integration repository structure

When using the continuous integration solution, the system serializes database data into XML and stores the results on the file system in the project’s CMS\App_Data\CIRepository folder.

The files are further organized within the following folder structure:

• Site level folders - the top level separates objects based on their relationships with sites: @global for global objects, <site code name> for individual sites (stores site-related objects, such as roles or ad-hoc page templates)

  • Object type folders - the next level contains folders for specific types of objects, based on object type names (see Object types supported by continuous integration 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 (such as the transformations of a page 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 (for example, transformations can belong under page types or custom tables).
    • 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, the binary data of metafile objects is stored in separate files. The separated files use names in format <object name>#<separated field identifier> and have an appropriate extension.

Example - CIRepository structure

Note: The example does not include all object types supported by continuous integration.

Storage structure for specific object types

Pages

The system uses three object types to store the definitions and settings of Pages. As a result, the files containing the serialized page data use a more complex structure than standard objects. The structure reflects how pages are stored in the database.

Each page is serialized in a site-specific cms.document folder and contains:

• A file in the <nodealiaspath>@<hash>.xml format describing the node data. This data determines where the page is stored in the content tree. The data is shared by all language versions of the page.
• A folder in the <nodealiaspath>@<hash>#<culturecode> format containing:
  • A document.xml file, containing language-specific data. Also contains the content of editable regions and editor widgets.
  • A fields.xml file, containing the data stored in the fields of individual page types.

Note: Other page-related object types, such as Page aliases, Page attachments and Page-level permissions (ACLs), are stored separately in the CIRepository folder.

For example, a “Coffee Beverages Explained” page with the “en-us” culture code on the dancinggoat site would be 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 files:

• A global cms.formclass item.
• A site-specific cms.form item.
• Any alternative forms under the main form are serialized as child objects of the global cms.formclass item.
• Bindings between forms and roles (determine which user roles are allowed to manage the form and its data in the Forms application) are site-specific, and the main object in the relationship is the form’s cms.form item.

Note: The continuous integration solution does NOT serialize the data records stored by individual forms.

For example, a form on the dancinggoat site with the “UserFeedback” code name, a “VIPFeedback” alternative form and role bindings would be serialized into the following XML files:

Users

Users in Kentico are a composite object type. As a result, the files containing the serialized data of users have a more complex structure than standard objects.

Each user is serialized into the following files:

• A global cms.user item, containing the basic user properties.
• A global cms.usersettings item organized as a child of the corresponding cms.user object. Contains the additional settings available when editing users in the Users application on the Settings tab.
• Other child objects and bindings, such as personal user categories and user-site relationships, are stored separately in the CIRepository folder.

For example, a user object with the username Andy would be serialized into the following basic XML files:

Resource strings

Each resource strings stored in the Kentico database (not strings in resx files) is serialized into the following files:

• A global cms.resourcestring item, containing the key of the resource string.
• A global cms.resourcetranslation item, containing bindings between the resource string and individual cultures. Stores the text value (translation) for each culture.

For example, a resource string with the CustomString key would be serialized into the following XML files: