Deployment Plan and Infrastructure

Deployment Diagram

graph TD
    %% --- STYLING ---
    classDef plain fill:#fff,stroke:#333,stroke-width:1px;
    classDef box fill:#e1f5fe,stroke:#01579b,stroke-width:1px;

    %% --- NODES (HARDWARE) ---

    %% Node 1: User's PC
    subgraph UserPC ["<<device>> User's PC"]
        subgraph Browser ["<<execution environment>> Web Browser"]
            WebApp["&lt;&lt;artifact&gt;&gt; <br> Web App Bundle <br> (HTML, CSS, JS)"]
        end
    end

    %% Node 2: iOS Device
    subgraph iOSDevice ["&lt;&lt;device&gt;&gt; iOS Device"]
        iOSApp["&lt;&lt;artifact&gt;&gt; <br> Native iOS App <br> (.ipa)"]
    end

    %% Node 3: Android Device
    subgraph AndroidDevice ["&lt;&lt;device&gt;&gt; Android Device"]
        AndroidApp["&lt;&lt;artifact&gt;&gt; <br> Native Android App <br> (.apk)"]
    end

    %% --- DISTRIBUTION & ENTRY POINT ---
    AppStore["&lt;&lt;cloud&gt;&gt; Apple App Store"]
    PlayStore["&lt;&lt;cloud&gt;&gt; Google Play Store"]
    Domain["domain.com <br> (DNS / HTTPS)"]

    %% Node 4: Linux Server
    subgraph LinuxServer ["&lt;&lt;device&gt;&gt; Linux Server"]
        
        %% Component: Firewall
        Firewall["&lt;&lt;component&gt;&gt; Firewall <br> (Ports 80/443 Open)"]
        
        %% Runtime Environment: Kubernetes
        %% Added <br> to title to prevent overlap with the node below
        subgraph K8s ["&lt;&lt;execution environment&gt;&gt; <br> Kubernetes Cluster"]
            
            %% Artifact 1: Reverse Proxy
            RevProxy["&lt;&lt;artifact&gt;&gt; <br> Reverse Proxy Pod <br>(Traefik / Nginx)"]

            %% Artifact 2: Backend Service (with 3 replicas)
            subgraph BackendService ["Backend Service (ReplicaSet)"]
                direction TB
                Hono1["&lt;&lt;artifact&gt;&gt; <br> Hono Container 1"]
                Hono2["&lt;&lt;artifact&gt;&gt; <br> Hono Container 2"]
                Hono3["&lt;&lt;artifact&gt;&gt; <br> Hono Container 3"]
            end

            %% Artifact 3: Database
            DB[("&lt;&lt;artifact&gt;&gt; <br> PostgreSQL Pod <br> (Persistent Volume)")]
        end
    end
    
    %% --- COMMUNICATION PATHS & RELATIONSHIPS ---

    %% 1. Distribution Path (Deployment)
    AppStore -. "Deploy" .-> iOSApp
    PlayStore -. "Deploy" .-> AndroidApp

    %% 2. Client Traffic to Domain
    %% Extended dashes (----) create more vertical space for labels
    Browser -- "HTTPS:443 <br> (Get Static Assets)" ----> Domain
    WebApp -- "HTTPS:443 <br> (JSON API)" ----> Domain
    iOSApp -- "HTTPS:443 <br> (JSON API)" ----> Domain
    AndroidApp -- "HTTPS:443 <br> (JSON API)" ----> Domain
    
    %% 3. External Server Path (Internet to Server)
    Domain -- "HTTPS:443" --> Firewall
    Firewall -- "Forward Port 80" --> RevProxy

    %% 4. Internal Server Path: Proxy to Backend
    RevProxy -- "HTTP (Load Balanced)" --> BackendService

    %% 5. Internal Server Path: Backend to DB
    BackendService -- "TCP:5432 <br> (SQL)" --> DB

Loading

Database Management

Rollout Strategy

Release 1: Stakeholder Signoff Releases

This is our initial, ongoing release phase focused on our primary stakeholder.

• At each "signoff" point (e.g., after completing a major feature like "User Login" or "Dashboard"), we deploy the latest build to a private server.
• Our goal is to get formal "Go / No-Go" approval from our stakeholder on a feature-by-feature basis.
• Process:
  1. Complete a development milestone.
  2. Deploy to our private environment.
  3. Conduct a live demo with the stakeholder.
  4. Stakeholder provides feedback and signs off.
• This process ensures we are always aligned with the project's business goals.

Release 2: Friends & Family Deployment

Once R1 was fully signed off, we deploy R2 to a trusted group for real-world testing.

• This release serves to identify critical bugs, gather initial usability feedback, and test the application on a variety of real devices (e.g., different phone models, browsers) before exposing it to real clients.

• We will release to 12 users:

  • 1 Stakeholder: To observe the test and confirm the flow.
  • 5 Novice Users (Family): To test for intuitive design and ease of use.
  • 6 Power Users (Friends): To test for advanced features and potential edge cases.

• By giving them specific tasks (e.g. "Start a claim", "Create an account"). This allowed us to observe them, record issues in real-time, and prioritize all feedback in a post-deployment meeting.

• We used Sentry to automatically monitor and uncover backend/frontend errors that users might not have seen or reported. All critical and high-priority feedback was fixed before planning R3.

• All critical and high-priority feedback was fixed before planning R3.

Release 3: Final Release

After all critical and high-priority feedback from R2 is fixed and signed off, we will proceed with the final release. This phase scales our deployment to real, unbiased users to validate our core logic and test for edge cases.

Alpha Release

• We will release to 15-20 stakeholder-trusted clients.
• To validate the end-to-end claim submission process with real-world flight data. This phase is critical for testing our business logic and compensation calculations.
• We will use the in-app "Shake" tool for users to easily send bug and crash reports. We will also maintain a direct communication channel with this group for detailed feedback.

Open Beta Release

• We will recruit 50-100 testers through social media for an open beta. There are plenty of Facebook groups and Reddit airline subreddits that would appreciate the invitation.
• To test the application at a wider scale and, most importantly, to uncover edge cases (e.g., multi-leg flights, different airline data formats, user data entry errors) that our smaller test groups may have missed.
• In addition to "Shake," we will send a Google Form survey to all beta testers to gather broader opinions and ideas for future improvements.

Full Release

As our application is transactional (users come for a specific purpose), a traditional percentage-based rollout is not necessary. Once the Beta phase is complete and all critical bugs are fixed, we will execute a "Big Bang" release.

• This makes the app publicly available on our domain and in the App/Play Stores. This meets the stakeholder's plan to "go forward" with a general release, and we will continue to monitor Sentry and "Shake" for post-launch issues.

History of Rollouts