Deploy to webMethods Integration Server Plugin for Jenkins
Jenkins is a popular open-source tool to automate software release (build, test and deploy) processes. It is widely used in projects based on webMethods Integration Server.
webMethods Asset Build Environment (ABE) provides out-of-the-box scripts to automate the build process. However, automating the deployment process can be challenging because of the dynamic nature of the project automator XML file.
The new plugin Deploy to webMethods Integration Server for Jenkins simplifies the deployment of webMethods Integration Server assets (packages and configuration). Thus, no need to write custom scripts or manually generate project automator XML file.
@Kalpshekhar_Gupta Thank you for this plugin. This will greatly help with in minimizing the effort required to setup CICD with Integration Server and Jenkins.
Is there a way you can support for other composite types such as flow services, documents and others instead of deploying the complete package?
@webc Yes, I’ll enhance it further based on the response and feedback I receive.
In case of repository based deployment (which is used in CI CD), I don’t think it’s possible to deploy individual composite types like flow services, documents, etc. Please correct me if I’m missing something.
If you want to deploy assets below package level, then you need to generate what is called a patch package. A patch package only contains a subset of the original package’s assets. On deployment it will be merged and not over-write an existing package. An exception will be raised if the target package does not exist or its version does not match the target version of the patch package.
regards,
John.
There is a school of thought where the package is the smallest unit of deployment. To go lower than that adds other administrative activity and makes determining what is deployed where a bit more involved.
I tend to think of an IS package as conceptual to a class. Treat it has a whole, don’t deploy a single method.
We used to deploy package patches but stopped doing so when it became a bit onerous to really confirm what changes were where. And the relative tedium of removing the patch info from the package once a complete package was to be released/deployed.
Of course this means package design needs to be such that a single package isn’t doing “too much” and has relatively focused scope. As with class/package design in Java, C++, C#, etc. one needs to segment things at the “right” abstraction levels (“right” being in the eye of the beholder).
I agree 100% with you @reamon, package deployment is the way to go, smaller than that is very dangerous. Patch packages are very niche and probably no longer valid in this day of small micro-service orientated packages.
John.
