Jenkins is the way to build and maintain even the most complex software in the world!

Social Security Product

Submitted By Jenkins User Theodore Chaikalis
A developer in Greece needed to deploy a robust solution covering current and future needs, while adapting to the changing requirements of social security organizations worldwide.
Organization: Various governmental organizations
Industries: Government software
Programming Languages: Java
Version Control Systems: GitLab
Community Support: Jenkins.io websites & blogs, Spoke with colleagues and peers

How enterprises can leverage containers to create a stable and scalable CI/CD environment.

Background: I work for a company known for automating social security services and modernising pension funds for more than twenty years. We offer a highly configurable and functionally complete Social Security Product, specifically designed to fully automate the business processes within a Social Security organization. Our solution is a multi-MLOC application composed of numerous, multi-module Maven projects spanning across different Git repositories. Our major challenge is to construct a central Build/Integration/Testing/QA assurance point that will easily handle all these different repositories.

Goals:  Providing a digital platform for contributions, insurance history, and pension management.

"Jenkins helps us by automating repetitive but complex tasks."
image— Theodore Chaikalis, Software Architect

Solution & Results:  

Here’s how I approached our challenge:

  1. I created a build job for each Git repo that is triggered on push events at the dev branch. 

  2. But the dev branch is locked. In order for somebody’s code to be accepted in the dev branch, they need to follow a specific process: Create a Merge Request. The creation of a Merge Request triggers a particular job in Jenkins called "merger." It merges the MR source branch locally into the MR target branch, builds the project, runs static code unit tests, runs sonar analysis, and — if ALL these steps pass — it then accepts the merge and pushes the code to the target branch. This triggers the build of step A. 

  3. At the end of each build, all jar artifacts are pushed to our enterprise artifactory repo, and all war artifacts are transferred via SFTP to a specific folder in the Jenkins server. 

  4. A special job called module-deployer reads the war files produced in step C and deploys them in selected dev/staging application servers. All these tasks are performed through parameterized jobs. 

  5. Special QA jobs are triggered by timers every night and run SONAR analyses for all projects of our codebase. In this way, we can have a fresh overview of the weak quality points of our software every morning.

Here are the capabilities I relied on most with Jenkins:

  • Build trigger for Gitlab integration

  • Build timer

  • Multiphase job

  • Jenkins DSL job generator

  • SSH execution step

  • Office 365 plugin that posts build results to our Teams channel.

  • Maven Job

  • Parameterized Job

  • Send files or execute commands over SSH

Here are the results we saw:

  • Build time for each application shortened by 70% 

  • Deployment time for each application shortened by 80% 

  • Monitoring of code quality improved