5.2 Change & Release Management

A manufacturing facility is not a SaaS startup. "Move fast and break things" translates to "Stop the line and destroy revenue." The goal of Release Management is Stability. Every change to the MES or ERP must be treated as a hazardous material transport: carefully packaged, strictly routed, and reversible at the push of a button.

The Three-Tier Environment

Do not develop on the production server. Do not test on the production server. Strict isolation is the only defense against corruption.

DEV (Development)

• Purpose: The Sandbox. Developers write code and break things here.
• Data: Synthetic / Dummy data.
• Access: Full Admin rights for Developers.
• SLA: None.

UAT (User Acceptance Testing / Staging)

• Purpose: The Mirror. An exact replica of Production hardware and software configuration.
• Data: Anonymized copy of Production data (refreshed monthly).
• Access: Read-only for Developers; Read/Write for Key Users (Testers).
• Logic: If it works in DEV but fails in UAT → Then Reject Release. (Environment configuration drift).

PROD (Production)

• Purpose: The Money Maker.
• Data: Live, real-time master data and transactions.
• Access: Zero Write access for Developers. Changes applied only via automated deployment scripts or System Admins.
• Rule: "Hot-fixing" directly in PROD is a fireable offense.

The Release Gate: Governance Logic

Code does not move from UAT to PROD based on a developer's promise. It moves based on Evidence.

The Request for Change (RFC)

Every release must have a ticket containing:

1. Impact Analysis: Which lines/modules are affected?
2. Test Evidence: Screenshots/Logs of the pass in UAT.
3. Rollback Plan: The exact script to undo the change if it fails.
4. Timing: Estimated downtime.

The Approval Matrix

• Minor Patch (Bug fix): IT Manager Approval.
• Feature Release (New Logic): IT Manager + Operations Manager Approval.
• Major Upgrade (Architecture): CIO + Plant Director Approval.

Release Windows & Blackout Periods

Timing is everything. Never deploy when the factory is vulnerable.

The "Safe" Window

• Time: Tuesday, Wednesday, or Thursday. 09:00 – 11:00 or 14:00 – 16:00.
• Why: IT Support is in the office. Operations leadership is present.
• Logic: Deployments require "All Hands on Deck."

The Forbidden Zone (Blackouts)

• Fridays: If it breaks, you work the weekend.
• Shift Change: (e.g., 06:00, 14:00, 22:00). Too much operational noise.
• Peak Season / End of Quarter: Do not touch the system when max throughput is required.

Versioning Strategy

Adopt Semantic Versioning (Major.Minor.Patch) to communicate risk to the business.

• Major (v2.0.0): Breaking Change. Requires downtime and Operator Retraining.
• Minor (v1.1.0): New Feature. Backward compatible. No downtime required.
• Patch (v1.0.1): Bug Fix. Invisible to the user.

Pro-Tip: Display the current Version Number in the footer of every MES screen. If a user reports a bug, the first question is "What version are you on?"

Rollback Rules (The "Undo" Button)

A deployment plan without a rollback plan is negligence. You must be able to return to the previous state in < 15 Minutes.

The Snapshot Rule

• Virtual Machines: Take a full VM Snapshot before applying the update.
• Database: Take a Transaction Log backup immediately before the script runs.

The 15-Minute Timer

• Trigger: Deployment starts.
• Check: At T+15 minutes, run the "Smoke Test" (Print one label, complete one cycle).
• Logic:
  • If Smoke Test = Pass → Then Commit Change.
  • If Smoke Test = Fail OR Performance degrades > 20% → Then Execute Rollback Immediately. Do not "try to fix it live."

Final Checklist

Category	Metric / Control	Threshold / Rule
Isolation	Environment Gap	0% Developer Write Access to PROD Database.
Gate	Evidence	No Release without UAT Sign-off attached to RFC.
Timing	Scheduling	No Deploys on Fridays or during Shift Handover.
Safety	Rollback	Undo script/Snapshot tested before the release window.
Visibility	Versioning	UI displays Active Version (vX.Y.Z) on all terminals.
Data	UAT Freshness	UAT data refreshed from PROD < 30 days ago.
Migration	Database	All SQL scripts must be idempotent (safe to run twice).