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 attachments and Page-level permissions (ACLs), are stored seperately 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: