--- title: Continuous integration repository structure related: - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md - https://docs.kentico.com/13/custom-development/serializing-objects-to-xml-using-the-api.md --- > Agent instructions: > **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown. > > - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version. > - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt). When using the [continuous integration solution](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md), the system serializes database data into XML and stores the results on the file system in the project's **CMS\App\_Data\CIRepository** folder (or another location set by the _CMSCIRepositoryPath_ web.config key). 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, **** for individual sites (stores site-related objects, such as pages or media libraries) - **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](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md) 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: _**@**_ - **Parent object folders** – object types that belong under a parent type (such as the permissions of a page type) use an additional level of subfolders – objects are separated into folders named according to the parent object in format: _**@**_. For object types that have multiple possible parent types, the folder name also contains a _**\_**_ prefix (for example, permissions 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 _**#**_ and have an appropriate extension. > **Info:** **Long names and forbidden characters** > > Very long folder and file names automatically replace the middle of the name with **..** characters, preceded and followed by a limited number of characters from the start and end of the name. To ensure the uniqueness of the name, an **@** symbol followed by a fixed-length hash value is appended. > > For example: _longcustomwpprefix..webpartcodenameend@fe6fd25d3e.xml_ > > If an object name contains characters that are not allowed in file names (for example slashes or backslashes), the given characters are removed and the same unique hash is appended. > **Note:** **Source control ignore rules** > > Certain source control systems may have ignore rules, such as _gitignore_, which exclude files or folders used in the continuous integration repository (for example the _\*.class_ and _\*.user_ file and folder extensions). > > Such rules may prevent your environment from working correctly. We recommend that you evaluate ignore rules for the continuous integration repository location and disable them as required. ## Example - CIRepository structure **Note**: The example does not include all [object types supported by continuous integration](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md). > **Info:** CMS\App\_Data\CIRepository > > - @global > - cms.alternativeform > - cms.news@8a478af656 > - filter.xml > - cms.documenttype > - cms.news.xml > - cms.emailtemplate > - ecommerce.ordernotificationtocustomer.xml > - cms.metafile > - articles@7baacb97a4 > - articlesthumbnail.png@ead1667b00#file.png > - articlesthumbnail.png@ead1667b00.xml > - cms.pagetemplate > - listing.xml > - cms.webpart > - repeater.xml > - cms.webpartcategory > - listingsandviewers.xml > - dancinggoatmvc > - cms.documenttypescope > - articles@97f55a462a.xml > - cms.emailtemplate > - ecommerce.orderstatusnotificationtocustomer.xml > - cms.form > - dancinggoatmvccoffeesamplelist.xml > - media.library > - coffeegallery.xml ## Storage structure for specific object types ### Pages The system uses three main object types to store the definitions and settings of [Pages](https://docs.kentico.com/13/managing-website-content/working-with-pages.md). 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](https://docs.kentico.com/13/custom-development/working-with-pages-in-the-api/page-database-structure.md). Each page is serialized in a site-specific **cms.document** folder and contains: - A file in the _@.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 _@#_ format containing: - A _document.xml_ file, containing language-specific data. - A _fields.xml_ file, containing the data stored in the fields of individual [page types](https://docs.kentico.com/13/developing-websites/defining-website-content-structure/managing-page-types.md). **Note:** Other page-related object types, such as [Page attachments](https://docs.kentico.com/13/managing-website-content/working-with-files/page-attachments.md), [Page-level permissions (ACLs)](https://docs.kentico.com/13/managing-users/configuring-permissions/configuring-page-permissions/page-level-permissions-acls.md), and [Page URL paths](https://docs.kentico.com/13/managing-website-content/working-with-pages/managing-page-urls.md) are stored separately in the _CIRepository_ folder. For example, a _"Coffee Beverages Explained"_ page with the "_en-us_" culture code on the _dancinggoatmvc_site could be serialized into the following XML files: > **Info:** CMS\App\_Data\CIRepository > > - dancinggoatmvc > - cms.alternativeurl > - articles\_coffee-be..es-explained\_en-us@7902cb5c89 > - coffee-drinks-explained@32acf274ff.xml > - cms.attachment > - articles\_coffee-be..es-explained\_en-us@7902cb5c89 > - coffee-beverages-explained-1080px.jpg@faab8ccb54#file.jpg > - coffee-beverages-explained-1080px.jpg@faab8ccb54.xml > - cms.document > - articles\_coffee-beverages-explained@1695e3bbe7.xml > - articles\_coffee-beverages-explained@1695e3bbe7#en-us > - document.xml > - fields.xml > - cms.pageformerurlpath > - articles\_coffee-beverages-explained@1ec8a463ae > - articles\_coffee-be..es-explained\_en-us@5387a32a00.xml > - cms.pageurlpath > - articles\_coffee-beverages-explained@1ec8a463ae > - articles\_coffee-beverages\_en-us@6cfa64fe01.xml ### Forms The system uses multiple object types to store the definitions and settings of [Forms](https://docs.kentico.com/13/managing-website-content/forms.md). 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. - 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 _dancinggoatmvc_ site with the _"UserFeedback"_ code name and role bindings would be serialized into the following XML files: > **Info:** CMS\App\_Data\CIRepository > > - @global > - cms.formclass > - bizform.userfeedback.xml > - dancinggoatmvc > - cms.form > - userfeedback.xml > - cms.formrole > - userfeedback@b8da61c184.xml ### Users [Users](https://docs.kentico.com/13/managing-users/user-management.md) in Xperience 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: > **Info:** CMS\App\_Data\CIRepository > > - @global > - cms.user > - andy.xml > - cms.usersettings > - andy@7b3b12561e > - 646cd67b-6380-462c-be47-d68449445465.xml ### Resource strings Each [resource strings](https://docs.kentico.com/13/multilingual-websites/setting-up-a-multilingual-user-interface/working-with-resource-strings.md) stored in the Xperience 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: > **Info:** CMS\App\_Data\CIRepository > > - @global > - cms.resourcestring > - customstring.xml > - cms.resourcetranslation > - customstring@09f9b53a99.xml