CROSSVISTA TEAM SERVER FOR WEBMETHODS

Enterprise Class Version Control and Change/Config/Release Management for webMethods


Please click here to view Brochures, Whitepapers, or Recorded Webinars.
Please click here to schedule webex demo or evaluation.

At the core of TEAM's value is the concept of using a “Release” to manage versions across an entire webMethods solution. This is very important. A TEAM Release is a logical grouping of all code, configuration, and database info required to support a webMethods project.

 

 

 

 

 

 

For example, a given Release may include webMethods components of Integration Server, Trading Networks, Broker, and Process Models. In addition, there are several configuration file and database table changes that may also be required to support the entire solution. TEAM allows you to group together all relevant components into a single logical group called a Release. Once those Releases are defined, TEAM allows you to do a couple key things:

Identify Changes – TEAM can compare an entire saved Release to either another previously saved Release or a live environment. If there are differences, then TEAM can tell you exactly what/where those differences are and who introduced those changes.

Promote/Rollback Entire Releases – Using promotion rules, TEAM can automatically promote or rollback an entire Release to any environment at the click of a button.

These features can be applied to help manage the entire SOA/BPM/Integration development lifecycle.

IN YOUR DEVELOPMENT ENVIRONMENT…

•  Track what, where, and who made changes to a given release in a shared development environment. This allows you to perform audits where none was possible before.

•  Selectively add changes to a given Release. This is especially important when trying to add fixes to an environment when more than one change has been introduced to a shared development environment.

•  Optionally, configure TEAM to manage concurrent development efforts and leverage TEAM's checkin/checkout functionality to perform diff/merges on newly developed code.

IN YOUR QA/UAT ENVIRONMENT

•  Validate your environments… don't spend days testing the wrong code. Perform an automated comparison of the live QA environment to the Release that “should” be on that QA environment. This will ensure that you're testing the appropriate code in the first place and nobody has manually made a change to the QA environment that shouldn't have been there.

•  Perform an automated comparison of the last Release on the QA Environment to the Release you are about to deploy to production before actually deploying it.

IN YOUR LOAD BALANCED OR CLUSTERED ENVIRONMENTS…

•  Synchronize your clustered environments. At the click of a button, you can validate that your live load balanced or clustered systems are synchronized both with each other as well as the Release that should currently be deployed on that environment.

IN YOUR DISASTER RECOVERY ENVIRONMENT...

•  Automatically update your DR System. A scheduled TEAM script can constantly search your current live production environment for new changes. If changes are identified, TEAM can automatically save off a new release and, either automatically or with one click, promote that change to your Disaster Recovery environment. You will have the confidence that your DR Environment will never be out of synch again.

IN YOUR PRODUCTION ENVIRONMENT...

•  By pre-configuring your TEAM promotion rules, TEAM can increase the speed and accuracy of any environment setup, configuration, and Release promotion.

•  Troubleshooting production issues are easier when you know where to look. You can verify at the click of a button that no changes have been made to the live production environment… including basic configuration changes.

•  Use TEAM “Regular Expressions” within your promotion rules to convert environment specific configuration data such as promoting a release from one environment hosted on a Windows platform to a production environment hosted on a Unix platform.

•  Manage versions in Production irrespective of package naming. Traditionally, users try to use a process driven approach to version packages. However, just because a package is named Package_v1 does not mean that the code within Package_v1 is the code you expect. TEAM tightens the process you're currently trying to implement by ensuring that what is in Package_v1 is exactly what you expect.

•  Manage Complex Production Deployments – Many customers use individual development servers for development but eventually need to migrate to a more scalable distributed architecture in production. In some cases, code within a single IS package might need to be distributed across multiple tiers of servers (i.e. Public Facing Servers, Processing Focused Servers, and Internally Facing Servers). TEAM promotion rules allow you to automatically manage that distribution without changing your code. Because TEAM groups all code, configuration, and database info within a logical Release, you can still validate the Release against the distributed production environment.