Hi, I am just getting back into webMethods after a few years away (version 8.22 was the last version I was heavily involved with).
I have been asked to look at how we can implement a DevOps CI/CD approach for integration server services, mostly Flow services, using Git and Azure DevOps and I have a few questions that I am hoping someone will be able to help me with.
Can I integrate with Git without having the ability to create a local development project (we are not licensed for local development)?
How can I incorporate unit testing as part of the build process without using WmTestSuite (again a licence constraint). Can we use something like JUnit?
What does a build do in relation to flow services as there is no compilation as they are XML files.
Apologies if these seem like obvious questions but I’m new to DevOps as well as learning the new capabilities in IS since 8.22.
Yes integration with Git is possible without LocalServiceDevelopment, but only for ProcessModels, UIs, Events, BusinessRules, but not for FlowServices etc (anything which is directly developed in a Package and not generated like BPM implementation).
AFAIK, LocalServiceDevelopment is now part of the Suite by default without requiring an explicit license since 9.x.
We have done something like that with a custom JBehave-Implementation (custom because we wanted to have it in german instead of english) using the JavaAPI of IS, TN, PE etc. running in Jenkins on a Tomcat-Instance with writing additional testing helpers like driver and stub services simulating the Partner Endpoints.
You can explore the download section of the community, there was a Junit-Sample-Package as well as a WmUnit-Package (but this one might not be publicly available) earlier if I remember right.
Which build function are you referring to?
There a several types of build operations doing different things (“Build & Upload” for generating models to run in ProcessRunTime, “Build the workspace” to compile CAF-based implementations before uploading them to the MWS).
The current version of wM is 10.5, just as a note.
If you have further questions, consider spawning new threads when they do not directly relate to this one.
This will make it easier for the community to track them.
The problem we have with Local Service Development is that the developers work with designer installed on their own workstations but with designer connected to a central development environment. In order for local development to work the Designer tool and the IS need to be installed in the same place. We cannot install an IS on the developers’ work stations due to the number of CPUs our licence allows for development (which would be my preferred way of working). One thing I could look at is getting designer installed directly onto the development server…
I’ll have a look at the download section for JUnit samples
Sorry, I should have been clearer. For the build process I’m only talking about Flow services at the moment. Our implementation is, so far, fairly simple with nearly everything being done using Flow.
as a workaround you can extract the affected packages from development server as a zip file (for transport reasons) and then unpack it to your local working copy of GIT and then do the check-in here.
But this is a manual task and cannot be automated via Designer-GIT-Integration. Unfortunately the VCS feature on IS side only allows for Visual Source Safe, Rational Clear Quest and Subversion to be integrated.
Additionally this feature should be considered deprecated in favor of using Local Service Development.
As long as the development server is Windows based you can install the Designer on it.
When the development server has access to the git repository you can also add the Local Service Development Support there.
Julian, you can implement all of this, and we’ve done this already, and use the build infrastructure with great success. We built our buid infrastructure around the wM Deployer (ABE). We created an ant script that controls the whole deployment procedure. At one place, it calls the ABE deployment script.
The ABE script provides the possibility to integrate any version control system. You just have to provide a script that would check out the assets to a certain directory. Our VCS ist a very exotic one, and still we integrated it easily.
The other question is how to put your developed assets into the VCS. For process models etc. this is easy as the files are edited locally. For flow services, if you develop on the server (as we do), you’ll have to come up with a way to accomplish this. We did this by creating a script that would copy the files to the local computer, and checking in from there. Thus you can also integrate any VCS supported by eclipse.
This depends on how you’ve implemented your unit tests. We created our own unit testing framework, based on flow services only. We execute them periodically and automatically, but not as a part of the deployment.
Our build uses the ABE and hence creates the ACDLs (deployable wM units) and also creates the deployer project. Our script is also able to execute the previously created deployer project. And do several things before and afterwards to ensure that everything went OK. It has grown over time, and now saves us much time as we don’t have to care about many details that often go wrong. We only deploy assets of type “IS package”, “Process Model” and “UI (portlets etc.)”
