We had published a recipe in developerWorks to automate the build and deployment of ACE projects on Cloud Pak for Integration. In this blog, we will discuss a pragmatic approach on how enterprises can quickly configure the pipeline for the build and deployment of ACE integration flows on IBM Cloud Pak for Integration.
Link to Developer Works recipe: Building CI-CD Pipeline for IBM App Connect Enterprise on Cloud Pak for Integration
In this blog, we will demonstrate an approach by taking an example so that it is nearer to real time experience.
A customer wants to automate the build and release process for IBM App Connect Enterprise to deploy on CP4I. They have considered using:
- Git as source control
- Nexus to store versioned BAR files
- Jenkins as the CI tool
The diagram below depicts their target state.
Note that you might have the multiple logical ACE environments on the same CP4I cluster isolated by namespaces or different ACE environments could be on different CP4I clusters spread across private or public clouds.
As you can see, this diagram depicts a basic DevOps flow. Lots of interesting things can be done on top of this, like:
- Implement continuous testing
- Automatically rollback to previous successful release if test fails
- Automatically Create issue in a bug tracking tool, like JIRA, for failures and assign to a developer
- Further enhance it to DevSecOps by introducing security test and so on.
One of the major benefits of moving to containers is that it eliminates the ‘compatibility issues’. It completely eliminates ‘it works on my machine’ problems. You can test your application with the same image locally that you are going to use in live environments. You would typically pull the respective ACE image from the container registry and deploy the app on local workstation. You can attach debugger for your flows running on containers on your local workstation. You could follow the below Github documentation to deploy ACE containers on your local workstation for development, testing and debugging as well.
Let us see how this basic DevOps flow can be implemented. In most of the scenarios:
- Developer will check-in the code after testing it locally with same image
- There could be a manual or automated build trigger for Jenkins build job
- Jenkins build job will compile the ACE application/service and create versioned BAR files for respective environments by taking configuration values from respective environment’s properties files and tag the source code with the respective version number
- Jenkins Build Job will store these versioned BAR files into a repository, say Nexus
- There could be a manual or automated trigger to Jenkins deployment job for DEV environment
- Jenkins DEV deployment job will pull BAR file(s) from repository (here Nexus), create an image with BAR file(s) baked into base ACE image and push the image into OCP registry of CP4I
- Jenkins DEV deployment job will create configuration secret with required configurations for the Integration Server, perform deployment from the created DEV image and will configure other objects like Horizontal autoscalar policy, Route etc.
- Upon successful testing in DEV env, there could be a trigger to Jenkins QA deployment Job. The similar steps (6 and 7) will be performed for QA environment.
- After validation and all required testing, similar steps (6 and 7) will be performed for Production environment.
You could create the image(s) for your ACE application during the build process itself; however building the image in a separate job, i.e. in a deployment job, has the advantage described below:
- You have versioned BAR files for respective environments and the source code is tagged with that version. So you can always trace the source code version associated with the respective BAR files.
- You may include BAR files from one or more build jobs to deploy them in one Integration Server.
- You have control over the deployment i.e. make deployment manual or automated. As in many scenarios, you may want to do manual testing of the applications before deploying in target environment.
For the scenarios where more than one ACE applications/services need to be deployed in the same Integration Server, the Jenkins deployment job can pull the respective BAR files from the repository (here nexus) and bake them into the ACE image.
The diagram below depicts two ACE applications being built and deployed in an IntegrationServer on CP4I
The sample Github projects used in this demo are attached here.
Thanks to Amar Shah for his contribution to this article