- 5x
- Faster deployment
- 66.6%
- More features released
- 1
- DevOps engineer
Traders Alloy built a web-based financial decision support tool for people managing their own stock portfolios. The team shipped every release by hand. A vendor had been hired to build a CI/CD pipeline and couldn't get one running.
Brocoders was brought in after that. We audited the code and the delivery processes, built the pipeline on Jenkins for backend and frontend, and trained the client's team to run it.
Traders Alloy at a glance
- Client
- Traders Alloy, a web-based financial decision support tool
- Industry
- Fintech
- Location
- Stockholm, Sweden
- Client since
- 2020
- What they came for
- A CI/CD pipeline a previous vendor couldn't deliver
- Service
- Software audit, then DevOps
- Environment
- A DigitalOcean cloud server and an on-premises physical server
- Pipeline
- Jenkins, with Blue Ocean and Declarative Pipeline
- Scope
- Backend and frontend, across multiple environments
- Brocoders team
- 1 senior DevOps engineer
- Handover
- The client's team was trained to run the pipeline
Why Traders Alloy was deploying by hand
Releases at Traders Alloy were manual. The previous vendor hadn't managed to get a CI/CD pipeline up, and the deployment cycle was slow.
Manual releases cost a fintech product team engineering hours on every release, and they leave room for a mistake.
The team wanted three things: features delivered faster, automated testing in the cloud, and test results somewhere the whole team could read them.
What we audited before building the Traders Alloy pipeline
The audit came first. We reviewed the code and the delivery processes before writing any pipeline configuration. That step is sold on its own today as the software audit. The closest module to what this engagement needed is the deploy and environment assessment: how the system is built, deployed and run, and what each environment needs to stand it up.
The build had one hard constraint. Traders Alloy ran on two machines, a DigitalOcean cloud server and a physical server on-premises. The pipeline had to use both fully without overloading either.
Why we built the Traders Alloy pipeline on Jenkins
We proposed several tools and chose Jenkins. It's open source, it's reliable, and it's easy to configure and manage.
We installed it on the client's test server.
Two Jenkins components are in the stack. Blue Ocean is Jenkins' visual pipeline view. Declarative Pipeline keeps the pipeline definition in a file in the repository.
What the Traders Alloy pipeline does
- One pipeline, backend and frontend
- Automated tests in the cloud
- Test results in Jenkins
- Delivery to multiple environments
- Slack notifications
- Role-based permissions
- Pipeline defined in code
Both sides of the product build and deploy from the same pipeline, covering the whole development lifecycle. The test suite runs in the cloud and posts pass and fail results where the whole team can read them. Deployments and test runs go to Slack, and who can deploy and who can read test reports are separate permissions. More in our guide to CI/CD on a SaaS project.
Handing the pipeline to the Traders Alloy team
Our senior DevOps engineer showed the Traders Alloy team how to run, test and deploy through the pipeline themselves. Showing them was part of the task.
We gathered feedback from the team afterwards. Slack notifications for deployments and tests were added as a result.
The team then ran the pipeline themselves, deploying several times a day, with an occasional helping hand from our engineer. Brocoders stayed available for the work that continued in the following years.
Results at Traders Alloy
- Deployment was 5x faster than the manual process it replaced
- The team released 66.6% more features
- Several deploys a day, where each release used to be a manual job
- Bugs were caught by the automated tests
- The client's team ran the pipeline themselves after the handover
Senior DevOps engineer
The stack behind the Traders Alloy pipeline
- Jenkins, self-hosted on the client's test server
- Blue Ocean, the Jenkins visual pipeline view
- Declarative Pipeline, pipeline configuration held in the repository
- DigitalOcean, the cloud server running the product
- An on-premises physical server
- Slack, for deployment and test notifications
More of our DevOps work.
FAQ
Yes, and that's what this engagement was. Every project takeover here starts with the same audit of the code and the delivery processes, and the build follows it. At Traders Alloy we audited first, then built the pipeline on Jenkins for backend and frontend, and then trained the team to run it.
For a new pipeline on a project already hosted with a cloud provider, usually not. GitHub Actions and GitLab CI are less work to set up and there's no server to maintain. Jenkins still earns its place in three cases: you run your own hardware, the build has to stay inside your network, or you want the pipeline on infrastructure you control. Traders Alloy had a physical server on-premises, so it fit.
Yes. Traders Alloy ran on both, a DigitalOcean cloud server and a physical server on-premises, and the pipeline had to use both without overloading either. That's a capacity question before it's a tooling question, and it's the kind of constraint the audit is there to find. If you're weighing a move to the cloud as part of the same decision, our guide to lift and shift against refactoring covers the trade-offs.
That's what the handover is for, and it's part of the job rather than an extra. Our engineer trained the Traders Alloy team to run, test and deploy through the pipeline themselves. They then ran it on their own, deploying several times a day, with an occasional helping hand from us while the engagement lasted.
Deploying to production and reading a test report are different levels of trust. On a financial product that difference is worth enforcing in the tool itself, so a mistake or a compromised account can't push a release. Traders Alloy's pipeline separates the two: who can deploy, and who can read test reports, are set as separate permissions.
Deployments and test runs. Slack wasn't in the first version of the pipeline. We gathered feedback from the team after launch, and notifications for deployments and tests were added as a result, so the whole team sees a release or a failed test run in the channel they already use.
If a pipeline has stalled, or every release is still manual, start with a software audit of the code and the delivery processes. Fixed price, five or ten business days, and a keep, refactor or rebuild decision per module.
