presenton-test-deploy

Deploy FastAPI patches to the Presenton test instance with backups and smoke tests.

Updated May 15, 2026
One-click install
npx skills add https://github.com/Pear-Commerce/pear-ai-skills --skill presenton-test-deploy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: presenton-test-deploy
Source: https://github.com/Pear-Commerce/pear-ai-skills/tree/main/skills/presenton-test-deploy
Command: npx skills add https://github.com/Pear-Commerce/pear-ai-skills --skill presenton-test-deploy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires aws-cli, docker, python3, curl, sed, grep, and includes scripts (resource) components.

What problem does it solve?

Manually deploying and testing backend changes to the Pear Presenton test instance risks accidental data loss, credential exposure, service downtime, and broken contract validation logic. This Skill eliminates those risks by enforcing strict safety rules, mandatory pre-deployment backups, and automated verification steps.

Core Features & Use Cases

  • Safe Deploy Workflow: Enforces mandatory backups of service configuration, environment files, and SQLite databases before any service restart, with hard rules preventing data wipes, auth secret leaks, and unsafe configuration changes.
  • Fast Backend Patch Lane: Supports narrow, contract-preserving FastAPI code changes without full image rebuilds, reducing deployment time for small bug fixes while maintaining data integrity.
  • Bundled Contract Smoke Tests: Includes pre-built scripts to verify date handling and placeholder rejection logic works correctly after deployment, ensuring strict contract validation behaves as expected.
  • Use Case: A backend engineer fixing a strict-contract bug in the Presenton QBR endpoint can use this Skill to push the fix, apply a patch layer to the running test instance, run smoke tests to confirm the fix works, and roll back if needed without risking test data or service stability.

Quick Start

Use the presenton-test-deploy skill to apply a FastAPI contract fix to the Presenton test instance and run the bundled contract smoke tests to verify the change works as expected.

Frequently Asked Questions about presenton-test-deploy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I patch a FastAPI backend on a Docker container without a full image rebuild?

You can patch a FastAPI backend on a Docker container without a full rebuild by applying a narrow, contract-preserving code change layer to the running test instance. This fast patch lane reduces deployment time for small bug fixes while maintaining strict data integrity.

What is the safest way to deploy backend changes to an EC2 test instance without losing SQLite data?

The safest way to deploy backend changes without losing SQLite data is to enforce mandatory pre-deployment backups of the database and service configuration. This approach includes strict guardrails preventing data wipes and image-only rollback workflows to ensure persistent data remains intact.

How do I verify contract validation logic after deploying a FastAPI patch?

You verify contract validation logic after deploying a FastAPI patch by running bundled contract validation smoke tests. These pre-built scripts specifically check that date handling and placeholder rejection logic behave as expected following the deployment.

Do I need AWS CLI and Docker to deploy backend fixes to the Presenton test instance?

Yes, you need AWS CLI and Docker to deploy backend fixes to the Presenton test instance. The deployment process requires these dependencies to manage EC2 instances via AWS SSM and handle Docker container operations for applying the patch.

Can I roll back a FastAPI deployment if the smoke tests fail?

Yes, you can roll back a FastAPI deployment if smoke tests fail using the included image-only rollback workflows. This allows you to revert the running Docker container to its previous state without risking test data or service stability.

When should I avoid using a fast patch lane for FastAPI backend changes?

You should avoid using a fast patch lane for FastAPI backend changes when the code modifications break existing API contracts or require full image rebuilds. This workflow applies only to narrow, contract-preserving bug fixes where broader infrastructure changes are unnecessary.