Gluu CI CD pipeline blueprint
Gluu, like any other top company, has the customer's satisfaction as its primary goal. Given the number of Gluu products, it is difficult to meet that goal without a complete, clear and comprehensive workflow.
Below is the list of problems we have to fix:
- How to provide patches as fast as possible
- How to catch bugs as soon as possible before reaching production
- How to react quickly to production outages
- How to monitor the production server
- Etc
DevOps is a software development approach that involves continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring of the software throughout its development lifecycle.
Gluu is 100% a software company, and we must take advantage of a philosophy like DevOps, as well as tools and technologies like Jenkins, GitLab, Jira, SCM, etc.
The solution for all of the above problems is a CI/CD pipeline. CI stands for Continuous Integration and CD stands for Continuous Delivery/Continuous Deployment. You can think of it as a process similar to a software development lifecycle.
Developer teams use version control to track changes on files, and the code is stored in GitHub. When a developer is done with a feature or a fix, the code is pushed to GitHub.
When code is pushed to GitHub, the Build phase can start. Most of our products are Java-based and use Maven as a build tool. Most of the time, this phase checks if there is a compilation error.
When the build phase is successful, the Unit Test phase runs all unit tests defined in the application. The unit test is intended to validate the domain object class. JUnit or TestNG can be used to write such a test.
When the Unit Test is successful, the artifact generated by the build phase can be used to deploy the application in a development environment.
There are two possible scenarios:
- The dev servers are up and ready: In this case, a script can be used to move artifacts to dev servers.
- The dev servers aren't ready: In this case, we may have to use configuration management tools like Chef or Ansible to provision the servers and then move the artifacts.
In the last verification phase, QA test cases are performed. Cucumber is the de facto tool to write and automate QA validation.
When the QA validation is successful, the final product can safely be deployed to a production server for clients/users. At this stage, we are confident about the product quality because it has passed all verification steps.
This phase can be ignored depending on the project, but for transaction applications, it is very important to automate monitoring of the application state/metrics.
Our task is to automate the entire process, from the time a developer commits a change to the time we get it into production. We will automate the pipeline in order to make the entire software development lifecycle agile, maintainable and spotless. For this, we will need automation tools.
The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.
Building and deploying new applications is faster with containers. Docker containers wrap up software and its dependencies into a standardized unit for software development that includes everything it needs to run: code, runtime, system tools and libraries. This guarantees that your application will always run the same and makes collaboration as simple as sharing a container image.
Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
JUnit 5 is the next generation of JUnit. The goal is to create an up-to-date foundation for developer-side testing on the JVM. This includes focusing on Java 8 and above, as well as enabling many different styles of testing.
Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) be automated as well.
Cucumber is a tool that supports Behavior-Driven Development(BDD). Cucumber reads executable specifications written in plain text and validates that the software does what those specifications say. The specifications consist of multiple examples or scenarios.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
SaltStack uses event-driven automation to transform complex systems into an organized and intelligent digital infrastructure controlled by a central nervous system that senses, learns, and reacts to important IT events across your environment.
Ansible is a universal language, unraveling the mystery of how work gets done. Turn tough tasks into repeatable playbooks. Roll out enterprise-wide protocols with the push of a button. Give your team the tools to automate, solve, and share.
HashiCorp Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared among team members, treated as code, edited, reviewed, and versioned.
- What is the best provisioning tool to use?
- How can we modify the setup.py command to run automatically without user intervention?
There will be 2 build processes:
oxTrust: https://github.com/GluuFederation/oxTrust/
oxAuth: https://github.com/GluuFederation/oxauth
Jenkins will poll a particular version i.e. https://github.com/GluuFederation/oxauth/tree/version_3.1.5
After a polling interval (i.e. 30 minutes), Jenkins will attempt to use Maven to build and test the image. We will use Docker for the environment deployment here. We should run tests against multiple Docker images, CentOS 6, 7 and Ubuntu 14 and 16 (maybe 18).
SCM (Source Control Management) below will refer to https://github.com/GluuFederation/oxauth/tree/version_3.1.5.
parallelsAlwaysFailFast() will force any parallel to fail automatically if there are any issues and not continue the test.
pipeline {
agent none
options {
parallelsAlwaysFailFast()
preserveStashes()
}
stages {
stage('Build'){
agent { docker { image 'maven' } }
steps {
checkout scm
sh 'mvn clean compile install findbugs:findbugs javadoc:javadoc site'
stash includes: '**/target/*.war', name: 'oxauth'
}
}
stage('Test in Parallel'){
parallel {
stage('Unit Tests to Ubuntu') {
agent { docker { image 'maven' } }
steps {
unstash 'oxauth'
sh 'mvn test'
}
post {
success {
// Push build artifact to Jenkins image Repo
sh 'echo Success'
// Create Debian package of latest Gluu Server components
sh 'echo Packaged'
// Use Terraform to provision DO Ubuntu VM's (14,16,18) and Chef to deploy Gluu Server with all components
}
failure {
sh 'echo Failure..'
}
}
}
stage('Unit Tests to CentOS') {
agent { docker { image 'maven' } }
steps {
unstash 'oxauth'
sh 'mvn test'
}
post {
success {
// Push build artifact to Jenkins image Repo
sh 'echo Success'
// Create Debian package of latest Gluu Server components and run QA tests
sh 'echo Packaged'
// Use Terraform to provision DO CentOS VM's (6,7) and Chef to install Gluu Server with all components
}
failure {
sh 'echo Failure..'
}
}
}
}
}
}
}
Above is a simple pseudo example of how to automate testing of oxTrust. There would need to be another success action that would tell Jenkins to download the latest artifacts and automatically package it in the corresponding .deb and .rpm. Once given approval to deploy, Jenkins would use Terraform to provision some resources on DO.
token.tfvars on the Terraform/Jenkins dev server (Not pushed to any git repo) will contain the do_token.
variable "do_token" {}
# Configure the DigitalOcean Provider
provider "digitalocean" {
token = "${var.do_token}"
}
variable "do_image" {
type = "map"
default = {
"centos7" = "# DO CentOS 7 image name"
"ubuntu16" = "# DO Ubuntu 16 image name"
...
}
}
# Create a web server
resource "digitalocean_droplet" "Gluu_Jenkins_Test" {
name = "Gluu_Jenkins_Test"
image = ${var.do_image}
}
Jenkins would then run terraform apply -var do_image=centos7 for CentOS tests and a terraform apply -var do_image=ubuntu16
Once the DO resources are up, Ansible or Chef would be used to configure and install Gluu Server.