EXANTE, a licensed international broker, recently delved into how it overhauled its delivery process for a business-critical CRM system — moving away from manual Saturday deployments towards a unified, automated pipeline now running across more than 30 services.
The scale of the problem
The system at the centre of this effort — exante-crm — underpins nearly every part of the business: client operations, document management, compliance, and a web of external integrations.
Its architecture reflects years of product growth: more than 60 Django applications in a single repository, three PostgreSQL databases, six Celery queues backed by Redis, 10+ white-label brands, 15+ external integrations, and seven production environments running across separate Kubernetes (GKE) clusters in different jurisdictions. A companion service, crm-script, handles background jobs using the same codebase and must always run in lockstep with the main application.
What was going wrong
The problems were cumulative. Jira tickets were filled in manually and inconsistently — sometimes not at all. Release windows tied deployments to specific calendar days, meaning code accumulated between releases and each deployment grew larger and riskier. Post-deployment checks were carried out by hand, and there was not clear visibility.
Regulatory pressure sharpened all of this. As a licensed broker operating across multiple jurisdictions, EXANTE is subject to change management scrutiny from external auditors. Those auditors want to know who deployed a given version, when, why, and who approved it — documented, not reconstructed from memory. With a manual process, answering those questions routinely turned into hours of investigative work. The crm-script alignment issue added further risk: when background job versions drifted from the main application, failures only surfaced hours later.
Building the new process
The team’s approach was deliberately incremental, beginning with a non-critical service before gradually expanding to the full CRM. The resulting flow is built around a single manual action: a developer clicks a deploy button for the target environment. Everything before that — code review, merge request approvals, access controls — remains human-controlled. Everything after it is automated.
When a Git tag is created, a pipeline kicks off covering image builds, linting, tests, and dependency scanning. A child pipeline then runs through four stages: Prepare (creates a Jira ticket and opens a Slack thread), Deploy (commits to the Flux repository), Verify (waits for rollout completion and runs standardised checks), and Finish (marks the ticket “Released” or “Rolled back” and updates Slack). A post-release stage automatically updates crm-script to keep versions aligned.
The Verify stage answers a specific question: is the application alive? It checks pod status, image tags, health endpoints, and scans logs for critical errors. It is not a substitute for functional testing — automated smoke tests covering core business scenarios are already in development as the next validation layer.
Results and honest limitations
Deployments are no longer tied to specific days for most environments, reducing code accumulation between releases. Audit preparation that previously took hours now takes a single query. Engineers are freed from manually filling tickets and clicking through pages post-deployment.
The team is equally open about what the process does not solve. Verify confirms availability, not business logic — hence the smoke test work in progress. Some services require additional configuration beyond the shared template, and if Jira or Slack goes down, those parts of the automation degrade, though deployment itself continues via Flux.
For more insights into Exante, read the full story here.
Copyright © 2026 FinTech Global
