Oney Bank France CI/CD Automation Journey
Submitted By Jenkins User Julien Schneider
A disruptive innovator in France’s financing and payment market, Oney Bank embraces automation in software development.
Organization: Oney Bank, https://www.oney.com
Project Website: https://www.oney.fr
Industry: Financial Services
Programming Language: Java, Node.js, Python, Angular
Platform: Docker or Kubernetes, Linux
Version Control System: GitLab
Build Tool: Maven
Community Support: Jenkins.io websites & blogs, Spoke with colleagues and peers
With Jenkins, developers no longer need to manage freestyle jobs:
all CI projects use the same pipeline.
In CI: One pipeline “to rule all builds” has been created (> 2.000 lines of code) and is run in some Jenkins agents (depending on the coding language). This pipeline manages source code checks, building (java, python, angular…), analysis (using SonarQube), container creation with generic Dockerfile (if asked), push artifacts to repositories and publish metadata (build/artifacts) to a MongoDB. MongoDB centralizes all knowledge about builds and artifacts. Thus developers don’t need to manage freestyle jobs any longer! All CI jobs use the same pipeline with only a few parameters like build method, git URL, version, etc. In this way, source code repositories are normalized.
In CD: Architecture is more complex: Jenkins works in the background using only one pipeline “to rule all deployments” which is run in a Jenkins agent hosting ansible. Three instances of software were developed to manage the deployment environments & parameters and the history of deployments: a user interface (using angular), rest API (using Spring Boot), and event processing (also using Spring Boot). Jobs in Jenkins are created/triggered by event processing when the user’s asking to. CI MongoDB is called to get builds and artifacts data. Thus developers and ops have a friendly interface to manage deployment parameters. All CD jobs use the same pipeline.
Goals: We had one goal: Making CI/CD a painless job for all Oney France applications
Solution & Results:
Jenkins agent management gives the capability to run a CI or CD job in a specific execution context (Jenkins agent) which is a container spawned on-demand. Thus no data is shared between job executions, and used binaries could be easily differentiated from one context to another.
Jenkins pipeline is a way to describe CI or CD job with source code (Groovy language):
- few Jenkins plugins are used (pipeline ones)
- this code is managed in Gitlab like any other source code
- Jenkins uses a branch or a tag of a pipeline: development of a pipeline is secured.
Jenkins is very stable: no downtime coming from a Jenkins core issue.
Jenkins community is huge: development help could be found easily on the internet.
What has been developed :
- Two Jenkins pipelines: one for CI, one for CD
- One Jenkins agent per build technology: java8, python, PHP, docker.
- One Jenkins agent for all deployment: ansible + az CLI + …
The results speak for themselves:
- Git projects structures are normalized
- Builds are isolated (Jenkins agent)
- Jenkins jobs for building software don’t need any parametrization
- Deployments are now visible to anybody