CI/CD / Professional experience
Container delivery with GitHub Actions & ECS
I build GitHub Actions delivery workflows for ECS workloads on EC2 capacity. Images move through ECR, a one-off migration task, and a health-checked rolling deployment, with the result reported to Teams.
Scope of work
Environment-specific push and PR events trigger image builds, migration execution, rolling ECS updates, and workflow-result notifications.
Key contributions
- Building container images from Dockerfiles and publishing them to Amazon ECR.
- Running a temporary ECS migration task and stopping deployment if it fails.
- Deploying new task-definition revisions through rolling ECS updates with health checks.
- Using OIDC roles, Systems Manager, runtime secrets, and Teams result notifications in the delivery workflow.
Public overview
This overview describes my professional contributions in general terms. Employer and client identities, internal source code, and production architecture are not disclosed.
From branch event to a health-checked release
A simplified technical account of the testing-environment delivery process. Service names explain the responsibilities; environment identifiers and production topology are omitted.
GitHub Actions
Push and pull-request events for an environment branch trigger GitHub Actions with short-lived AWS IAM OIDC roles. The runner builds container images from the existing Dockerfiles.
Amazon ECR
The workflow publishes the built container images to Amazon ECR. Those images are used by the migration task and the application deployment.
One-off ECS task
A temporary ECS task runs the database migration on EC2-backed capacity. If migration fails, the pipeline stops before deployment and sends a failure notification to Teams.
ECS on EC2
After migration succeeds, the workflow registers a new task-definition revision and updates the ECS service for a rolling deployment. Secrets Manager supplies runtime secrets; health checks must pass before the stage completes.
Microsoft Teams
GitHub Actions reports the workflow result through a Teams webhook. Successful deployment notification follows health checks; a failed migration reports failure without advancing to deployment.
Migration failure stops the release
The temporary task runs before application deployment. If migration fails, the workflow does not advance to the deployment step and sends the failure result to Teams.
Health checks gate completion
After a successful migration, a new task-definition revision is registered and the ECS service is updated for a rolling deployment. The deployment stage completes after health checks pass, followed by the result notification.
Identity, runtime configuration & communication
- AWS access
- GitHub Actions uses OIDC-based IAM roles. Systems Manager is part of operational access; it is not the identity provider.
- Runtime secrets
- Secrets Manager supplies secrets when application containers start. The public overview includes no secret values, identifiers, or configuration samples.
- Release availability
- Rolling updates are used to maintain application availability while tasks are replaced. This overview does not claim a measured uptime or a guaranteed zero-downtime result.
- Team visibility
- A Teams webhook reports the workflow outcome. It communicates the result of migration and deployment checks rather than replacing those checks.