Industrial Use-Case of Jenkins
Before discussing Jenkins industrial use-cases. Let first take a quick overview of the Jenkins tool in brief.
What is Jenkins?
Jenkins® is an open-source automation server. With Jenkins, organizations can accelerate the software development process by automating it. Jenkins manages and controls software delivery processes throughout the entire lifecycle, including build, document, test, package, stage, deployment, static code analysis and much more.
You can set up Jenkins to watch for any code changes in places like GitHub, Bitbucket or GitLab and automatically do a build with tools like Maven and Gradle. You can utilize container technology such as Docker and Kubernetes, initiate tests and then take actions like rolling back or rolling forward in production.
Jenkins History
The Jenkins project was started in 2004 (originally called Hudson) by Kohsuke Kawaguchi, while he worked for Sun Microsystems. Kohsuke was a developer at Sun and got tired of incurring the wrath of his team every time his code broke the build. He created Jenkins as a way to perform continuous integration — that is, to test his code before he did an actual commit to the repository, to be sure all was well. Once his teammates saw what he was doing, they all wanted to use Jenkins. Kohsuke open-sourced it, creating the Jenkins project, and soon Jenkins usage had spread around the world.
Jenkins Today
Originally developed by Kohsuke for continuous integration (CI), today Jenkins orchestrates the entire software delivery pipeline — called continuous delivery. For some organizations, automation extends even further, to continuous deployment. Continuous delivery (CD), coupled with a DevOps culture, dramatically accelerates the delivery of software.
Jenkins is the most widely adopted solution for continuous delivery, thanks to its extensibility and a vibrant, active community. The Jenkins community offers more than 1,700 plugins that enable Jenkins to integrate with virtually any tool, including all of the best-of-breed solutions used throughout the continuous delivery process. Jenkins continues to grow as the dominant solution for software process automation, continuous integration and continuous delivery and, as of February 2018, there are more than 165,000 active installations and an estimated 1.65 million users around the world.
Architecture Of Jenkins
Before we dive into how does Jenkins works, we must understand the architecture of Jenkins. These are the series of steps that outlines the interaction between different elements in Jenkins:
- Developers do the necessary modifications in the source code and commit the changes to the repository. A new version of that file will be created in the version control system that is used for maintaining the repository of source code.
- The repository is continuously checked by the Jenkins CI server for any changes (either in the form of code or libraries) and changes are pulled by the server.
- In the next step, we ensure that the build with the ‘pulled changes’ is going through or not. The Build server performs a build with the code and an executable is generated if the build process is successful. In case of a build failure, an automated email with a link to build logs and other build artifacts is sent to the developer.
- In case of a successful build, the built application (or executable) is deployed to the test server. This step helps in realizing continuous testing where the newly built executable goes through a series of automated tests. Developers are alerted in case the changes have caused any breakage in functionality.
- If there are no build, integration, and testing issues with the checked-in code, the changes and tested application are automatically deployed to the Prod/Production server.
Here is the diagrammatic representation of the Jenkins architecture:
A single Jenkins server might not be sufficient to realize the following requirements:
- Testing needs to be performed on different environments (i.e. code written using different languages e.g. Java, Python, C, etc. are committed to the version control system), where a single server might not suffice the requirement.
- A single Jenkins server might not be sufficient to handle the load that comes with large-scale software projects.
In such scenarios, the distributed (or Master-Agent) architecture of Jenkins is used for continuous integration and testing. Diving deeper into how does Jenkins works, we take a look at the architecture of Jenkins.
WHY DO WE USE JENKINS?
With Jenkins, organizations can accelerate the software development process through automation. Jenkins integrates development life-cycle processes of all kinds, including build, document, test, package, stage, deploy, static analysis, and much more.
Jenkins achieves Continuous Integration with the help of plugins. Plugins allow the integration of Various DevOps stages. If you want to integrate a particular tool, you need to install the plugins for that tool. For example Git, Maven 2 project, Amazon EC2, HTML publisher etc.
The image below depicts that Jenkins is integrating various DevOps stages:
Features of Jenkins:
Jenkins offers many attractive features for developers:
- Easy Installation
Jenkins is a platform-agnostic, self-contained Java-based program, ready to run with packages for Windows, Mac OS, and Unix-like operating systems.
- Easy Configuration
Jenkins is easily set up and configured using its web interface, featuring error checks and a built-in help function.
- Available Plugins
There are hundreds of plugins available in the Update Center, integrating with every tool in the CI and CD toolchain.
- Extensible
Jenkins can be extended by means of its plugin architecture, providing nearly endless possibilities for what it can do.
- Easy Distribution
Jenkins can easily distribute work across multiple machines for faster builds, tests, and deployments across multiple platforms.
- Free Open Source
Jenkins is an open-source resource backed by heavy community support.
Jenkins Use Cases :
Continuous Integration (CI)
Continuous integration is a practice that forces developers to frequently integrate their code into a central repository. Instead of building out new features to the end without any quality measurement, every change is tested against the central repository in order to anticipate errors.
Every developer commits daily to a shared mainline and every commit triggers an automated process to build and test. If building or testing fails it can be detected and fixed within minutes without compromising the whole structure, workflow, and project. In that way, it is possible to isolate problems, solving them faster and provide higher-quality products.
Continuous Delivery (CD)
Continuous delivery is the ability to make changes of all types — such as new features, configuration changes, error fixes, experiments — into production in a safe and efficient manner using short work cycles.
The main goal in continuous delivery is to make deployments predictable as routine activities that can be achieved upon request. To be successful, the code needs to always be in a deployable state even when there is a scenario with lots of developers working and making changes on a daily basis. All of the code progress and changes are delivered in a nonstop way with high quality and low risks. The end result is one or more artifacts that can be deployed to production.
Continuous Deployment (CD)
Continuous deployment, also known as continuous implementation, is an advanced stage of continuous delivery that the automation process does not end at the delivery stage. In this methodology, every change that is validated at the automatic testing stage is later implemented at the production stage.
Automation
As a job executor, Jenkins can be used to automate repetitive tasks like backup/restore databases, turn on or turn off machines, collect statistics about service and other tasks. Since every job can be scheduled, repetitive tasks can have the desired time interval (like once a day, once a week, every fifth day of the month, and so forth).
Jenkins Case Study: Tymit
Challenge:
Create a solidly reliable CI/CD platform that provides the technology team with the agility and the flexibility needed to innovate while ensuring the security and scalability their fintech service requires.
Solution:
Tymit, a revolutionary credit card processing company, leveraged Jenkins to build a compliant, transparent and secure modern DevOps platform to drive product innovation, handle instant financial transactions and support thousands of users in real-time.
A flexible infrastructure to keep pace in a rapidly evolving fintech world
“At the time we were building the proof of concept, we didn’t require an extensive infrastructure, so we relied on different non-open source third-party vendors,” said Nicolas.
“Once our product became a big reality in the market — with a huge interest from the Credit Community and focus from companies like VISA — we knew we had to build a solid CI/CD system to scale with our business in a much more reliable and cost-effective way.”
Today, Tymit claims to have re-designed the credit card, putting the user in control, the majority of whom actively use the card and access the platform through the Tymit mobile app. New customers onboard every day by tapping into Tymit’s ‘instant issuing’ service. With this particular feature, users can download the app, get issued a virtual card and make an initial transaction in just a few minutes. This instantaneous transaction is a first for the fintech industry, Nicolas points out, and one that requires the power and flexibility that Jenkins affords them.
These kinds of services and transactions are where Tymit’s infrastructure and CI/CD system starts to become more critical every day, the engineering team pointed out. For them, it was absolutely critical for them to have the right tools in order to scale in security, cloud resources and capabilities to continue to support Tymit’s exponential growth.
Also, since Tymit is a fully digital credit card, the team is tasked to provide mission-critical 24/7 customer service to users. That requires a platform that can seamlessly authorize global transactions at any time, day or night.
Scaling cloud resources and capabilities with Jenkins
Tymit’s infrastructure supports three distinct platforms: Mobile (iOS and Android), Backend (Microservices), and Platform (Infrastructure/Security/SRE/Operations). While they are quite heterogeneous, each division requires different release schedules and management processes. For instance, Tymit could hypothetically release new versions from the backend services while simultaneously releasing new updates for the iOS and Android app. And, as the platform is continuously evolving, they perform weekly Terraform releases. The Tymit technology team uses Jenkins to orchestrate these distinct release schedules from the environment up to production.
The product and engineering teams also manage very diverse load times with varying spikes. To handle that, they use spot instances. Over a period of weeks, they may need to release software on the backend in a rapid-fire way, requiring more resources in the CI than in the mobile vertical. By using the EC2 Plugin on-demand with special labelling, they can increase those resources for specific peak times for a particular team. Once finished, the tech team can simply roll back that infra to normal within the Jenkins configuration.
Enabling secure, transparent financial transactions with a powerful CI/CD
When people’s finances are on the line, security and privacy are of paramount importance. “Being a fintech company on the road to achieving PCI DSS compliance creates a lot of challenges in terms of security,” Nicolas explained. “Because Tymit uses CI to perform for both software and platform releases, the need to have a solid and secure pipeline which does not leak any sensitive information is critical to our success.”
For this, Tymit creates ‘secrets’ within Jenkins — which are either stored fully encrypted or acquired from their AWS Cloud provider — to ease the deployment of certain software on different platforms. Using specific Jenkins capabilities — like the Docker with Pipeline plugin — the team can handle Docker images in a secured environment.
Scaling as rapidly as Tymit’s fintech rise
The technology team at Tymit feels that this platform-as-a-service solution offers more capabilities than a standard CI/CD system. And they aim to use Jenkins to integrate additional processes in their software life cycle to help scale and deliver the best quality to their customers.
They equate Jenkins to “a big Swiss Army knife” and believe that with a bit of setup, it can offer many possibilities in the software engineering world and beyond. “Jenkins has become a fundamental piece for our ‘time to market’ to deliver constant value,” Filippo Matoso, Tymit’s Product Owner
Thank You!
Keep Learning & Sharing…
If this article is useful for you then don’t forget to press the clap 👏 icon and also follow me for more such amazing articles.