Tuesday, August 28, 2012

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.