Since I stated that the VCS Integration Feature is more or less unusable, I thought I should offer alternatives for consideration.
Option 1:
Use any VCS and develop procedures for developers and release managers to follow.
Manage versions at the package level, not the service level. Versioning at the service level is somwhat akin to managing a Java class at the method level.
Have just one person at a time modifying a package.If many people need to make changes to a single package at the same time it may be an indicator that the package scope is too broad.
When deploying always deploy from the VCS, never from another IS.
Keep a change log for every package. Either as a log in the VCS or in a text file in the package direcotries. Or both.
Never deploy adapter connections.
Avoid branching and merging whenever possible. Since this approach really has no tools to help with these tasks, and thus would need to be done manually (mostly), these actions should be avoided.
The key to this approach is that everyone follows the processes. It isn’t as nice as having a tool that we’re all familiar with for Java development but it is workable and doesn’t lead to erroneous assumptions about VCS capability.
Option 2:
Use a tool like CrossVista TEAM ALM Server (I am not affiliated with this company or product). I won’t repeat the marketing literature here. Those that are interested can review their web site. It provides many of the VCS features that one expects the VCS integration feature from SAG would provide but doesn’t. Alas, my only exposure to this tool is a brief evaluation. It works as advertised. Perhaps others who have used the tool for real work can chime in.
#Integration-Server-and-ESB#webMethods#Flow-and-Java-services