Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.
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.
Deploy to webMethods Integration Server plugin does the following tasks in the background
Details on how to install the plugin, minimum requirements and documentation can be found at Deploy to webMethods Integration Server.
@Kalpshekhar_Gupta thank you for this plugin, please give me an example configuration for Jenkins
i don’t understand using English . please create an example image such as ServerAlias : “C:<sag-dir>.…” etc . looks like that …
i need this document for POC , or you can send by email : andiogie@gmail.com , thank you …
@Kalpshekhar_Gupta - Just for general knowledge. Assetcatalog_for_RepositoryBased_deployement.pdf (2.8 MB)
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.
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 should be having an old doc, i will share it here.
Please refer to webMethods Deployer User’s Guide for more details.
Thanks, is there documentation I can refer to?
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.
it is possible. You would need to define the Automator file for components instead of composites.
@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.
@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?