From the Deployer documentation for 10.5:

Deprecation Notice: Beginning with release version 10.5, runtime-based deployment is deprecated. Software AG recommends that you use the Asset Build Environment and repository-based deployment instead.

Anyone else negatively impacted by this? For our environment, repository-based deployments are an unnecessary complexity. It just makes things more complex without added value.

My hopes are not very high but I was thinking if there was enough demand for keeping runtime-based deployments that SAG would reconsider.

Anyone else interested in trying to get this restored?

Hello Rob,

I am with you on this voice too!!

I am also interested and wanted continue to use Run-time based deployments to keep standalone based actively involved environments in some of Orgs.

Hope SAG hears this side of voice also and not get this option Deprecated >= v10.5 releases etc…

Cheers!
RMG

Hello,

I agree with Rob and RMG.

I also want to have the possibility to do runtime-based deployments as we are quite familiar with this while doing repository-based deployments require us to do some more migration work when migrating to a newer wM version next time.

Might be worth opening a thread for a poll and/or opening a feature request at Brainstorm.

Regards,
Holger

Submitted 07688 to Brainstorm.

Thanks for the update and very much appreciated !!!

Hi everybody,
just to mention, that deprecation does not mean removal. The runtime deployment will continue to function, but we don’t encourage new projects stated with it.

The repository based deployment needs to be enhanced, but it also brings a lot more new scenarios with it - deployment to containers, to cloud, etc. We need to make it clear for new customers which mechanism is preferred. This never meant disturbing existing customers that have their landscapes already set up.

Regards,
Angel Tcholtchev

Liked and Watching

@Angel:

Thanks for jumping into the fray on this! Very much appreciated.

Deprecated usually means removal in the near future. If that is not the intent, great. But perhaps different wording in the docs would be more clear.

(I’m battling the fear that this is going to be like Broker – SAG repeatedly stated it would continue right up until stating it would be dropped completely.)

Why is runtime-based considered inferior or “not preferred?” For new customers, I get that you want to highlight the ability for various scenarios. How does runtime-based get in the way of that?

I obviously don’t know what it under the covers in Deployer, but it makes no sense to me that creating a “build” from runtime to create a deployment set (a bunch of files) is conceptually different than creating a build from a repository to create a deployment set (a bunch of files)?

I am also confused as to why the source being runtime-based is somehow anathema to deploying the build to a container or hosted system (“cloud”). Would it not be a good feature to support “build from your central dev servers and deploy to another rutime or to a container, cloud, etc. – no need for a separate repository!”

Make Deployer more IS/TN/BPM/etc. friendly, not less.

Thanks Angel for jumping on this check…

I also agree with Rob and Deprecated wording shouldn’t be used in this scenario rather :

“Deprecated usually means removal in the near future. If that is not the intent, great. But perhaps different wording in the docs would be more clear.”

Cheers!
RMG

I applaud to the decision to declare the runtime deployment as inferior. I fully agree with that opinion and think that giving this orientation to new customers is the right thing.

IMO, a repo based deployment is much better than the runtime one since only repo based deployment allows you to fully control what is in the build in a reproducible way. It also brings in the full power of branching etc. into the deployment process.

Runtime based deployment is like building a house on sand.

But I’ve heard another thing: the deployer could be deprecated as a whole in future because its features will be subsumed by the Command Central. What would you say to this rumour?

@fml2:

Differing opinions are the spice of life.

Seems like you’ve encountered significant issues using runtime-based deployments leading you to conclude runtime-based is to be avoided.

My experience has not been a “sandy” one.

This is most certainly a YMMV concern. For you, runtime-based is inferior. For others, runtime-based is superior for the situation.

For the CC item, that would be a bit interesting, although the CC UI is a bit “ugh.” E.g. monitoring UM is an adventure.

Pulling Deployer features into CC reminds of when TN Console was pulled in to MWS. I get why it was done, but it is debatable if doing so was “better.” I guess we’ll see.

My wish is for SAG to mimic or buy Crossvista. While some of the details of how CV works are not always stellar, the idea of “understand all the parts that comprise a component to be deployed” is far better captured by CV TEAMS than by ABE and repository, which leaves much of the details as an exercise for us.

I by no means want to discourage you from using runtime deployment. If it works for you, it’s just fine. But IMO the right way is to use a real VCS as the source of truth – like the rest of the software industry does.

The ABE allows to fully automate the deployment process, and we’ve built an infrastructure (some scripts) around the “core” ABE scripts to further ensure that the deployment has been executed without errors (e.g. a package could not be activated after deployment). There some actions that are executed prior to the execution of the deployer project, and some that are executed afterwards.

Also, we can customize the deployment depending on the target environment (sort of like preprocessing in C) etc.

Some/many of these features would not be possible with runtime based deployment.

I’ve never used Crossvista, just seen some videos. Does it allow to automate deployment?

Hi,

I don’t work for CrossVista but my company sells their solutions.

Yes CrossVista TEAM has a lot of automation builtin, from simple event triggered events (a commit, a ticket from HPQC, etc) to a full lifecycle management process.

The next version can even deploy other artifacts (files, databases, other types of systems)…

The Designer plugin is everything you wish SAG had done to replace the VCS (individual check-in, checkout, compare revisions, access the package files directly, etc).

That being said, it is a completely different way of doing deployments and it may not be a choice for every case.

As for the repository deployment, I find the documentation lacking.

Some things are much harder to do, for instance, users, roles and permissions from the IS and MWS, Optimize artifacts, etc…

I already have several incidents open with SAG to make repo-base deployments projects as feature-rich as runtime-based ones

Best regards,.

fml2,

Regarding-

"But I’ve heard another thing: the deployer could be deprecated as a whole in future because its features will be subsumed by the Command Central. What would you say to this rumour? "

→ Yes could be and I heard the same also no wonder as more and more IS Internal connecting apps being moved to Command Central (CCE) as its a one-stop-Shop IS configurations web portal and going to be more easier for usability and Ifra Operations and Admins life:)-

Cheers
RMG

Interesting, after about a 5yr layoff from wM product and working in the open source space we are now starting to incorporate CI/CD devops for some clients. We currently building solutions that use repository for deployments via jenkins pipeline, it seems IS assets apart from code are not trivial to add into the base build?
Designer plugins with git has been good compared to the ol days of SVN however I just raised a post with some odd behaviour on one of our machines