web-hosts/domains/coppertone.tech/docs/project-plan/phases/Phase-6-Testing-Deployment-and-Launch.md

Phase 6 Breakdown: Testing, Deployment & Launch

This final phase is about ensuring the quality and reliability of the platform before and after it goes live. It involves rigorous testing, finalizing the automated deployment pipeline, and establishing procedures for long-term maintenance.

---

Task 6.1: End-to-End (E2E) Testing

While unit tests (configured in Phase 1) check individual components in isolation, E2E tests validate entire user flows through the complete application.

• 6.1.1. Test Case Development:
  • Using the Cypress framework (selected in Phase 1), write test scripts for all critical user journeys:
    • User Authentication: A user can register, receive a confirmation, log in, and log out.
    • Client Flow: A client can log in, view their projects, see their invoices, and successfully complete a payment flow (using mock data from Stripe/BTCPay).
    • Staff Flow: A staff member can log in, create a new project, assign a task, and update the task's status.
    • Public Site: A visitor can navigate the public pages and submit the contact form.
• 6.1.2. Test Environment:
  • The E2E tests should be run in an environment that closely mirrors production.
  • The CI pipeline (Gitea Actions) will be configured to spin up the entire application stack (frontend, backend Go functions, database) using Podman Compose, run the Cypress tests against it, and then tear it down.

---

Task 6.2: Finalize CI/CD Pipeline with Gitea Actions

The Gitea Actions CI/CD pipeline will be extended to become a full Continuous Deployment pipeline, automatically shipping successful builds to production.

• 6.2.1. Container Registry:
  • Gitea includes a built-in container registry. This will be used to store the production-ready container images.
  • The CI pipeline (Gitea Actions) will need to be configured with credentials to log in and push to the Gitea registry.
• 6.2.2. Pipeline Stages:
  • The .gitea/workflows/*.yml files will be structured with multiple, dependent stages:
    1. Test: Runs all unit and integration tests for both Frontend and Go Backend services.
    2. Build: If tests pass, this stage builds the production Containerfile for the frontend and each Go backend service, tagging the images with the Git commit hash.
    3. Push: If the build is successful, this stage pushes the images to the Gitea container registry.
    4. Deploy to Staging: This stage will run on merges to the testing branch, deploying the new versions of applications to the staging environment.
    5. Deploy to Production: This stage will only run on merges to the main branch, deploying the new versions of applications to the production environment.
• 6.2.3. Secrets Management:
  • All sensitive information (SSH keys, API tokens, etc.) will be stored as encrypted secrets in Gitea's built-in secrets management, not committed to the repository.

---

Task 6.3: Production Deployment

This involves preparing the production server and performing the initial launch.

• 6.3.1. Server Hardening:
  • Set up a firewall (e.g., ufw) to only allow traffic on necessary ports (80 for HTTP, 443 for HTTPS, etc.).
  • Install and configure Podman and Podman Compose.
  • Set up a reverse proxy (e.g., Nginx or Traefik) to handle incoming traffic, manage SSL/TLS certificates (using Let's Encrypt), and route requests to the appropriate containers (including orchestrating Go serverless functions).
• 6.3.2. Initial DNS Configuration:
  • Point the A record for coppertonetech.com and any subdomains (gitea., matrix., etc.) to the production server's IP address.
• 6.3.3. Go-Live:
  • Manually run the deployment process for the first time.
  • Thoroughly test the live site to ensure all services are running correctly.
  • From this point on, all subsequent deployments will be automated via pushes to the main branch.

---

Task 6.4: Monitoring and Maintenance Plan

A system isn't "done" once it's deployed. Continuous monitoring and a clear maintenance plan are essential for long-term stability.

• 6.4.1. Monitoring & Logging:
  • Deploy a monitoring stack. A common choice is Prometheus (for metrics) and Grafana (for dashboards). Containers can be configured to expose metrics for Prometheus to scrape.
  • Deploy a logging stack like the Loki/Promtail/Grafana stack to aggregate logs from all running containers, making debugging easier.
  • Set up alerts in Grafana/Prometheus to notify administrators of critical issues (e.g., a service is down, CPU usage is too high).
• 6.4.2. Backup and Recovery Plan:
  • Implement a cron job or script on the production server that regularly backs up all critical data.
  • This includes:
    • PostgreSQL databases (using pg_dump).
    • Podman volumes containing persistent data for Gitea, Synapse, etc.
  • Store these backups in a secure, off-site location (e.g., a separate object storage service).
  • Document the exact steps required to restore the system from a backup.
• 6.4.3. Ongoing Maintenance:
  • Document procedures for updating system dependencies, container base images, and application packages on a regular schedule.
  • Keep all software up-to-date to patch security vulnerabilities.