I am planning an upgrade right now and while designing the new architecture I am also migrating deprecated products and modernizing the architecture a little bit. In our current environment we have multiple cluster groups and each group is assigned to a different project (code base/repo). Our current license doesn’t have Micro-services Runtime right now, and current architecture makes more sense to me if it were deployed on containers. If we can’t get a license for containers, then my plan is to collect all these cluster nodes in to 1 giant cluster, but keep repository separate for each project.

My questions are:
What is the Best Practice for managing multiple projects using VCS in webMethods.
Does my plan make sense and is it possible?
Is there anything I should consider/test before going towards this path? Is there anything to avoid?

I never used or configured VCS in webMethods before because my previous projects weren’t that big. I am open to reading any materials. I checked the VCS configuration document but I didn’t see much details there.

Thanks in advance

In one view of the world there is no such thing as “best practice.” Instead, the view is “what others do might work for you too, depending upon your situation.”

My only caution about VCS with Integration Server and related components is to be very aware of what the VCS support in Designer does and does not do along with ABE/Deployer. Version control and builds with packages, adapters, config files, models, TN, etc. (depending upon one’s environment) is an undertaking. Do not assume it is trivial. It’s not hard, just more involved than what is usually initially assumed due to various constraints.

By “projects” do you mean independent components that do not share code? Are there any services/packages created that are shared? When you mention “1 giant cluster” what type of cluster do you mean specifically? These items may help with segregating components for VCS purposes.

Yes Multiple independent projects. There are some shared libraries but AFAIK there aren’t any shared code other then loggers. It will be a stateful IS cluster if that’s what you mean. There are single instance brokers in each cluster node in current architecture but my intention is to seperate all IS, UM and MWS instances completely. Most of our code is implemented on IS and its already in a VCS. Currently we have around 100 nodes and they all have double IS instances and 1 brokers. If I can manage multiple repositories in single highly maintained cluster group (each product group can have more then 2 nodes but they will have more(8+) cores then they do now) I can reduce number of dedicated cores and I can gain a lot of extra performance as well. At least that’s what I think.

What do you class as a project ?
Also I wouldn’t use the term cluster as it implicates hardware and good software design should not impose a physical topology.

We generally recommend that you version control each package individually. A Developer will then compose a project based on a collection of packages. You can even version control the project with it referencing the different versioned packages. Git allows you to do this via submodules i.e.

We will soon be introducing a new cli tool called wpm (webMethods Package Manager) which will allow users to share and collaborate around packages. The tool will require that you version control your packages and the first iteration will require that you do that with git.

It is designed in mind with our MSR, because you will be able to create a Dockerfile and run the wpm command from with in it to combine both your own and eventually even licensed packages from us.

regards,
John.

Is this inspired by npm and intended to be conceptually similar? If so, I have mixed reactions. (Probably a discussion in another thread).

What I mean by project is a collection of packages which controlled by the same VCS repo.

So basically you recommend against using different cluster groups having different code base (i.e. separating instances according to use cases), am I right? What if the developers, analysts etc are also different and none of the packages are related to each other? Should we still deploy every package in to same instance group?

What is the correct procedure to keep track of active/inactive packages then? Any environment will have lots of inactive packages eventually if not managed correctly. I feel like we need to keep track of package usages somehow.

Not sure what you mean by a cluster group. If you are moving to a container/micro services architecture then you need to break your work load into small units. This is not necessarily a 1 to 1 mapping with a project. As I said a good design should allow you to deploy your integration/project in various different topologies from a single container to multiple.

So to answer your questions when I said independence from topology I am not advocating that you install everything everywhere, but to ensure that you can decide to change where packages get installed without having to rewrite code. You should not be installing packages into containers if not needed, even a disabled packages consumes disk space and every kb matters in a containerised architecture.

Hope that makes it clearer,
John.

Thanks for the additional info.

I’ll defer to others to provide additional advice as it’s been a long, long time since I’ve used any VCS with wM components (we’ve been able to get away without using one so far). My 2 cents:

• Be aware of what the integrated support for VCS in Designer does and does not do. You’ll need to address the “does not” in some way.
• I think the ABE/Deployer info will be more helpful in this activity than will the VCS docs. What you’ve descibed is more of a build/deploy-focused concern than a VCS. Obviously the VCS is important, but getting the artifacts from the VCS deployed to the run-time environment is more about getting ABE/Deployer/Jenkins, etc. to do what you need.

HTH