DevSecOps
Platform engineer who turns release days into non-events — CI/CD pipelines, security gates and release automation for banking-grade systems.
40+ repos · 5 artifact types · 3 environments · 1 gateway
Release pipeline stages: commit (git push), build (maven, gradle, npm), scan (trivy, sonarqube), approval gate (five-layer chain), deploy to SIT, promote to UAT, release to PROD with a release ledger.
scan · gate — fail closed
# this is all a service repo carries include: - project: 'core/pipeline-gateway' file: '/gateway.yml'
DevSecOps, Jakarta. I design and maintain the release machinery behind banking-grade systems — and I document the trade-offs, not just the wins.
artifacts I ship: jar · image · apk/aab · ipa · web bundle — one standard for all five
Sanitized descriptions — no hostnames, no tenant names, no internals. The engineering is real; the labels are not.
Webhook-driven orchestrator that turns issue-board movements into action: branch creation, merge requests, approval validation, deploy triggers and scan scheduling, with a state machine persisted in the issue itself.
A single repository holding every CI/CD definition: a gateway include that routes 40+ service repos to domain pipelines, shared stage templates per artifact type, and a codified rulebook the whole organization deploys by.
Self-built release management platform: deployment history, build and deploy triggering, scan results, environment promotion, secrets and audit in one UI — fed live by pipeline callbacks over server-sent events.
A GitLab issue board has almost none of what a regulated release needs: no approval chain, no phase enforcement, no persistent state, no deploy trigger. Instead of buying a tool, I made the board itself drive the pipeline. Engineers move a card; branches, merge requests, scans, approvals, deploys and audit comments happen by themselves — and every result is written back into the ticket.
before: approvals lived in chat, release state lived in one person's head, deploys were triggered from a terminal
no approval chain · no phase state · no trigger — just columns
phase badge · approval chips · bot comments · deploy trigger — the board runs the release
<!-- PIPELINE_STATE -->A retry command with substring matching let the bot trigger itself: hundreds of runaway comments across multiple tickets in one night. The fix is layered — four guards — and 25 regression tests keep it from recurring.
chatops // /retry · /sonarqube · /diff <domain> · /sync · /follow #iid · /summarypic · /notif — the board doubles as a command line; every command is anchored, gated by ticket status and bot-proof.
A release management platform I built and maintain: version drift between environments, build and deploy triggering, live console streaming, quality gates, secret changes, mobile test recordings and role-based access — on one page, updated in realtime. Below is an interactive replica with sanitized dummy data. Click anything.
before: five tools and one spreadsheet to answer "what runs in UAT right now?"
The replica UI is shown in English, exactly like the real product. Names, versions, hashes and paths below are sanitized dummy data — the behaviour, the layout and the numbers describing the platform itself are real.
The core question is "what differs between SIT and UAT?" — the release plan is generated only from services whose versions actually diverged, so nothing rides along by accident.
Pick services or paste a commit SHA; the platform resolves which services that diff touches, triggers the build, then streams queue, stages and console output back live.
Tag descriptions are composed from grouped tickets — features, bugfixes, hotfixes — plus config and secret changes, then applied to every repository in the group at once.
Three roles, per-project assignment, revocable API keys for pipelines, an audit log for every destructive action, and a platform-update button that redeploys the dashboard itself.
The idea I keep returning to: developers should never own pipeline plumbing. A four-line include routes every repository to its domain pipeline, and the standard evolves in one place.
before: every repo kept its own copy of the pipeline — fixing the standard meant editing 40 files
Project IDs map to domain pipelines in one config. Onboarding a new team means changing one include, not forking a pipeline.
GitLab CI and legacy Jenkins coexist behind the same stage contract and callback format, so migration is incremental instead of a big bang.
SIT → UAT → PROD moves are tag-and-merge operations with an append-only release ledger as the source of truth for what runs where.
click any node — the detail appears below the rail
| service | branch pair | status | mr |
| ledger-service | R1.0 → R1.1 | ✓ MERGED | view MR |
| mobile-bff | R1.1 → R1.2 | ⚠ CONFLICT — REBASE NEEDED | view MR |
| scheduler-job | R1.0 → R1.1 | — NO CHANGES | |
| auth-gateway | R1.1 → R1.2 | ✕ APPROVAL FAILED | view MR |
Hasil pemindaian ini dihasilkan oleh Semgrep yang dijalankan otomatis melalui pipeline DevOps, Temuan bersifat indikatif dan dapat mengandung false positive. Laporan ini ditujukan sebagai bahan analisis awal bagi developer — bukan pengganti pemindaian keamanan formal.
| category | service | critical | high | medium | low | status |
| FE | 12 | 0 | 0 | 0 | 0 | BERSIH |
| BE | 19 | 1 | 0 | 5 | 0 | TEMUAN |
| service | branch | quality gate | vulns | coverage |
| ledger-service | R1.1 | PASSED | 0 | 78.4% |
| mobile-bff | R1.1 | NOT PASSED | 2 | 61.2% |
| auth-gateway | R1.1 | PASSED | 0 | 83.0% |
| scheduler-job | R1.1 | NO ANALYSIS | — | — |
// dummy data in the report format my pipelines generate — names, domains and links are sanitized. The amber disclaimer is deliberate: a scanner that overclaims is worse than no scanner
// security is a gate, not a report — SAST on the merge path, SBOM per image, secrets fail closed
// the stage orchestrator was designed on paper before a line of code — 40 repos share one contract, so a new team onboards with a four-line include
// every helper ships with permanent debug logs — when production misbehaves, I read, I do not guess
// I hate copy-paste versioning more than I hate writing code: sync groups retag a whole release train consistently, next version suggested
The pipeline is only half of it. These are the settings that decide whether a service keeps running after it ships — and my part in them is not choosing the numbers. It is making sure the number that was agreed is the number that runs, in every repo, without drift.
Resource values started out copied from whatever service shipped last, because nothing measured them and nobody was asked for a number. If I set this up again, the contract would carry a measured baseline per artifact type, so the decision starts from an observation instead of an estimate — and the list of overrides stays short enough to read in one sitting.
Each decision, the alternative I rejected, and what it cost.
The tool list is what I used — this table is what I was thinking about.
| asset | threat | the gate that closes it |
|---|---|---|
| release integrity | merge without approval · phase skip | 5-layer chain + machine revert with an explanatory comment |
| production | manual "quick fix" deploy | deploy only fires from board state; watermark + running-pipeline refusal |
| secrets | plaintext in logs or repo | KV store, JWT-scoped pipeline auth, fail-closed, values masked in audit |
| artifacts | vulnerable or untraceable image | trivy + SBOM on the merge path; quality gate before promote |
| release record | "what runs where" disputes | append-only ledger + pipeline callbacks written back to the ticket |
No percentages — they cannot be falsified. Each skill carries a usage tier and a pointer to the project that proves it. Hover or tap a reference to see where the evidence lives.
gateway include routes 40+ repos; the 52-rule standard is versioned with the pipelines.proj-02
SSH deploy and rollback tooling for JAR and image paths.proj-02
29 legacy Groovy pipelines kept alive behind one stage contract during the dual-engine migration.proj-02
stage contract per artifact type; onboarding a team is one include, not a fork.proj-02
18 ChatOps orchestrators and ~330 unit tests, stdlib-only by constraint.proj-01
the release control plane: Express, SSE event bus, RBAC — three dependencies total.proj-03
shared pipeline logic and security-scan jobs as declarative Groovy.proj-02
AWR tuning tasks shipped from the same orchestrator repo that drives the board.proj-01
centralized per-domain SAST in the merge path, results commented back on the MR.proj-02
vuln+secret+config scanning on every image, HIGH/CRITICAL summarized in the build.proj-02
KV v2 with JWT-scoped pipeline auth; missing secrets abort the job, fail-closed.proj-02
CycloneDX SBOM archived alongside every container build.proj-02
image build and push on every backend deploy, incremental tags.proj-02
rolling deploys via rendered deployment manifests across three namespaces.proj-02
service lifecycle over SSH with dated backups and 5×10s verify retries.proj-02
append-only release ledger; promotion is tag-and-merge, reviewable in a diff.proj-02
five artifact types — jar, image, apk/aab, ipa and web bundle — each with its own stage contract behind one gateway.proj-02
where every mobile build lands: apk/aab and ipa produced by the pipeline are distributed through them for SIT and UAT testing.proj-02
built the platform's own machines from an empty image — Jenkins node, GitLab runner, app server, web server: install, configure, keep updated.proj-02
permanent debug logs in every helper; deploy callbacks stream into the dashboard over SSE.proj-03
anti-loop watermarks and the scan-fails=fails rule both exist because of real incidents.proj-01
per-artifact stage templates and rendered OpenShift manifests from one service map.proj-02
~330 tests covering routing, idempotency and merge races — written after incidents, not before.proj-01
education S1 Informatics — Universitas Tarumanagara
I design the architecture and the workflow — the diagram is drawn before the YAML is written.
I onboard and mentor engineers onto pipelines they now run without me.
Four projects I owned have been handed over — documented well enough to survive the handover.
Open to DevSecOps, platform engineering and developer-experience roles — on-premise or cloud, banking-grade or startup-speed.