a. Execution environment
Ansible-managed runner hosts
I prepared one runner VM per environment, with host automation, users, permissions, connectivity, registry access and managed identity dependencies.
Enterprise experience
Thoughtworks · Client engagement
Health Promotion Board
Azure/AKS platform support, environment migration and CI/CD rebuilding.
Migration outcome
Bamboo-to-GitLab workflows rebuilt. Environment and scanning dependencies resolved. Migration completed.
01 / Role & daily work
Supporting the platform and its development teams.
As a Thoughtworks DevOps Engineer on Singapore’s Health Promotion Board (HPB) engagement, my role combined day-to-day Azure and AKS support with larger environment and delivery changes. I worked directly with development teams and was the main hands-on engineer for the environment migration and Bamboo-to-GitLab rebuild.
Day-to-day platform and delivery support
I handled routine operational work for the Azure and AKS environments, helped developers investigate environment and delivery issues, and worked through pipeline problems to get build and deployment workflows running. This included reviewing scripts and configuration and checking changes with the teams.
A major delivery within that role
The migration covered system integration testing (SIT), user acceptance testing (UAT) and production environments, moving to isolated AKS clusters and rebuilding Bamboo workflows in GitLab CI/CD. I was the main hands-on engineer responsible for this work, with another DevOps engineer contributing under my guidance.
02 / Pipeline migration
Rebuild delivery for the migrated environments.
Moving from Bamboo to GitLab CI/CD meant rebuilding both the workflow and the environment it depended on. The required delivery tasks and security checks had to work across SIT, UAT and production under the client’s access restrictions.
I reviewed the old steps, dependencies and expected results, then rewrote most of the scripts. Shared functions became reusable GitLab steps, with task-specific work kept separate. I was the main engineer for this migration and guided another engineer through some repeated work. I reused Helm deployment logic across environments and integrated client-provided functions such as image scanning.
b. Delivery workflow
Reusable steps and required checks
I rebuilt the path from code scanning and application builds to Helm deployment, application-status checks and DAST, including the FOD SAST/DAST integration.
c. Migration sequence
Validate SIT/UAT before PRD
I completed and validated the SIT/UAT migration work before progressing production, reusing the prepared automation and pipeline work.
d. Supporting services
Vault and private endpoints
I implemented Vault integration for startup credential injection and developed its backup approach. I also introduced private endpoints for internal services.
The migration was completed after the environment, access and scanning dependencies were resolved and the required validation passed.
Runner preparation, SIT pipeline and environment differencesWhy rebuild the scripts instead of copying the Bamboo steps?
03 / Cross-team coordination
Working across team boundaries.
Routine releases did not require the external service-request process. SIT deployed automatically; UAT and production required manual confirmation. We coordinated release timing with the Product Owner (PO).
Some migration tasks and operations or queries in restricted environments required coordination outside the team. The client’s support teams handled the relevant service requests, which often took several days. I followed up on these requests and used the returned information to progress the environment and migration work.
Where cross-team coordination was needed
My cross-team coordination
Coordinate external actions and follow up on results
Migration setup · Restricted-environment operations and queries
Service requests
Execution results
Client support teams
Execute restricted operations and queries
For these tasks outside the team’s access, client support teams executed approved requests and returned results for the environment work.
Coordination through the client
Access and setup
Client, support teams and provider
Enable scanning-service access for the migration
During the migration, I coordinated with the client, who contacted the relevant teams and provider for the subscription and access needed to set up mandatory scanning.
A migration setup blocker
Fortify on Demand access and setup
Static and dynamic application security testing (SAST and DAST) were mandatory for this project. During the migration, obtaining the subscription and access needed to set up Fortify on Demand became a major blocker.
I provided the issue details and requirements, then followed up through the PO and support team to obtain help from the provider. The provider resolved its managed part. Required access and configuration were completed, validation passed and the migration finished successfully.
04 / Delivery outcome
The migration was completed.
The environment and delivery rebuild progressed through the required access, configuration and validation work. I combined hands-on implementation with colleague guidance and coordination with the client’s support teams.
Sharing practical Terraform guidance
I also prepared Terraform plan and Azure resource-import materials and shared them with client staff and teammates. Using examples, I explained how configuration, Terraform state and actual Azure resources can differ, and why a successful import still needs careful plan review.
About this retrospective
This retrospective draws on my working notes, Terraform teaching materials and project experience.
Reviewed and updated on .