Version Control and Automation Lifecycle Management
Source control
Studio integrates Git (and other providers through the same UI): initialize a repository, commit, push, pull, create branches and resolve conflicts. Treat Main.xaml and shared workflows as shared code: branch per feature, review before merging into main. .gitignore should exclude local settings, logs and machine-specific configuration, and should never include credentials. Because .xaml files are XML, merges are possible but risky; the pragmatic resolution is to accept one version and manually reapply the other developer's changes.
Lifecycle (ALM)
The standard promotion path is Development, Test/UAT, Production, each with its own Orchestrator folder or tenant and its own assets. Packages are versioned semantically (major for breaking change, minor for features, patch for fixes); Orchestrator only sees a new version after the package is uploaded and the process is updated to point to it. Pipelines automate build, test and deploy using the UiPath CLI or the Azure DevOps extension; Test Manager holds test cases and results. Governance covers change approval, rollback to a previous package version, audit trails and backups.
Traps
- Committing secrets, connection strings or production Orchestrator URLs.
- Forgetting a version bump, so Orchestrator keeps running the old package.
- Deleting old package versions that running processes still reference.
- Assuming configuration changes accompany the package; assets must be updated per environment.
Rule of thumb
Code flows up through environments; configuration does not. Promote the same package version and set environment-specific values in each folder's assets.