Our Journey to Continuous Delivery at Grab (Part 1)

Summary

Around the end of 2018, Grab's backend architecture consisted of roughly 270 services managed through fragmented, manual deployment workflows. Engineers copied release parameters between build logs, wiki pages, Slack bots, and multiple Jenkins jobs, leading to high operational friction and an average of 10 business days between production updates for a service. To streamline delivery, Grab built Conveyor, an internal automation platform built on top of open-source Spinnaker. Conveyor introduced a custom user interface focused on pipeline visibility and a pipeline-as-code DSL called Artificer using Jsonnet files in the monorepository. The platform automatically registers build artifacts with commit metadata to eliminate manual parameter entry and automatically provisions integration, staging, and production pipelines.

Context

Around late 2018, Grab operated about 270 backend services with a lengthy, manual deployment process involving copy-pasting release versions across Jenkins jobs, wiki release notes, and Slack bot scheduling, averaging 10 business days between service updates in production.

Approach / What changed

Grab built Conveyor, an internal platform on top of Spinnaker, featuring a simplified dashboard interface, artifact registration directly from CI jobs, and an in-repo Jsonnet-based pipeline-as-code DSL interpreted by a tool named Artificer.

Takeaways

• In 2018, Grab averaged 300 staging deployments per business day across roughly 270 services, but only about 10% (28 per business day) reached production.
• Conveyor uses Artificer to interpret service-level conveyor.jsonnet files on every commit, allowing services to onboard with minimal configuration specifying service and group names.
• Artifacts generated during Jenkins CI runs are automatically registered with metadata in Conveyor, eliminating manual copy-pasting of build log versions for deployments.

Related reading

• Grab · Jun 29, 2020

  How We Built Our In-house Chat Platform for the Web

  Grab extended its in-house chat platform to the web to support its internal Customer Support portal. Because the existing TCP gateway only supports unicast connections with one active connection per user, opening multiple browser tabs would repeatedly disconnect previous tabs. Rather than undertaking a complex migration to multicast connections on the server, the team adopted a hybrid client-side strategy using SharedWorker and BroadcastChannel APIs. The implementation uses a SharedWorker to maintain a single WebSocket connection per domain while a BroadcastChannel syncs events across all open tabs. A custom wrapper over the worker manages version transitions during deployments to avoid race conditions across tabs.

  Vasu Krishnamoorthy

• Grab · Jan 20, 2022

  Biometric authentication - Why do we need it?

  Grab addressed the vulnerabilities and costs associated with SMS one-time passwords and PINs by implementing device-level biometric authentication. The architecture pairs device biometric sensors with hardware secure enclaves to protect private keys separately from the main operating system. During enrollment, Grab generates a public-private key pair using SHA512withECDSA, authenticates the user locally, and stores reference identifiers in encrypted device storage. HellfireSDK verifies that the device is not rooted, ensuring raw biometric data never leaves the handset. Early experimental runs indicate an adoption rate exceeding 90% and a login success rate near 90%.

  Chad Burgess

• Grab · Mar 1, 2022

  Abacus - Issuing points for multiple sources

  Grab needed a centralised points management architecture to issue loyalty points across a growing catalog of products, membership tiers, and external partner exchanges. To address this, the engineering team built Abacus, an issuance platform designed to process millions of daily transactions with high availability. The system ingests completed transaction streams or API calls, dynamically computes points via configured multipliers, and passes calculations through Amazon Simple Queue Service queues. Once the Point Awarding module updates a persistent ledger, Abacus notifies consumers, emits events to Kafka for downstream consumers, and recalculates rolling point expiration dates.

  Chandrakanth

• Grab · Oct 30, 2020

  Keeping 170 Libraries Up to Date on a Large Scale Android App

  Grab's passenger Android superapp relies on more than 170 in-house and open-source libraries, incorporating five to ten library bumps into each weekly release. Although developers often avoided updates due to the fear of leaking defects or crashes into production, the engineering team established a risk-assessment framework based on codebase usage and the volume of incoming changes. To minimize update diffs and avoid accumulating large issues, libraries are updated incrementally on a weekly cadence matching upstream release schedules. Automated UI test cases written in Gherkin syntax execute on CI for every merge request, while high-risk bumps trigger targeted QA manual testing. This structured updating process prevents defect leakage while keeping the application compliant with evolving Google Play target API requirements.

  Lucas Nelaupe