I am currently working on implementing Continuous Integration (w/ Github + Jenkins) and was able to get the demo that Software AG has provided to work on my system. Now, I’m attempting to take this setup and ensure it will work for all of Deployment needs before making plans to proceed with the full implementation. One of the items that I cannot seem to find any information on is how to get a file from the filesystem to be included with the automatic deployment. Here’s the scenario in more detail:

We have a quite a few services that have configuration files that are stored in an application specific folder path (such as…/IntegrationServer/instances/default/AppConfig/Service123/properties/) rather than inside the Package. I would like to add these into my Github Repository so they are versioned and would get deployed along with code changes. Today, We have this option to select any file in Deployer in a Runtime based deployment as a “webMethods File”. However, I cannot find any mention of this with a Runtime based deployment w/ ABE. With regards to Integration Server components, I am only seeing info about including Packages and some webMethods config/admininstration settings that can be included in the assetts/IS/config folder (or assetts/IS/Packages/config) if they are manually copied to the repository.

Is this something that is possible? I’m on Integration Server 10.1 btw.
Thanks in Advance!
-Brad

Hi,

This one of the areas the repository-based deployment does not address.

My solution is to have those files stored in GIT in their own folder hierarchy and have them on the same tag with the package files so that Jenkins will have a coherent vision on checkout.

The ABE will NOT pick those files, obviously, but I will save them along side the build binaries in my build repository (I’m using Apache Archiva but you can use any other system).

In my deploy job, I’ll pick them with the build and, while (or before) the Deployer is working, I’ll place them directly in the correct place.

I’m still working on a pre-deploy phase where all asset properties are changed to the required values of the target environment.

Best regards,

Another solution (which we have applied several times) is to place the files in the, say, resources folder of the “owner” package (you’ll have to decide which one should own the files) and then copy them to the destination folder on the target server in a service that’s called when the package is loaded (startup service). Then everything is handled by the deployer. And the package life cycle.

PS. But then, why not consume the files directly from the package? I.e. why do the files have to be located outside the IS dir?

Hi @fml,

In my case, it provides for a separation of deployment.

Most of the time, only the configuration file needs to be changed, the code remains untouched.

I do prefer using a solution where the configuration is handled using a helper tool: managed and secured centrally and cached locally.

Best regards,