Hi everyone,
I’m looking for best practices to implement an efficient and standardized code review process for UiPath projects integrated with Bitbucket (using pull requests and Git version control).
Specifically:
- What branching strategy works best for UiPath (feature/develop/main, GitFlow, trunk-based)?
- How do you review large XAML changes effectively?
- Do you use a formal code review checklist (naming conventions, REFramework compliance, logging standards, exception handling, transaction handling, config management, etc.)?
- How do you enforce consistency in REFramework implementations?
- Are you integrating Bitbucket pipelines, UiPath CLI, Test Cases, or Automation Cloud pipelines for CI/CD and quality gates?
Additionally, I would like to ask:
Is Rovo Dev applicable or beneficial in UiPath development workflows (e.g., for PR analysis, automation insights, or documentation generation)? Has anyone successfully integrated it with UiPath repositories?
Looking forward to technical insights and real-world implementations.
Thanks.
Best regards,
Robert
Hi @RobertRussell_Monsalud,
- Branching strategy for UiPath projects
For UiPath, simple beats complex.
- Use feature → main (or feature → develop → main if releases are controlled).
- Keep one feature per branch and make branches short-lived.
- Avoid full GitFlow, as UiPath XAML merges get messy very quickly.
- Ensure the main branch is always in a deployable state.
Trunk-based development works only for very mature teams with strict discipline.
- Reviewing large XAML changes
Raw XAML diff is not review-friendly.
-
Review logic changes rather than raw XML structure.
-
Ask developers to explain what workflow changed, why it changed, and which components are impacted.
-
Validate changes directly in UiPath Studio, not only through Bitbucket diffs.
-
Use workflow diagrams and test-run evidence for larger or critical changes.
-
Code review checklist (keep it short & strict)
Yes, a checklist is mandatory. Typical checks include:
- REFramework compliance across Init, Get Transaction, Process, and End.
- Proper logging with clear separation between business and system exceptions.
- No hardcoded values; configuration should come from Config files or Assets.
- Correct retry logic and transaction handling.
- Clean folder structure and consistent naming standards.
If it’s not on the checklist, it doesn’t pass.
- Enforcing REFramework consistency
You don’t “request” consistency- you enforce it.
- Use a standard, company-approved REFramework template.
- Lock core workflows such as Init, Main, and End.
- Allow changes only in dedicated business workflows.
- Reject pull requests that modify framework logic without explicit approval.
Templates and discipline matter more than documentation.
- CI/CD and quality gates
Keep CI/CD lightweight but effective.
- Use Bitbucket Pipelines to restore packages, run UiPath CLI validation, and package projects.
- Apply UiPath Test Cases only to critical business paths.
- Deploy to Orchestrator via pipelines instead of manual publishing.
- Enforce pull-request approval as a mandatory quality gate.
Avoid over-engineering automation that brings little return.
-
Is Rovo Dev useful for UiPath?
-
It is not production-ready for deep XAML or logic reviews yet.
-
It can help with high-level pull-request summaries, documentation generation, and basic automation insights.
-
Strong human review remains essential for UiPath projects.
1 Like