Crossvista: ALM and concurrent development for webmethods (part 1)

Why CrossVista?

The webMethods platform comes out of the box with a VCS and a deployment solution. Although the deployment feature works quite well, the VCS doesn’t. This is not a big problem when development is being done in small groups, but when it comes to concurrent development for large enterprises we see arise some problems:
* What about development teams distributed all over the world? How can they be aware about changes being done by other developers?
* What about sandbox development? Suppose every developer has his or her own integration server running locally. How is it possible to manage packages and releases in this case?
* How can we store all the assets of a webMethods release (package, configuration files, sql files, …) in subversion?
That’s where CrossVista comes with an answer to these questions. CrossVista provides a solution to concurrent development on one side and application lifecycle management on the other side, but very specifically for the webMethods platform.

ALM: how it works

The most important component of CrossVista is TEAM server, responsible for the application lifecycle management part. In TEAM server you start defining repositories. Each repository maps to a specific folder (or a repo) in a version control system (VCS). You need to define one repo per physical webMethods environment (development, test, QA, production, …). This is important for a correct working of TEAM server. Each repository keeps track of the releases for that physical webMethods environment, i.e. the test repo in team server contains the releases deployed or to be deployed on the webMethods test environment. The same is true for the QA and production repos and environments.
Once a release has been created in the development repo it will be moved to the next repo by executing a so called promotion. In the promotion action, promotion rules can be defined so that settings can be adapted to work in the test environment. This means that releases in the test repo contains specific settings (adapter connection, extended settings, sql files, …) for the physical webMethods test environment. Releases in the QA repo will contain settings for the QA webMethods environment and so on.

Concurrent development: how it works

TeamVCS is a CrossVista solution for concurrent development on webMethods. It is an integration server package that needs to be installed on every development integration server. It communicates with the central TEAM server to download releases and install them on the development machines or to upload new releases in the central TEAM server when development has been finished. This makes CrossVista suitable for shared development (on one integration server) or distributed development (every developer has its own integration server).

In case of distributed development every developer checks out the releases he or she needs to work on and checks them in when development has been finished. Multiple developers can work on the same release simultaneously.

There is also a TeamVCS plugin for webMethods Designer to make processes and CAF projects also part of a release.

 

Author: Dimitri