docker65

This structure is designed for a concise Scrum stand-up or breakout session (about 3–5 minutes). It balances high-level concepts with the specific "destructive update" and "downgrade" features you are implementing in the COMET migration.

Scrum Presentation: RPM Deployment Standard

Goal: Align the team on the new RPM-based deployment lifecycle and our custom cleanup/downgrade logic.

Slide 1: The RPM Anatomy

Core Concept: We are moving to a standard Linux packaging format. The filename is our primary metadata carrier.

Artifact (Name): The application identity (e.g., CPLS).
Version: The code version (e.g., 1.2.0).
Release: The build iteration (e.g., 2).
Architecture: The target environment (e.g., x86_64).

Slide 2: The Lifecycle (Wipe & Replace)

Core Concept: Unlike traditional updates, this implementation is destructive by design to prevent configuration drift.

The Logic: When a new RPM is installed, we don't just "overwrite" files in place.
The Goal: We want a clean slate. Any previous release files are removed.
Why? This ensures we don't have "ghost files" or stale configuration left over from previous versions that could cause unpredictable bugs. If it isn't in the new package, it shouldn't exist on the server.

Slide 3: Downgrade Capability

Core Concept: Standard RPM/YUM behavior is "forward-only." We are explicitly overriding this for emergency recovery.

The Constraint: By default, YUM rejects an install if the system detects a newer version is already present.
Our Solution: We have implemented allow_downgrade: yes in our Ansible automation.
Operational Workflow: To roll back, we don't need a complex uninstallation script. We simply define the target Version and Release in our pipeline and re-run the build cycle. The installer treats the "older" package as the new desired state and forces the swap.

Slide 4: Summary of Rules

Same Artifact Name: Triggers the "Wipe & Replace" cleanup process.
Changing Artifact Name: Treated as a new, independent application; previous installations remain untouched.
Downgrades: Fully supported via our Ansible pipeline flags, allowing for rapid recovery.

Tips for your delivery:

Keep it focused on the "Why": Since it's a Scrum meeting, emphasize that the "destructive" nature is a feature for stability, not a risk—it reduces the "it works on my machine/server" issues caused by leftover files.
Fielding Questions: If they ask about data persistence, clarify that data directories should be mounted externally or decoupled from the application path so that the "Wipe & Replace" doesn't destroy the user's data.

How does this flow feel for your team's current level of technical familiarity?