Release Promotion Without a Test Environment Match
A utility company runs Blue Prism across development, test, and production environments. Test runs on a different Blue Prism version (7.1) than production (6.10), and the test database is a restored copy that is refreshed quarterly. A release containing 14 process changes and 6 object changes is scheduled for Friday night. The changes include a new browser automation mode in one object and a modified queue schema with two new fields. The release was tested successfully in the test environment. Production has 40,000 items in flight in the affected queue. Rollback has never been rehearsed.
1. Assess the release risks and decide whether to proceed on Friday.
Read the worked answer
Proceeding as scheduled carries several compounding risks:
- Version skew. Testing on 7.1 does not validate behaviour on 6.10. Browser automation modes and engine behaviour can differ between major versions; a passing test on 7.1 is not evidence for 6.10. This alone undermines the test result.
- Stale test data. A quarterly refresh means the test database may not reflect current production data shapes, volumes, or edge cases. The new queue fields may interact with data the test copy never saw.
- Queue schema change with 40,000 items in flight. Adding fields to a queue that already holds live items is the highest-risk element. In-flight items may not carry the new fields, and any process logic that assumes their presence can fail at scale. The migration path for existing items must be explicit.
- Unrehearsed rollback. A Friday-night release with no tested rollback means any failure extends into the weekend with no safe exit. This is a governance failure, not just a technical one.
- Change volume. 20 changes in one release widens the blast radius and makes fault isolation harder.
Recommendation: do not proceed Friday as scoped. Defer, split the release, and close the environment gap first.
2. Propose a release plan that addresses the risks and a promotion gate that prevents recurrence.
Read the worked answer
Immediate plan:
- Align environments: bring test to the production Blue Prism version (6.10) or schedule the production upgrade first. Testing must occur on the target version.
- Refresh the test database from current production data (masked as required) so the new queue fields are exercised against realistic shapes and volumes.
- Split the release: ship object changes and low-risk process changes first; treat the queue schema change as a separate, carefully staged release.
- For the queue schema change, define the handling of the 40,000 in-flight items: either drain the queue before the change, or confirm the new fields are optional with defaults and that all logic tolerates their absence. Test this explicitly with a copy of live in-flight data.
- Rehearse rollback end to end in test, including restoring the previous release package and confirming in-flight items are not corrupted. Record the time to roll back.
- Schedule for a window with support coverage, not a Friday night.
Promotion gate (prevent recurrence):
- No release promoted unless test environment version matches production.
- Test data refresh within an agreed window (e.g., 30 days) before any release touching queue schema or high-volume processes.
- Every release has a documented, rehearsed rollback plan.
- Release size capped, or large releases require architect sign-off with a risk assessment.
- Queue schema changes require an explicit in-flight item strategy signed off before promotion.