For those who may have missed this in the Deployer_ABE_readme doc:

webMethods Deployer 10.5 is the last general availability release of the product. We will
not add new features in Deployer in the following release. We will notify you of what you should do to
replace the Deployer functionality and what are the official end-of-life dates in a deprecation notice as
soon as the deprecation comes into effect.

In 10.5, the runtime-based project type was deprecated. Now it seems Deployer altogether is going away. Alas, no info yet about what might replace it.

I know commenting on future releases/features is generally avoided, but I’m hoping someone might be able to share some of the thoughts behind this decision. I know there is a contingent that thinks managing wM artifacts should be the same as “the rest of the industry” but I take issue with that. If I wanted to manage source code and config files the same way as is done with Java development, I’d do Java development. Many wM components are not stand-alone text files. A tool that understands the relationships between the components is incredibly useful. Please don’t have this relationship and dependency management as an exercise for the user community via editing scripts.

Hi Reamon,
the reasoning for is that as we move away from monolithic platforms and return to package based deployment, deployer will no longer be required. Packages should be more autonomous with dependencies that are explicitly defined and easier to manage and we will adopt this pattern for our own packages and provide new features to encourage this when developing your own packages.

Also I am quite (genuinely) excited to give a little window in a new command line tool that will arrive 2022 to allow packages to be included from any git repository of your choosing. It will allow developers to easily add new features to their local development environment and also integrate into your build pipelines to facilitate building a working platform or container image.

I can’t really say anymore at the moment about our new package manager, we will be announcing it later in year alongside some other very cool features for taking webMethods development to the next level

regards
John Carter
Product Manager,
Integration & Microservices Runtime

Thanks for sharing what you could! Very much appreciated!

Alas, it somewhat confirms my fears – a focus on source code repositories and reliance on scripts. Both are steps backwards, IMO. We don’t use local dev, we use central dev. We don’t use a VCS (that will strike many as strange). With the central dev server(s) model, doesn’t add value (a discussion of that can be separate topic).

Package-focused deployments is what we do. We rarely have a Deployer project that has more than one package in it. We’ve long used packages as the smallest deployment artifact (we never use package patches). The automated dependency checking is great for: 1) making sure copy/paste of services or steps isn’t resulting in a reference to a wrong package; 2) helps verifies that the common utility package has been deployed first (without me needing to manually define that in some way ahead of time).

I’ll be very interested in seeing what the replacement tooling will do along these lines.

I’m having flashbacks to the “fun” of managing header file includes in C/C++ code. “Easier” might be debatable.

Looking forward to learning the details as they become available.

Hi,

another thing to keep in mind:

What about BPM deployments as well as CAF/Tasks and/or Optimize deployments?

We have used runtime based deployments for these and found it very helpful with the automated dependendy checks (esp. for BPM packages referring to the regular implementation packages).

Regards,
Holger