Skip to main content

SDLC 05: Infrastructure Management and Release Procedures

Revision history: Updated May 2026 — Branch strategy simplified (main = staging, production = live); migrated to systemd.

1. Branch Strategy​

The Pakashop branching model is designed for simplicity and continuous integration:

BranchEnvironmentPurposeTrigger
mainStagingIntegration & Pre-production QAPush to main
productionLiveProduction PlatformPR from main to production
feature/*PreviewLocal development & Vercel previewsPR to main

2. Infrastructure Overview​

TierPlatformNotes
FrontendVercelProduction branch: production; Staging branch: main
Backend (Staging)AWS EC2 (Staging)Tracks main branch
Backend (Live)AWS EC2 (Prod)Tracks production branch
MicroservicesAWS EC2Managed with systemd; separate unit files

3. EC2 Service Orchestration​

All backend services run under systemd.

3.1 Service Orchestration​

The backend ecosystem consists of several specialized microservices (Gateway, API, Notifications, Moderation, etc.) that are managed as independent units to ensure high availability and isolated scaling.

4. Deployment Flow​

4.1 Frontend (Vercel)​

  • Staging: Pushes to main are automatically deployed to the staging environment (e.g., staging.pakashop.store).
  • Production: Merges into production are automatically deployed to the live environment (pakashop.store).

4.2 Backend (EC2)​

Deployment is orchestrated via GitHub Actions using the deploy.sh script on the target host.

  • Staging Deployment:
    1. Merge feature branch into main.
    2. GitHub Action connects to the Staging EC2 instance.
    3. Executes the deployment orchestration script.
  • Production Deployment:
    1. Merge main into production via PR.
    2. GitHub Action connects to the Production EC2 instance.
    3. Executes the deployment orchestration script.

5. Release Procedures​

5.1 Standard Release​

  1. Complete feature development on a feature branch.
  2. Open PR to main. After review and CI pass, merge.
  3. Verify changes on the Staging environment.
  4. Once verified, open PR from main to production.
  5. Merge PR to trigger live deployment.

5.2 Hotfix Release​

  1. Branch directly from production for critical fixes.
  2. Apply and verify the fix.
  3. Merge back to production for immediate live deployment.
  4. Important: Immediately synchronize main with the new production state.

6. Rollback Procedure​

  1. Revert: Revert the problematic commit on the corresponding branch.
  2. Deploy: Push the revert to trigger the automated deployment.
  3. Verify: Check the service status and logs to ensure stability.