RealtyMogul · Engineering case study
A merge is not a deployment
Bringing AWS pipeline progress back to the code review surface so a release could be followed from build to result.
Code lived in GitHub, but many services deployed through AWS CodePipeline. I built a small monitoring service that joined those two views of a release, then extended the CI/CD workflows so deployment status started earlier.
The problem
A commit being merged or a build completing did not say whether its deployment had started, failed, been superseded, or reached the intended environment.
Across multiple services and stages, the monitor needed to identify the exact source revision and keep later pipeline events attached to the same GitHub deployment.
What I did
Listen to the pipeline
Used EventBridge pipeline state changes and CodePipeline execution details to find the source revision and map AWS states to GitHub Deployment statuses.
Keep the lifecycle together
Stored an execution-to-deployment mapping so success, failure, cancellation, and supersession updated the right deployment without polling GitHub.
Make rollout safer
Added a dry-run stage that validates repositories and revisions before writes, tests for pipeline mappings, and build workflow changes that create a pending deployment before the deploy step.
What changed
Deployment progress could appear beside the revision that produced it, with a path back to AWS logs. I built the monitor and related workflow changes around pipelines owned by the broader engineering team.