DevOps Services in Riyadh, Saudi Arabia

Banking / Digital Banking

A Saudi digital bank (SAMA-licensed, launched 2 years prior — 450,000 retail customers, 120 employees, 40 engineers) deployed its mobile banking app through a manual process that was slow, error-prone, and non-compliant with SAMA expectations. The deployment process: an engineer manually building the application on their laptop, copying build artifacts to a shared server, another engineer manually deploying to staging for testing, QA team manually testing for 3-5 days, a senior engineer manually deploying to production during a weekend maintenance window, and the operations team manually verifying the deployment through a checklist. Problems: deployment frequency (releasing every 6-8 weeks — competitors releasing weekly. Feature requests from business taking months to reach customers. The product team frustrated by the pace — "We design features in days, engineering builds them in weeks, but deployment takes another month"), deployment failures (23% of production deployments resulting in rollback or hotfix — caused by: configuration differences between engineer laptops and production, missing database migrations, untested integration points, and environment-specific bugs not caught in manual testing), SAMA compliance gaps (SAMA examiner feedback: "Change management documentation is incomplete and inconsistent. Security testing evidence is not systematically captured. Disaster recovery capability has not been tested." The bank operating under a remediation timeline — 6 months to address findings or face operational restrictions), and weekend deployment burden (every production deployment requiring 4-6 engineers working Saturday (the Saudi weekend) — manual deployment, monitoring, and potential rollback. Engineers working 12-hour deployment weekends 6-8 times per year — contributing to attrition in a tight Saudi engineering talent market).

We built a comprehensive DevOps platform over 14 weeks: CI/CD pipeline (weeks 1-6): automated build, test, and deployment. GitLab CI (self-hosted on Saudi infrastructure) managing the entire pipeline. Build: reproducible builds in Docker containers — eliminating the "works on my machine" problem. Every build producing identical artifacts regardless of which engineer triggered it. Automated testing: unit tests, integration tests, API contract tests, and end-to-end tests running automatically on every code push. Test results: attached to the pipeline run as evidence for SAMA change management. Security scanning: SAST (SonarQube), SCA (Snyk), container scanning (Trivy), and secrets detection (GitLeaks) integrated into every pipeline run. Security findings: categorised by severity — critical/high blocking the pipeline, medium creating Jira tickets, low logged for tracking. SAMA change management: the pipeline automatically creating a change record in Jira Service Management when a deployment to production is initiated — attaching: the list of changes (git commits since last deployment), test results (all test suites with pass/fail counts), security scan results (all scanners with findings summary), deployment plan (which services are being deployed, in what order), and rollback plan (specific steps to revert if issues are detected). Approval: routed to the designated change approver (the CTO for all changes during the initial phase, then delegated to senior engineers for standard changes after 3 months). Deployment automation (weeks 4-10): zero-downtime, zero-weekend deployments. Kubernetes (EKS on AWS Bahrain) hosting all application services. Blue-green deployment: new version deployed alongside current version — traffic switched after automated health checks confirm the new version is healthy. Rollback: instant — traffic switched back to the previous version if any metric degrades. Canary deployment: for higher-risk changes — 5% of traffic routed to the new version, metrics compared against the stable version, and automated promotion to 100% if metrics are healthy (or automatic rollback if not). Database migrations: automated using Flyway — migration scripts versioned with the application code, applied automatically during deployment, with rollback scripts prepared for every migration. Environment management: staging environment automatically provisioned as an exact replica of production (same Kubernetes configuration, same database schema, same external service connections via service stubs) — eliminating environment differences that caused 60% of previous deployment failures. Monitoring and incident response (weeks 6-12): Arabic-aware observability. Prometheus + Grafana: application and infrastructure metrics — custom dashboards for: application health (response times, error rates, throughput per API endpoint), infrastructure health (CPU, memory, pod count, node health), business metrics (active users, transactions processed, account openings — the metrics the CEO and SAMA care about), and deployment tracking (when was the last deployment, what changed, who approved it). Arabic alerting: PagerDuty configured with Arabic alert messages sent via WhatsApp — the on-call engineer receiving alerts in Arabic with clear escalation paths. Runbooks: incident response procedures documented in Arabic — step-by-step guides for common issues (database connection exhaustion, high API latency, payment gateway timeout) enabling the on-call engineer to resolve issues without escalation. Disaster recovery (weeks 8-14): SAMA-compliant DR. DR environment: warm standby in a separate AWS availability zone — continuously synchronised with production through database replication and shared container registry. Automated failover: Route 53 health checks detecting production failure and switching traffic to DR within 5 minutes. DR testing: automated quarterly DR drill — the DR environment taking production traffic for 2 hours, metrics compared against baseline, and DR test report generated for SAMA documentation.

The DevOps platform launched after 14 weeks. Deployment frequency: from every 6-8 weeks to twice per week — a 6-8x improvement. The product team delivering features to customers within days of completion instead of months. Deployment success rate: from 77% to 99.2% — the 23% failure rate nearly eliminated through automated testing, environment parity, and automated rollback. Weekend deployments: eliminated — all deployments during business hours (Sunday-Thursday) with zero downtime. Engineers reclaiming their weekends — the bank's Glassdoor rating improving and attrition reducing. SAMA compliance: all examiner findings addressed within the 6-month remediation timeline. Change management documentation: automatically generated for every deployment — complete, consistent, and immediately available for examination. Security testing: systematic, automated, and evidenced. DR capability: tested quarterly with documented results. SAMA follow-up review: zero additional findings. Time to production: from 6-8 weeks (feature complete to customer-available) to 3-5 days. The reduction from automated testing (no 3-5 day manual QA cycle), automated deployment (no weekend scheduling), and automated change management (no manual documentation). Engineering productivity: engineers spending 30% less time on deployment-related activities — time reinvested in feature development. The 40-person engineering team effectively gaining 12 person-months of development capacity annually. Incident response: mean time to detect from 45 minutes (customer complaint-driven) to 2 minutes (automated monitoring). Mean time to resolve from 3.5 hours to 35 minutes (runbooks, automated diagnostics, one-click rollback). Financial impact: engineering productivity gain (12 person-months × SAR 30,000/month): SAR 360,000/year. Deployment failure cost avoidance (reduced rollbacks, hotfixes, weekend overtime): SAR 280,000/year. Customer impact reduction (fewer incidents, faster resolution): estimated SAR 450,000/year in retained customers. Total annual benefit: SAR 1.09M. Implementation cost: SAR 580,000. First-year ROI: 88%.