Pipeline Hardening

Step 1: MCP-informed test design

The MCP connection gives Claude direct knowledge of the database schema. Use that to write better tests -- tests that verify the application works correctly with the actual data model, not with assumptions about it.

Ask Claude to review the existing tests and suggest additional integration tests based on the actual schema relationships:

Using the MCP connection, look at the database schema and the existing tests in tests/. Suggest 3-4 additional integration tests that would catch real problems -- especially tests that verify foreign key relationships, the interaction between batches and quality checks, and the shipment-to-certificate relationship.

Add the suggested tests to the test suite and run them locally. Then push to trigger the pipeline. The new tests should run alongside the existing ones.

Flaky tests are worse in CI than locally. A test that sometimes fails blocks the entire pipeline, which blocks everyone. If any new test is flaky -- passing sometimes, failing other times with no code change -- investigate immediately. The usual causes are timing assumptions, database state leaking between tests, or network dependencies.

Step 2: Deployment notifications

Aminata's fourth requirement: "I need to know when a deployment succeeds or fails." Add a notification step to the pipeline.

Tell Claude to add a deployment notification step:

Add a notification step to the CI/CD pipeline that runs after the deploy step. It should:
1. Send a notification on both success and failure
2. Include the commit message and the outcome (deployed successfully or failed at which step)
3. Use GitHub Actions' built-in notification capabilities or a simple webhook

The notification step should use if: always() so it runs whether the pipeline succeeded or failed. A notification that only fires on success is useless -- Aminata needs to know about failures even more than successes.

Step 3: Staging configuration

Production deployments should not go straight from "tests passed" to "live for 45 employees." Add a staging step between build and production deploy.

The staging environment runs the same build against a separate environment. If staging works, production deploy proceeds. If staging breaks, production is never touched.

Tell Claude to update the pipeline:

Update the CI/CD pipeline to include a staging deployment step between build and production deploy. The staging step should:
1. Deploy to a staging environment first
2. Run a basic health check against the staging URL
3. Only proceed to production deploy if staging is healthy
4. The production deploy step should need the staging step to pass

Step 4: Deployment window

Aminata's processing floor runs 6AM to 7PM West Africa Time. Downtime during these hours means untracked batches, missed quality checks, and potentially missed export shipments.

Add a deployment window awareness to the pipeline. A warning comment in the workflow that flags deployments during processing hours is the right level -- a hard block is complex to implement correctly in GitHub Actions and the value is in the team being aware, not in an automated gate.

Add a step at the beginning of the deploy job that checks the current time in West Africa Time (UTC+0). If the time is between 06:00 and 19:00, add a warning annotation to the workflow run saying "WARNING: Deploying during Sahel Noix processing hours (6AM-7PM WAT). Production downtime during this window directly affects 45 processing floor workers."

Aminata sees the deployment notification. She responds: "Good. Now I know when something changes. But what happens if someone deploys during the afternoon shift? We had the March outage at 2PM."

The deployment window warning is the answer.

Step 5: End-to-end verification

Run the complete pipeline from start to finish. Push a meaningful change -- a small improvement to an API endpoint or a new test. Watch every stage execute:

1. Lint passes
2. Tests pass (including your new MCP-informed tests)
3. Migration check passes
4. Build succeeds
5. Staging deploy succeeds
6. Production deploy succeeds
7. Notification sent

If any step is skipped, soft-fails, or doesn't fire, fix it now. A pipeline with gaps is worse than no pipeline -- it creates false confidence.