Improving the DevOps Practice
Submitted By Jenkins User Prudviraj Pentakota
Helping businesses with a software platform that allows customer success management teams to manage customer lifecycle and identify and proactively respond to risks requires a faster, better DevOps practice.
Organization: Customer success software company
Industry: Computer Software
Programming Language: Java, Node.js, Python
Platform: Docker or Kubernetes, Linux
Version Control System: GitHub
Build Tool: Ant, Maven
Community Support: Jenkins.io websites & blogs, Networking at Jenkins event
High quality, controlled, and clearly-visible code
shipped to production released 30% faster.
Background: This organization provides innovative technology to help businesses build deep and lasting relationships with their customers with the focus on helping to retain them and reduce churn. There is no single definition for DevOps in the organization, but at the end of the day, they wanted to break down all the definitions to map it to delivering faster and better products for their customers.
Goals: Making the DevOps process better. The team wanted to have faster, controlled, quality code shipped to production with clear visibility. We also wanted to save on infrastructure costs while producing faster builds.
We work with a plethora of tools and programming languages. Jenkins has been the go-to tool for automating most of the processes and thereby we’ve been able to ship code faster with better quality.
To begin with we use Gerrit , a free, web-based team code collaboration and review tool. We also use GitHub for version control. Now in Jenkins, we use the Gerrit Trigger Jenkins plugin and GitHub hooks combined with custom script to validate the code and merge only when it meets the set quality gate.
Once we have the code merge, we have our pipeline jobs which verify additional quality standards including Sonar. If CI is green, the pipeline then starts the automation build. Based on the quality gate for an automation suite, we either deploy it to our QA environment directly or use Docker.
We use Allure reports and JaCoCo plugins to check the code coverage and test suite information. Based on the quality gates at this point, we promote the Docker build to the next environment stage. A detailed report would be emailed to a Slack channel to have a clear communication.
Jenkins helps us reduce the single person communication with its integration to Slack and emails. When we find issues with building automatic Jira tickets that would be raised to the committees, we use custom logic with the Jira plugin.
We have thousands of Jenkins jobs built including Java, Node and Python-based, each requiring their predefined infrastructure. We use auto scaling via an Amazon Ec2 plugin to scale infra and avoid static machines drying our pockets.
Along with that, we have a few legacy build machines which are used only for specific builds. For example, as the Amazon ec2 plugin cannot be used as a machine should not be terminated, we have Jenkins REST APIs to build auto-scaling for legacy slaves.
We do have multiple environments and want only specific people to deploy to those environments from the same Jenkins. For this automation, we used Jenkins Build User Details with apply deployment restrictions.
We have built most of our automation to achieve the desired results using these Jenkins plugins:
- Gerrit Plugin , Git plugin (automatic triggers)
- Aws EC2 plugin (for auto-scaling )
- Maven, Nexus, Sonar, Pipelines, and Docker plugins (build and releases)
- Dashboard plugins (for listing build status with coverage info)
- Jira, Slack and email plugins (for clear communication)
- infrastructure cost saved by 40%
- builds are 30% faster
- better and seamless communication on builds and releases
- faster release cycles
- improved quality in release
- To avoid unnecessary builds.
- Handle deployments to 70-80 applications with a single click/and also fully automated provision with build scheduler ( As required details are consumed from database , rather than need for manual input).
- Send specific information to slack channels and avoid person-to-person/team-to-team dependency.
- Reduce manual efforts with Jenkins being epicenter and database bringing required information.