Summary

The documentation repository uses a mono-repo model. All product source documentation resides here; application code exists in a separate repository. Localization files will reside either in a dedicated repository or alongside the English source (to be determined). bla The repository employs three primary branch types: main, develop, and feature/*. Branch naming conventions can be adjusted as needed.

• main is the production source, deploying to docs.uipath.com.
• develop is the staging branch, used for testing and validation before release.
• feature/* branches are for active authoring and trigger preview deployments.

Versioning is handled by directory structure (e.g., orchestrator/latest, studio/2024.10).
No direct commits are allowed to main or develop; all changes must go through pull requests (PRs).

Authoring must always begin in a feature branch, with PRs targeting develop and then being promoted to main.

Documentation updates must be delivery-aware: all environments (e.g., cloud, on-premises) are covered simultaneously. Variables and conditional logic are used to maximize content reuse. An automated checker validates this.

Preview environments are automatically generated for each feature branch.

Merges are moderated. Only documentation owners or moderators can approve merges. Overrides are possible via structured comments when necessary.

For details on the publishing strategy and deployment process, refer to the publishing strategy documentation.

---

Repository structure and branching model

The documentation will be managed in a mono-repo. All product source documentation lives here. Application code is maintained separately. Localization files may reside in a separate repository or with the English source (TBD).

Branch	Purpose	Deployment
main	Canonical source of truth	Production (docs.uipath.com)
develop	Active development, staging for main	Staging preview (docs-staging.uipath.com)
feature/*	Work-in-progress authored content	Per-PR preview (docs-dev)

Rule: No direct pushes to main or develop. All updates are submitted via pull requests, with enforced reviewer approval through CODEOWNERS.

---

Folder and versioning structure

Example directory structure:

├── orchestrator/
│   ├── includes/
│   ├── media/
│   ├── latest/
│   │   ├── user-guide/
│   │   ├── api-guide/
│   │   └── release-notes/
│   └── 2024.10/
│       ├── user-guide/
│       ├── api-guide/
│       └── release-notes/
├── studio/
│   ├── includes/
│   ├── media/
│   ├── latest/
│   └── 2024.10/
└── assistant/
    └── ...

---

Authoring flow

Authoring to production

author ➝ feature branch (docs-dev)
          |
          ▼
   PR to develop (full review, CI checks, preview URL)
          |
     - Markdown lint/style
     - Structural validation
     - Conditional flag checks
     - Product owner approval
     - Preview deploy (e.g. Netlify)
          ▼
        develop (docs-staging)
          |
          ▼
   PR to main (high-level checks, release gating)
          |
     - Release validation
     - Optional final approval (release manager)
     - Production deployment trigger
          ▼
         main (docs-production)

Step 1: Authoring

• Start in a feature branch, e.g., feat-studio-triggers-doc.
• The working directory for ongoing development is always latest.
• Edit or create files within the relevant product and version folder, e.g., apps/latest/user-guide/introduction.md.
• Use flags (e.g., cloudFlavor) to conditionally show/hide content by environment, and variables for output variations.
• Push changes to the feature branch.

Step 2: Pull request into develop

• Open a PR targeting develop.
• Pre-merge requirements:
  • Lint checks
  • Markdown standards enforcement
  • Ownership review (moderator/owner required)
  • Overrides possible via comment trigger (e.g., /override-review)
• Automatic preview link generated (Netlify, Vercel, or GitHub Pages Preview).
• PR previews must build all relevant variant outputs (cloud and on-premises).
  latest/ serves as a staging area, not a finalized environment. This ensures all writers are aware of every delivery context.

Step 3: Merging to develop

• Once approved, the PR is merged into develop.
• Changes are visible at docs-staging.uipath.com.

Step 4: Promote to main

• At release intervals:
  • Open a PR from develop to main.
  • Only approved, release-ready changes are included.
  • Merged changes deploy to docs.uipath.com according to the deployment cadence or trigger rules.

---