Perforce and RoboMerge Branch Automation

Branch automation applies an integration policy repeatedly; it does not decide what a stream means. Make change direction, movement conditions, and exception ownership visible before introducing a tool. RoboMerge can then enforce a reviewable policy rather than become an unexplained source of changes.

Define stream intent#

Give every participating Perforce stream an operational purpose. A development stream may accept ongoing work, an integration stream may collect compatible changes, and a stabilization stream deliberate corrections. Define what may enter, where it may flow, what must not flow automatically, and who decides.

Draw allowed integration directions as a graph. Include content, code, configuration, and generated definitions when their rules differ. Each direction needs a reason independent of a pending change; otherwise it is not ready for automation.

Separate flow from promotion#

An integration is not automatically a release promotion. Automation can carry an approved source change along a defined path while a later promotion gate determines whether a built candidate is suitable for distribution. Keeping those concepts separate avoids treating a successful merge as evidence that the output is compatible, packaged, or ready.

Make stream protections agree with the graph. Direct submissions that bypass the intended path should be rare, visible, and recorded as exceptions. Otherwise the branch model will drift away from the automation model.

Assign integration ownership#

Every automated direction needs an owner, escalation route, and definition of what the tool may do alone. The author owns change intent; a stream owner decides whether it belongs, and a release owner may pause a direction during stabilization.

Do not make a bot account the owner of a conflict. The automation identity performs an action; people remain accountable for source changes, policies, and resolution decisions. Record the source change, target stream, selected rule, result, and resolution owner in a place that can be reviewed later.

Configure RoboMerge as policy execution#

Use RoboMerge to apply declared directions and exceptions. Begin with rules that map directly to the stream graph. Define eligible and excluded paths, target directions, pause behavior, and conditions that require review.

Avoid rules that depend on informal conventions hidden in change descriptions. If a convention is necessary, document its syntax, validation, and owner. Prefer explicit opt-in or opt-out behavior where the consequence of a missed annotation is understood. The safest policy is one whose result can be predicted by reading the rule and the source change together.

Treat conflict queues as work queues#

A conflict is a decision point, not a transient tool error. Queue blocked integrations with the source change, target stream, context, policy, and owner. Distinguish source and policy problems, infrastructure failure, and deliberate holds.

Resolution should produce a new, reviewable Perforce change or an explicit decision not to integrate. Do not rely on a local workspace repair that cannot be replayed. Once resolved, let the normal policy path re-evaluate the result rather than manually forcing a silent continuation.

Put gates around the change#

Use gates that match the risk of the direction. Source validation can reject malformed metadata, prohibited paths, unresolved files, or missing reviews before automation acts. Build and test gates can evaluate the resulting target revision after integration. A gate should report the exact revision it evaluated so a later retry does not accidentally use newer source.

Keep gate failure separate from merge conflict. A clean integration can still fail validation, and a conflict can be resolved before validation begins. Clear state makes it possible to retry the right operation without masking the original evidence.

Make behavior observable#

Emit an audit trail for accepted, skipped, paused, conflicted, retried, and rejected work. Include rule identity, source and target revisions, actor, and validation evidence. It should explain movement, non-movement, and the next owner.

Alert on conditions that require ownership, such as a paused direction, an accumulating conflict queue, repeated infrastructure errors, or a rule that rejects expected work. Observability is useful when it shortens diagnosis, not when it merely creates more dashboard surface.

Roll back without rewriting history#

When an integration must be undone, pause its direction. Create a corrective change, record why the policy allowed the original move, adjust the rule or source as needed, and rerun gates before resuming automation.

Do not use history rewriting as the normal rollback mechanism. Perforce history and automation records should remain able to explain both the original movement and the correction.

Implement in dependency order#

• Document stream intent and the allowed integration graph.
• Assign owners for directions, conflicts, holds, and policy changes.
• Configure a narrow RoboMerge rule set for an easily understood path.
• Add source validation, target validation, and an auditable conflict queue.
• Exercise a pause, a conflict resolution, and a corrective rollback.
• Extend automation only when the prior direction has predictable ownership.

Practical checklist#

• Every stream has a written operational purpose.
• Allowed directions are explicit and protected from casual bypass.
• Integration, promotion, and release decisions are distinct.
• RoboMerge rules map directly to documented policy.
• Automated directions have named owners and escalation paths.
• Conflict records contain context, classification, and an accountable resolver.
• Gates identify the exact revision they evaluated.
• Accepted, paused, skipped, and rejected work is auditable.
• Rollback pauses automation and creates a reviewable corrective change.
• New rules are added only after a bounded path is understood.