Shiplane: release and operations case study
Deploy a service with CI, health checks, rollback, observability, and a clear operations runbook.
Use Shiplane to show how you test, deploy, and operate a backend service. Keep the deployment path small and visible. You do not need to build a general-purpose platform to show production-minded engineering.
Focus: CI, Docker, Linux operations, safe releases, and debugging. Plan about 45 to 55 hours across global weeks 14 to 19. These milestones use project weeks 1 to 6.
Deployment flow
Scope
- Core: automated tests on each change, container build, health check, deployment history, and a documented rollback.
- If time allows: blue/green deployment, metrics dashboard, alert rules, and nightly database backup.
- Cut first: custom orchestration, hand-built metrics storage, and a requirement to run continuously for a fixed number of weeks.
Deploy Ledgerline or another small service. Start with Docker Compose and a single VPS. State the limits of that setup and sketch how a larger system could use managed infrastructure.
Release behavior
- Build an immutable image from a commit and record its version.
- Start the new version beside the current one and check its health endpoint.
- Route traffic only after the check passes. Keep a documented manual rollback path.
- If you automate rollback, test it by deploying a deliberately unhealthy version.
Do not promise a rollback time before measuring it. Record the actual result and the test conditions.
Observability and recovery
- Emit structured logs with request IDs and release versions.
- Expose a small set of service metrics, such as request count, error count, and latency buckets.
- Choose one service objective and explain how the metric approximates it.
- Write a runbook for a service that fails its health check, fills disk, or loses database access.
- Test a backup by restoring it to a separate database and checking a known record.
Use controlled failures if no real incident occurs. Label them as drills. Never describe a simulated failure as a production incident.
Milestones
Artifacts to publish
- A README with the deploy path, architecture, and commands to reproduce a release.
- A CI run and a short demo of a successful deploy and a failed health check.
- A runbook with symptoms, checks, recovery steps, and known limitations.
- A release table with the number of attempts and measured outcomes. Include controlled drills separately from real incidents.
Interview topics
Explain how CI prevents broken releases, how health checks differ from readiness checks, what your rollback can and cannot undo, and how you would protect secrets and backups. Be clear about what ran on your VPS and what you only designed on paper.