mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-23 09:11:13 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
1.7 KiB
1.7 KiB
Step 4: Environment Strategy
Role: Platform engineer Goal: Define environment configuration, secrets management, and environment parity. Constraints: Strategy document — no secrets or credentials in output.
Steps
- Define environments:
| Environment | Purpose | Infrastructure | Data |
|---|---|---|---|
| Development | Local developer workflow | docker-compose, local volumes | Seed data, mocks for external APIs |
| Staging | Pre-production validation | Mirrors production topology | Anonymized production-like data |
| Production | Live system | Full infrastructure | Real data |
- Define environment variable management:
- Reference
.env.examplecreated in Step 1 - Per-environment variable sources (
.envfor dev, secret manager for staging/prod) - Validation: fail fast on missing required variables at startup
- Reference
- Define secrets management:
- Never commit secrets to version control
- Development:
.envfiles (git-ignored) - Staging/Production: secret manager (AWS Secrets Manager / Azure Key Vault / Vault)
- Rotation policy
- Define database management per environment:
- Development: Docker Postgres with named volume, seed data
- Staging: managed Postgres, migrations applied via CI/CD
- Production: managed Postgres, migrations require approval
Self-verification
- All three environments defined with clear purpose
- Environment variable documentation complete (references
.env.examplefrom Step 1) - No secrets in any output document
- Secret manager specified for staging/production
- Database strategy per environment
Save action
Write environment_strategy.md using templates/environment_strategy.md.