Promotion Without a Net: Versioning a Bot That Three Teams Depend On
A 'customer-onboarding' bot has grown to 40 actions across 6 sub-bots and is used by three business units. There is no source control; developers edit the production bot directly in the development environment and 'save and run.' Last week a developer changed a shared login sub-bot to add a new field; two business units' flows broke because they relied on the old field order. Rollback took 6 hours of manual reconstruction from memory. Management wants to 'just add a test step' and move on. The bot has no documented inputs/outputs and no error handling on the sub-bot calls.
1. Why is 'just add a test step' insufficient here? Identify the structural gaps.
Read the worked answer
A test step tests whatever version happens to be live - it does not solve the underlying problem, which is that there is no controlled artifact lifecycle. Gaps:
- No version control: Edits happen in place against production; there is no immutable history, so rollback is guesswork (hence 6 hours of reconstruction).
- No environment separation: Development and production are the same place; a change is instantly a production change.
- No interface contract: The shared login sub-bot has undocumented inputs/outputs. Changing field order silently broke consumers - a classic missing-contract failure.
- No error handling on sub-bot calls: Failures propagate opaquely; callers cannot distinguish a login failure from a downstream issue.
- No promotion gate: Nothing checks that a change is compatible with all three consumers before it goes live.
A test step is necessary but not sufficient: without versioning, environment separation, and a defined interface, the test only validates the current state and cannot prevent the next breaking change.
2. Design a promotion and change-management approach that would have prevented last week's incident and enables fast rollback.
Read the worked answer
Establish a lifecycle with contracts and gates:
- Version control everything: Store the bot and all sub-bots in a repository. Every change is a commit with a message and author. Production runs a tagged, immutable version.
- Environment separation: Develop in a dev environment, validate in a test/staging environment, then promote a specific version to production via the Control Room - never edit production in place.
- Define the sub-bot contract: Document inputs/outputs (names, types, order-independence where possible). Treat the shared login sub-bot as a published interface: additive changes only, or a versioned new interface (
login_v2) so existing consumers keep working. - Consumer-aware testing: A change to a shared sub-bot must run regression tests for all three business units' flows before promotion.
- Promotion gate: Require passing tests + review sign-off before a version can be deployed. Block promotion if any consumer's regression fails.
- Fast rollback: Because production runs a tagged version, rollback is redeploying the prior tag - minutes, not hours.
- Error handling on sub-bot calls: Wrap calls so failures are caught, logged with context, and surfaced as clear exceptions rather than silent breakage.
Answer to management: Add the test step and the versioning/contract/gate around it; the test alone would not have caught a field-order change unless the consumers' flows were part of the regression suite.