Existing delivery
Retain the required work.
Moving from Bamboo to GitLab CI/CD required reviewing the old steps, their dependencies and expected results. The workflow also needed prepared runner hosts and the project’s required security checks.
All engineering inquiries
Engineering judgment
Health Promotion Board / Pipeline migration decisions
Engineering judgment
& inquiry.
Restructuring delivery scripts, working within environment boundaries and completing a migration across several teams.
These answers bring together my project account and an AI-assisted review. The follow-up challenges identify the next questions I will work through using my engineering-judgment framework.
Context Question Judgment Follow-up
01 / The constraints
Change the workflow within the project’s boundaries.
Environment and responsibility boundaries
Work across restricted access.
SIT, UAT and production had separate runner hosts and restricted access between environments. Client support teams performed restricted operations; I prepared and coordinated the work needed for the migration.
02 / Questions & answers
Choices about structure, constraints and responsibility.
Each answer describes the work and reasoning established so far. The next challenge beneath it is marked for a future answer.
Script boundaries / Maintainability
Why did you restructure the scripts instead of copying the Bamboo steps into GitLab?
My answer
I reviewed what each step did, what it depended on and what result it should produce. The necessary tasks stayed, but scripts that mixed several responsibilities needed a different structure.
I rewrote most of the scripts, separating common functionality into reusable scripts and templates while keeping task-specific work distinct. This fitted the client’s approach to shared functionality and made the pipeline easier to follow.
For example, I reused the Helm deployment script across SIT, UAT and production. HPB also supplied shared functions such as image scanning, which I reused in the pipelines. I integrated those functions rather than writing them myself.
The technical deep dive includes my proposed design for shared deployment logic and environment settings.
Next challenge · Answer in preparation
When changing most of the scripts, how did you decide which behaviour had to stay, and how did you check that it was preserved?
Environment boundaries / Release approach
How did the project’s access restrictions shape your release approach?
My answer
Access between environments was strictly restricted. In this project, SIT, UAT and production each built and deployed from the same code for a given release version, rather than promoting one immutable package or image.
I worked within those boundaries when rebuilding the pipelines. SIT deployed automatically, while UAT and production required manual confirmation. For the migration itself, I completed and validated SIT/UAT before progressing production and reused the work already prepared.
The environment model shows the separate build paths and release controls.
Next challenge · Answer in preparation
With separate builds, what evidence would you require before accepting a release as consistent across environments?
Delivery ownership / Coordination
What did you own when some migration work required action outside your team’s access?
My answer
I mainly handled the migration and guided another engineer through some repeated scripts and steps. I prepared and coordinated restricted changes, while client support teams executed the operations outside our permitted access.
For the FOD integration issue, I supplied the details and requirements, followed up through the PO and support team, and used the agreed process to obtain vendor help. The vendor resolved its managed part. We completed the required configuration and validation, and finished the migration.
Next challenge · Answer in preparation