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
Industry: Government software
Programming Language: Java
Platform: Linux, Windows
Version Control System: GitLab
Build Tool: Maven
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.
Solution & Results:
Here’s how I approached our challenge:
- I created a build job for each Git repo that is triggered on push events at the dev branch.
- 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.
- 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.
- 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.
- 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