License for Local Service Development (LSD) usage

,
1

We are using webMethods 10.11 on a central server based on Redhat. Actually, every developer (around 10) has a Designer on his machine linked to the server for service development. We have already a license for this usage.

Now, we want to start doing versioning. Local Service Development (Local Version Control Integration) is the suggested way to do versioning with webMethods, so Integration Server and Designer are installed locally on the same machine.

Here are my questions: To start using Local Service Development (LSD):

  • on each developer’s machine, do we need to do the installation of webMethods (with LSD plugin activated ) ? Or do we need just to install LSD plugin on our previous central server ?
  • if the previous question about installing webMethods on each developer’s machine is Yes, do we need to buy a license for each developer’s machine from Software AG ?

Best regards !

2

For the technical side, you will need a separate local installation for each developer. Anything else does not make sense, since the core aspect of local development is that each developer has his/her own environment.

For the licensing part you need to talk with your Software AG contact person.

4 Likes
3

@jahntech.cj Thanks for your reply.

If each developer has his own IS instance in the central server, do you think we can do versioning ?

My personal point is each developer should have his own local environment in his machine (like you said previously), but my hierachy is suggesting to have an IS instance for each developer (so developer can work independtly from eah other). Who is right ?

Our final goal is to do versioning with webMethods and create a CI/CD pipeline later.

4

In my view this is not a question of one side being right and the other being wrong :slight_smile:

You can always do versioning. At least I cannot think of a reasonable setup that prohibits it.

For me the real question is actually not a technical one. (Although I am a very technical person.) Instead it is about the business goals that shall be achieved. In that sense I have not yet met an organization that said “we want to slow down our developers”. Because that is what happens with any other setup, compared to a local development environment.

A local development environment has, for the context of this discussion, two main characteristics. First, it is local :-). Local here means that the developer has full control. For me that includes admin rights! Because you always come into a situation that you need to install a certain tool to make your life easier. This dev environment can also run on a VM, so it does not have to be local in a strict sense. The core aspect of local here is easy file system access, because version control by definition happens on the file system.

Second, the developer should be the only person working on that environment. Yes, technically it is possible to share. But there are two huge downsides to that. The bigger one is added complexity, which slows people down greatly. The smaller one, and it is kind-of related to the other, is the increased risk of by mistake interfering with someone else’s work.

I understand that managers shy away from switching to a completely new way of doing things, and I have had similar discussions with customer countless times over the last 15 years or so. What has helped me is to very directly ask what negative aspects people expect from a switch to local development. Then these challenges can be addressed. Because usually people understand that local development creates better results. It is just that change always comes with risks as well. When those risks can be addressed, that is a start.

It is also a possibility to start with just one local development, rather than switching over completely. That contains the risk, allows people to learn the work with a Version Control System, and comes with limited effort. Without additional details it is difficult for me to be more specific. But I think the best results come by finding a way that fits your organization’s business needs and(!) takes into account where you are today. In other words, an approach that looks great on paper, but ignores your current capabilities does not help. The probably biggest factor for success is an honest assessment what needs to be learned. I don’t mean this in a patronizing way at all! Having worked with various VCS I still learn new stuff every day.

I realize that was a rather long answer, and possibly not the one you wanted. But it is my honest opinion and so far has worked great for me.

Hope that helps!

2 Likes
5

@jahntech.cj Thanks you for your analysis. In fact, the answer is not long :slightly_smiling_face:

6

Hi @codrelphi, We are planning to do the same. can you please confirm if you have bought license for each local service development installation on developer’s machine ? How did you progress? Please respond as this is high priority for us. Thanks in advance

8

We didn’t contact SAG to get licence information of LSD. Our management has changed the usage requirements. So finally we drop out LSD and went to the idea of an IS instance for each developer. We’ve got another way to versioning our packages as it is our main goal.

In your case, if LSD is your main requirements and you get information for the licence part from SAG, don’t hesitate to share it here.

9

LSD is basically around the idea of one IS instance for each developer, which allows local git repos and the implementation of git patterns (such as feature branch) to better manage and automate your build and deployments.

The licensing aspects depend on your contract.
If it’s a recent transaction based contract, chances are, LSD is already included (like WmTestSuite.)
If you’re on an older type of contract, CPU based, then it’s an add on and you need to get in touch with your account exec to know how much it costs.

2 Likes
10

That has not been my experience. Each has pros and cons and areas that can inhibit progress. In general, I think the downside of central development is overstated and the challenges with local development are understated. Indeed, I’ve seen that when someone advocates against central development, they don’t even list the cons/gotchas of local development. Just the “bad” aspects of central. But each has its charms and its frustrations.

It is one possible suggested way, not necessarily the way. As with any tool, it has pros and cons. Be sure to understand its limitations. There are things that it does not do for which you will need to define a way to address.

11

@reamon Thank you for your reply.

In fact, my affirmation is from the reading of the documentation. As WmVCS package is deprecated with IS 9.9, SAG recommands to use LSD along with a version control system to do the versioning.

But I agree with you that each type of development (central or local) has its pros and cons. As technical specialist we can found many ways to achieve our goal even if it is not a pseudo-best-practise. That is what is happening in my actual case. Our main goal is to versioning our packages, so we found a way to do it by still working with the central development.

Here is the affirmation from the documentation (can be found in the part Using the Local Service Development Feature):

Important:
The WmVCS package, which provides the functionality for using the VCS Integration Feature, is deprecated as of Integration Server version 9.9. Software AG recommends that you use the local service development feature (Local Version Control Integration) to check package elements and their supporting files into and out of a version control system (VCS) directly from Designer.
12

Thanks everyone for this interesting discussion!

I think we are touching on a number of conceptual aspects, sometimes in a slightly tacit way.

In particular we need to distinguish the various facets of “versioning”. Here is my take:

  • If we check something in (aka commit) via a VCS (irrespective of whether that happens on a local or central environment) that is a change set.
  • Publishing package XYZ 1.2 is a release.
  • Supporting different “levels” of an API or service are versions and they are part of a release.

Not sure how many people will agree, but this way to separate things has served me well in numerous discussions. At the very least it helps to raise awareness that “version” is not a completely clear-cut term.

Topics that are closely related with versioning are

  • how to integrate work from different people (CI/CD vs. central DEV environment)
  • how to track work and the way changes are linked together technically as well as to a work item (ticket/issue)
  • compliance and traceability of what code exactly was in production when
  • etc.

This is a very wide field that falls in the SDLC bucket. At the end of the day it is in my view about how to integrate business agility (through efficient software delivery), compliance, and operational resilience. And probably some other aspects that I have forgotten here.

Looking forward to comments :slight_smile:

2 Likes
13

Certainly. But “recommend” does not mean “only”. :slight_smile: There are many things that vendors recommend that, for one reason or another, would not necessarily be followed.

The server-based VCS integration definitely had constraints. Just be aware, so does the local development version control support.

As an FYI: we don’t use any VCS in our environment. Which may cause some to gasp. :slight_smile:

I’ve posted this before, and this will likely not be the last time :slight_smile:, but in one view of the world, there is no such thing as a best practice. Just practices that other people have used that might also work for you. [Edit] If someone indicates “this is a best practice, so you should do this” one would do well investigate further to see if it really would work in a specific situation rather than just blindly adopt it.

Your situation may be different, but it seems like this is an “action” intended to achieve a goal of some sort, rather than a goal in and of itself. Of course, the value and benefit of versioning developed components is widely covered on the web in a myriad of articles and forums.

I know this is intended in the general sense, but wanted to note that these things are not mutually exclusive. Central dev can be part of a CI/CD framework.

My thanks too! It is always fun and educational to learn what others are doing and the challenges faced.

14

LSD is a designer feature which allows you to manage package versioning from the Designer. It provides some features to manage your custom packages outside the IS/MSR packages folder (better separation between middleware and code), and it also makes it easier to manage packages in containerized development environments.

But you can certainly version your packages without the LSD. A git CLI or GUI can be used to version your packages.

The WmVCS package deprecation message tells you that SAG recommends the LSD. It’s just a recommendation, not an obligation!

Even though I am a strong advocate of local service development, this WmVCS package deprecation in itself should not make you switch to LSD if you’re currently doing development with a central environment.
You should switch to LSD if you want to realize the benefits of LSD: proper git branching, real continuous integration, out of the box separation between the middleware and the application code.
Otherwise stick with central development, create a git repo for your packages (or even better, one git repo for each package, which is the new SAG recommendation, since the iPaaS and wpm work this way) and manage this git repo with a git CLI or GUI.

2 Likes
15

Hi,

WmVCS only supported very few VCS systems, while Designer LSD is Eclipse based and you can integrate with any VCS for which an Eclipse plugin is available.

Therefore, whenever possible LSD should be preferred instead of using deprecated WmVCS.

Regards,
Holger

16

Forking/branching seems like it is viewed as a “must have” by the majority of developers. Understandable. But one should not assume that it is always needed/valuable. Another view to consider: don’t fork/branch. We have been able to follow this for long time. I do not miss the tedium of merging FLOW services or fixing bad merges.

This is a personal growth area for me to try to not be so pedantic :slight_smile: but I bristle whenever someone has qualifiers like “true” or “real” in front of some item. Like “true multi-tasking” or “real CI/CD”, etc. I bristle because it implies that the unadorned label like “multi-tasking” or “CI/CD” or whatever is ambiguous (it is) and “true” or “real” clarifies in ways that everyone understands and agrees to (it doesn’t). IMO, “true” anything or “real” something is just as ambiguous and requires a “what specifically do you mean by that” type of exchange.

I agree that one should not use WmVCS. I do not agree with the default of using local service development (I avoid using the acronym due to its existing history with something completely different). This is not to say I’m advocating against using local development. Just advocating for fully understanding the options and following what makes sense in a given environment.

2 Likes
17

Can you elaborate on what specifically you mean by “middleware” vs “code” in this case?

18

Using branches (unless they are REALLY short-lived, as in a few hours) and CI/CD are mutually exclusive. I know that some people like branches because they seem to make things easier. And they do for a part of the overall process, but not overall.

19

Couldn’t agree more. It is important to understand the relationship between branch/merge operations and organizational issues. All too often branches are used to separate work along the lines of the organization (as a variant of Conway’s law).

The problem comes if things need to be merged. But wouldn’t it make more sense to address this on the organizational side? Like have a single team with clear responsibilities? So that usually people work on a piece of code on their own?

20

Middleware = Integration runtime (IS or MSR), code = your custom packages.
LSD allows you to manage your custom packages outside the IS/MSR packages folder.