BRIMEN

New Engineering Journey

Brimen 2.0

New Engineering Journey

Actually

Brimen 5.0

BRIMEN 5.0

New Team Structure

SDLC

Future Architecture Insight

Planned Development

BRIMEN 5.0 - New Team Structure

With the new added team members Brimen will new restructuring into a proper engineering team with different squads, each squad will be responsible for different areas of the product and will have their own goals and objectives.

BRIMEN 5.0 - New Team Structure

Ruben

Team Lead / SAD

Team 1

Legacy Migration

Team 2

New System

Team 3

Go Migration

Azril · Steven

Bunaya

Deni

Wahid

Bagus

Ainun

Vidha

Amelia

Faizal

Fardan

Team Hore - Lead Engineer

Banyu

DevOps

Hani

Technical Writer

SDLC FLOW

One lifecycle, eleven checkpoints. Dedicated slides below explain the key stages in detail.

1. Grooming

Backlog refinement and sizing.

2. Brainstorming

Solution options and risks.

3. System Design

Architecture and module contracts.

4. Reviewing System Design

Cross-team quality and feasibility.

5. Dev (Development)

Implementation and integration.

6. Deploy to release/staging

Release candidate deployment.

7. QA Testing

Validation against requirements.

8. Fix Issues (Development)

Defect fixes and stabilization.

9. UAT / Stakeholder Validation

Business acceptance check.

10. Production Deployment

Go-live rollout.

11. Monitoring & Feedback

Operate, observe, improve.

Detailed focus: The next dedicated slides focus on Grooming, System Design & Review, and Development execution.

Quality loop: QA feedback still loops into fixes, then back to staging and retest.

SDLC process overview and key feedback loops

Grooming & Brainstorming

Developers, QA, and frontend align on PRD and Figma before implementation starts.

What Happens Inside

Read PRD and inspect Figma flow together to lock feature intent.
Break each page request into concrete tasks, for example list endpoint and create endpoint.
Check external dependencies and integration points needed to deliver the feature.
Decide whether existing endpoints can be reused, updated, or created as subtasks.

Outputs and Exit Criteria

Task list is complete with dependency status for each item.
Existing API reuse or update decision is documented.
Missing API creation is captured as subtask with owner and acceptance criteria.
Team has one shared understanding before design starts.

Grooming workflow from PRD and Figma into tasks and API dependency checks

System Design & Review

After grooming, developers draft technical design and review choices together with technical writer support.

What Happens Inside

Create database schema updates, sequence diagrams, and module boundaries.
Describe API contracts, failure cases, and operational assumptions.
Collaborate with technical writer in parallel to keep design artifacts readable.
Run cross-team review to challenge feasibility, risk, and maintainability.

Outputs and Exit Criteria

Design package is approved with clear architecture choices.
Trade-offs and open risks are explicitly recorded.
Implementation sequence is clear for frontend, backend, and QA handoff.
Team alignment is complete before coding starts.

System design and review collaboration with schema and sequence diagrams

Development (Part 1)

Development starts in dedicated feature branches, then merges through pull requests into releases/development.

Branching and Implementation

Every developer works on a dedicated branch with naming convention like feat/inventory-list or feat/pelunasan-webhook.
Code is implemented from approved design while keeping commit history clear per feature scope.
When feature work is done, open a pull request to releases/development as the integration branch.
Run checks and reviews before merge to avoid instability in shared integration flow.

Promotion Path to QA

If one end-to-end happy flow is ready, promote build to releases/staging for QA testing.
Staging acts as release validation area before broader rollout decisions.
Any defects discovered in this path return to development for fixes and redeploy.

Development branch and pull request flow to releases development and releases staging

Development (Part 2)

QA validation runs while feature work continues in parallel, with feature flags protecting risky flow changes.

Risk Control During Ongoing Development

If a change can impact existing user flows, gate it behind a feature flag.
Use explicit config naming, for example USE_CHECKOUT_CALCULATION_V2_IS_ENABLED=false or true.
Enable flags progressively after QA confidence is established.
Keep rollback simple by switching flag state when required.

Parallel Continuation and Team Cadence

While QA tests one delivered flow, developers continue remaining feature work in parallel.
Defects and enhancement findings are fed back quickly to active branches.
Team keeps delivery throughput high without blocking all development on one QA cycle.
Release confidence grows through repeated test, fix, and feature-flag control.

Feature flag and parallel development loop while QA validation runs

DAY TO DAY ACTIVITY - DEVELOPER WORKFLOW

Work from Jira Task -> Branch -> Code -> Done -> Add Proof and Comments

1. Go to Your Jira Task

Open assigned Jira task, read scope, and confirm acceptance criteria before coding.

2. Create a Branch

Create a branch in repository using naming convention, for example feature/INVC-1234-inventory-list.

3. Develop and Test

Implement changes, run tests locally, then commit and push with clear task-linked messages.

4. Mark Task Done

Set task as done when implementation is complete and open PR if required by team flow.

5. Add Comments and Proof

Add Jira comments and proof of work such as API response, test result, or UI screenshot.

Definition of done: code delivered, validated, and proof posted on the Jira task for visibility.

Developer Day-to-Day Diagram

Reference visual for the daily task-to-proof execution cycle.

Day to day developer workflow from opening Jira task, creating branch, developing and testing, marking task done, and posting proof in Jira

Use this as an execution checklist from assignment to reporting.

DAY TO DAY ACTIVITY - QA WORKFLOW

Test Feature → Send Proof to Jira Task · If Bug Found → Create Issue → Fix → Verify → Send Proof Again

1. Pick What to Test

Open your assigned Jira task (Main Task or Subtask). Read the task details and focus on one feature at a time.

2. Identify Feature to Test

Read task details and acceptance criteria to understand the feature scope, objectives, and expected behavior.

3. Test the Feature

Execute test cases on the target environment. Verify list loads, filters work, pagination is correct, and data is accurate.

4. Evaluate Result

Working as expected → Done. Bug found → Follow the Bug Flow. Document actual vs expected behavior clearly.

5. Send Proof to Jira

Add comment on the same task with UI screenshot or API response, mention the feature tested, and update status if done.

Definition of done: feature validated, proof posted on the Jira task. If a bug is found, create an issue and follow the Bug Flow below.

QA BUG FLOW

Create Issue → Developer Fixes → QA Verifies → Send Proof → Close Issue

B1. Create Bug / Issue

Create a bug in Jira with steps to reproduce, actual vs expected, environment, and screenshots or logs.

B2. Assign & Link

Assign to the related developer and link the bug to the original Main Task or Subtask and the feature tested.

B3. Developer Fix — Branch

Developer creates a branch (e.g. bug/INV-201-fix-null-filter), codes the fix, commits, pushes, and opens a PR.

B4. Proof of Fix (Dev)

Developer comments on the bug issue with what was fixed, how it was fixed, and screenshots or logs as evidence.

B5. QA Verify Fix (Retest)

QA retests the feature against original test cases, related scenarios, and regression paths to confirm the fix.

B6. QA Update Result

Fix verified → mark Done. Still an issue → re-open or comment with details. Loop back to B2 or create a new bug.

B7. QA Send Proof to Bug Issue

Add comment on the bug issue with what was retested, test results, screenshots or logs, and update status to Done.

B8. Close Issue

Close the bug issue after verification is confirmed. Issue is fix-verified and confirmed complete.

Still an issue after B6? Re-open or comment with details, then loop back to B2 or create a new bug ticket.

QA Day-to-Day Diagram

Reference visual for the QA daily task-to-proof execution and bug flow cycle.

QA day to day workflow: pick task, identify feature, test, evaluate result, send proof; bug flow: create issue, assign, dev fix branch, proof of fix, QA verify retest, update result, send proof, close issue

Use this as a daily checklist from test execution to bug resolution and reporting.

Future Architecture Insight

CI/CD Pipeline · Bamboo · Bitbucket · Rancher

🌿 Branch Strategy

feature/* Feature

releases/development Dev

releases/staging Staging

releases/piloting UAT / Piloting

releases/production Production

All merges via Pull Request

⚙️ CI/CD Pipeline (Bamboo)

1 Code Commit — Push / PR to Bitbucket

▼

2 Build — Compile, Unit Test, Dependency Check

▼

3 Test — Integration Test, Quality Gate

▼

4 Security Scan — SAST / DAST, Vulnerability Scan

▼

5 Build Image — Docker Image Build & Tag

▼

6 Push Image — Push to Container Registry

🚀 Deployment (Rancher)

Development

Auto-deploy on merge · Feature flags ON/OFF

Staging

Integration & system testing · Feature flags for unrelated features

UAT / Piloting

Uses PRODUCTION environment (DB, Redis, MQ) · Final validation

Production

Blue/Green or Rolling Update · Zero manual SSH · 100% automated

🔀 Trunk-based Dev 🔃 PR-based Workflow 🤖 Automated Everything 📦 Immutable Images 🌍 Environment Promotion 🔁 Backward Compatibility 🧪 Production-like Validation 📊 Observability & Rollback

Stack: Bitbucket Bamboo Rancher Docker Registry Kubernetes SonarQube

CI/CD Architecture Diagram

Bamboo + Bitbucket + Rancher — full pipeline topology

Full CI/CD pipeline architecture diagram showing Bitbucket branch strategy, Bamboo pipeline steps, container registry, and Rancher deployment clusters for Dev, Staging, UAT/Piloting, and Production

Future Architecture Insight

Microservices · Kong · gRPC · MySQL · Redis · RabbitMQ · OTel + Elastic Stack

🔀 API Gateway — Kong

🔐 JWT Authentication & Validation

⚡ Rate Limiting

🔁 Request Routing (Proxy)

🔌 Plugins — Logging, Transform, Security

Client → HTTPS → Kong → HTTP → Services

⚙️ Microservices

Document Service

REST API (HTTP) · gRPC Server

Storage Service

REST API (HTTP) · gRPC Server

Management Service

REST API (HTTP) · gRPC Server

Inter-service communication via gRPC

🗄️ Data & Messaging

🐬 MySQL Cluster — 1 Primary, 2 Replicas (Async Replication)

🔴 Redis Cluster — Cache · Session Store · Rate Limit Store

🐇 RabbitMQ — Exchanges → Queues → Consumers

🔑 HashiCorp Vault — Secrets ⚙️ Configurations & Certificates 📡 OpenTelemetry — Traces, Metrics, Logs (OTLP) 🔍 Elasticsearch & Kibana 📥 Logstash / Beats (Ingestion)

Stack: Kong Golang gRPC MySQL Cluster Redis Cluster RabbitMQ HashiCorp Vault OpenTelemetry Elastic Stack

Microservices Architecture Diagram

Kong · gRPC · MySQL · Redis · RabbitMQ · OTel + Elastic Stack

TASK REPORTING / STAND-UP

Regular updates to keep the team aligned and transparent

📅 Schedule

Every Monday & Thursday

Reporting required from:

Developers
QA
DevOps

🎯 Purpose

Share progress
Surface blockers early
Align priorities
Track commitments

📋 Where to Report

Jira Project → Task Reporting / Stand-up

Dedicated Section / Epic / Custom Field
or Confluence Page linked in Jira

🔔 Important Guidelines

Be specific and factual
Use dates (DD/MM) for what's done
List items under each day
Keep it short and update consistently

TASK REPORTING / STAND-UP

Reporting Format (use this for every update)

1. What Has Been Done List tasks completed with date and details.

Date (DD/MM)	Task / Work Done
13/05	- List Item - Detail Item (UI) - API: GET /items (with pagination & filter)
14/05	- Update Item - API: PUT /items/{id} - UI: Edit Item modal
16/05	- Fix: Item status not updating
…	…

2. What To Do List tasks planned or in progress.

Create Invoice
Update Invoice
…

Reporting Flow

Team Member Updates the report on Monday & Thursday

↓

Add to Reporting Section Use the format: What has been done · What to do

↓

Team Visibility Everyone can see updates and progress

↓

Follow-up in Stand-up Discuss blockers, dependencies, and next steps

Example Report (Developer)

✅ What Has Been Done

Date (DD/MM)	Task / Work Done
13/05	- List Item (UI) - API: GET /items (pagination & filter)
14/05	- API: PUT /items/{id} - UI: Edit Item modal
16/05	- Fix: Item status not updating
…	…

🔵 What To Do

Create Invoice
Update Invoice
Add invoice items
…

PLANNED DEVELOPMENT

4 Main Initiatives. Aligned Teams. Clear Focus.

🚀

Main Features
Planned Development

👥

Teams Involved
Aligned & Focused

📅

Upcoming Phases

Fase 5 – Fase 6
Delivery Roadmap

🎯

1 Goal

Deliver Value
On Time, Together

#	Feature / Initiative	Description	Phase	Team	Key Benefits
1	Pelunasan Team 3 (Starting to use Golang)	Requirement dari APP dengan landasan nota dinas BRIMEN Legacy ditutup	Fase 5	👥 Team 3	Menyelesaikan requirement Pelunasan dari APP Penutupan landasan nota dinas pada BRIMEN Legacy
2	Migrasi BRIMEN Legacy Team 1	Migrasi database dan NFS untuk BRIMEN Legacy	Fase 5	👥 Team 1	Modernisasi infrastruktur data Peningkatan performa & keandalan sistem
3	Dokumen Transaksi with QLOLA Integration Team Hore	Dokumen operasional (DHE) dengan integrasi ke QLOLA	Fase 5	👥 Team Hore	Digitalisasi dokumen operasional (DHE) Integrasi QLOLA untuk proses yang lebih efisien
4	Modul Korporasi Team 2	Mampu integrasi dengan BRISPOT	Fase 6	👥 Team 2	Penguatan modul korporasi Integrasi dengan BRISPOT