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

Components

CrossVista as a whole contains the following parts:

• CVCM package: the core TEAM server product 
• CVCM agents: packages that need to be installed on every integration server TEAM needs to connect to. Will be done automatically in the background. 
• TeamVCS package: package for concurrent development, to be installed on every development integration server 
• Team API: API to access the team services 
• CvTunneler.jar: tunneling for webMethods reverse proxy 
• TeamVCS plugin for eclipse (webMethods Designer)

 

System Requirements

CrossVista can be run on the latest versions of the webMethods platform: 6.5, 7.1, 8.0 and 8.2. Many version control systems are supported out of the box: CVS, SubVersion, VSS, ClearCase, TFS, but you need to mention the version! Only a limited number of versions are supported and not following these requirements will make CrossVista possibly not work. Since the CVCM and TeamVCS packages contain java server pages, the WmTomcat package needs to be enabled on every integration server containing one of these packages.

Installation

Installation of CrossVista is very straightforward since the core products are nothing more than just packages that need to be deployed on an integration server:

• Install the CVCM package on one and just only integration server. This integration server will become the TEAM server. There are no recommendations whether this can be installed on an existing integration server, hosting other packages or whether a separate integration server needs to be taken for a good operation. 
• Install the TeamVCS package on every integration server that can be categorized as development machine. 
• Install the TeamVCS plugin for webMethods Designer in case you want to develop BPM or CAF projects. 
• Assign users to the TeamAdministrators and TeamUsers groups and ACLs in integration server. These groups and ACLs will be created when you install the CVCM package. 
• Give non administrators that need to access Team server or TeamVCS access to WmTomcat. By default only Administrators can access the WmTomcat package functionality. You can add them in the web.xml file under web/WEB-INF of the WmTomcat package.

 

CrossVista Terminology and workflow

Two import names need to be kept in mind before you start working with CrossVista:

• A TEAM project: a definition of all the constituents 
• A release: an instance of a project

As you can see you can make the link with webMethods deployer naming. You define a deployer project, where each project can have multiple builds.

In order to work correctly with CrossVista, the following workflow needs to be followed:

• Define a new TEAM project. In this project you define the constituents that form the project (packages, configuration files, sql files, …) 
• Upload the project in the version control system. Here a new release will be created and the release will be stored in the development repo 
• Promote the project. Promotion means moving the release from one repo to another using promotion rules. In these promotion rules you change the configuration and target servers to be conform to the new environment. Promotion does not mean you deploy the release! 
• Deploy the project. Here you select the release from the repo that corresponds to the physical environment on which the release will be deployed. 
• Analyze the project

 

Features overview and their strengths and weaknesses

• Automated release cleanup. This sounds promising, but the feature only allows cleanup after x days. This means that when you don’t make any new release during x days, all your releases will be deleted 
• One repo per environment. A good feature to keep separate releases per environment. You always need to be aware in which you are working. This feature is prone to mistakes. 
• Almost everything can be part of a release: 
• IS services 
•  Extended settings 
•  Adapter connections 
•  Schedulers 
•  Users, Groups, ACLs 
•  Broker clients 
•  TN, MWS, BPM resources 

• Dependency definition between projects. Very useful feature. You can define the type of dependency: latest release, a specific release or a range of releases. Team server detects the missing release and will automatically add the missing release. 
• Visual diff between releases. Probably the best feature in Team server. It allows you to compare two different releases visually for flow services, document types, java services and flat files. It also allows you to make a live compare between a release and live integration servers.  
• Create a new release based on an existing one. You can make a new release, which is a subset of an existing release or you can merge different releases. This seems to be a dangerous feature, because you need to be aware very well of what you are doing. A mistake can be made quickly. 
• Site definition and check whether sites are in sync. You can group multiple integration servers in a site and check whether this site is in sync with another one. By default integration server also provides this feature when they are running in a cluster. 
• Built in scheduled tasks. This feature doesn’t seem to be very useful. You can create scheduled tasks for automated upload, deploy, promotion, etc. The question is why would you do that? The TEAM server solution seems too complex to me to automate such things. 
• Easy to keep track of changes since release notes can be added 
• Out of the box support for many version control systems, but you need to be aware of the version you are working with. 
• Automated creation of revisions, triggered by the lock/unlock operation in developer. Doesn’t seem to be very useful since a good practice is to make a full release when you are finished. Can act as a backup mechanism. 
• Concurrent development. Nice feature in case you need it, but I haven’t found an environment so far where this feature has been missing. 
• Support for both shared development (one integration server) and distributed development. The TeamVCS feature seems to be very useful in case of distributed development, but not necessary when development is being done on one machine. In that case you can start making releases directly from within team server when development has been finished.

Author: Dimitri