Problem Statement
TransBnk operates a growing catalog of microservices across dev, QA, staging, prod, and DR environments in a heavily regulated BFSI setting, where every release must be traceable, security-checked, and auditable. Before adopting BuildPiper’s GitOps workflow, security scanning happened outside the pull-request loop, CI status was not visible to reviewers directly on the PR, and there was no single, traceable build artifact that moved consistently from a developer’s feature branch all the way through to DR. Promotions between environments relied on manual coordination rather than a governed, approval-gated pipeline, and the final step of merging validated code back into the release/prod branch after DR sign-off was a manual task that was easy to delay or miss. As TransBnk scaled its release volume, this combination of fragmented checks, ungoverned promotion, and manual release closure created compliance risk and slowed delivery — making a shift to a fully automated, Helm-based GitOps pipeline a business necessity rather than a nice-to-have.
Top 3 Achievements
Challenges
No automated security feedback inside pull requests
SAST checks were not wired into the PR workflow, so vulnerabilities in changed code surfaced late, well after a feature branch had already progressed toward a target branch.
CI/build status invisible on the PR itself
Reviewers had to leave the pull request and check separate CI dashboards to see whether a build had passed or failed, slowing down reviews and merges.
Change-level checks weren't backed by full-codebase validation
Lower-environment CI on a feature branch validated only the changed code; there was no guaranteed, extensive check across the entire codebase before a build was promoted further.
No single, traceable tag across environments
Builds moving through dev, QA, staging, prod, and DR lacked one consistent tag, making it difficult to guarantee that the artifact tested in lower environments was exactly what shipped to production.
Manual, ungoverned promotion across QA, staging, prod, and DR
Moving a build between higher environments depended on manual coordination between teams, with no consistent, approval-based gate to control who could promote a release and when.
Manual release-branch merge after DR sign-off
Once a release was validated in DR, merging that code back into the release/prod branch was a manual step owned informally by whoever remembered to do it, creating gaps in the audit trail.
Solutions
PR-triggered SAST pipeline with inline status
For every pull request from a feature branch toward a target branch, BuildPiper's lower-environment job templates clone the required SAST tools and scan only the changed code, using regex-based Git event triggers. Results are posted back as PR comments, and the PR is marked with a clear build pass/fail status — all before any tag is created.
Full-codebase CI gate on merge to the tagging branch
Once a PR merges from the feature branch into the tagging branch (e.g., dev), BuildPiper triggers an extensive CI run across the entire codebase — not just the diff — closing the gap between change-level and full-build validation.
Single tagged build, deployed via Helm to dev
The same build tag validated by the full CI run is deployed to the dev environment using Helm charts, establishing one traceable artifact as the starting point for every downstream promotion.
Release Package–driven promotion with approval gates
Using BuildPiper Release Packages, that same tag is promoted through QA, staging, prod, and DR through Helm-based deployments, with approval-based stages controlling every environment transition.
Governed, auditable environment-to-environment movement
Each promotion stage requires explicit approval before deployment proceeds, giving TransBnk a consistent, enforceable governance layer across every higher environment instead of ad hoc coordination.
Automatic post-DR release PR with owner assignment
As soon as the DR deployment completes, BuildPiper automatically creates a pull request to merge the validated code into the release/prod branch and assigns the application owner to complete the merge, removing the manual, easy-to-miss final step.
