webMethods provides basic version control features to integrate with third party VCS products however only a limited number of third party products are supported with limited features. There are very few proper version control tools (example - Cross Vista) available for webMethods and a license fee is payable for these. In case of budget constrains and supportability concerns, light-weight custom version control automations can be build around Integration Server with nominal effort. This paper explores an alternative custom solution to achieve the same.
Architecture
Divide the solution components into the following logical layers:
Repository Layer stores the artifacts under version control and provides functionalities to interact with the repository.
Interface Layer consists of API and command line utilities to expose the functionalities (eg – checkin, checkout) of the VCS product.
Automation Layer is the custom build components which consist of scripts and services wrapping the interface layer.
Server layer is solution backbone (mostly webMethods Integration Server) which hosts and executes the automation layer using the service framework and invoke manager.
Client Layer is the interface to developer communities to use the version control automation layer in an interactive manner (client tools, browser, custom GUI) and command line utilities to perform the version control operations.
Implementation Cycle:
The implementation can be achieved through the following 5 steps:
1> Identify the custom version control requirements (Example - manage the code lifecycle, manage locking, track revision history etc).
2> Map the custom requirements with the functionalities supported by repository layer. Custom solution may be required if there are any functionalities gap.
3> Identify the interface layer components exposed to implement the functionalities.
4> Write wrappers and logic for the automation layer.
5> Expose the wrapper services to the client layer (through GUI or client tools).
Key Functional Features – Case Study with webMethods IS packages
Basic version control requirements in an enterprise focus on certain aspects however there could an array of diverse requirements. This section discusses some of the key functional features in alignment with Integration Server packages as an example.
1> Manage Code Lifecycle
2> Manage Code Version
3> Code Control
4> Manage Revision History
Manage Code Lifecycle
IS Package can be considered as a unit of change. The lifecycle of a package in a controlled IS environment is ideally as follows:
The package is created/generated in Developer IDE. The developer can add the package to VCS right away or choose to work on the package before adding it to VCS.
Add is a one-time operation to create the path of the package in the VCS repository and add a default version of the package to the repository.
Subsequently the package is checked out, changed and checked in several times during the development and maintenance lifecycle of the package. Every checkin publishes the package from IS as a zip file and every checkout installs the package in IS from the zip file retrieved from VCS.
Manage Code Version
There are two versions to deal with – the IS package version and the VCS version also known as revision number. The automation layer should automatically manage the package version. A default version number is assigned to the package (eg. D=1.00) during the add process. Every subsequent checkin operation increments the package version by a unit (d=0.01). If supported use the package version number as the VCS revision number else capture the package version in the change history of the package.
Code Control
With every checkout the package path in the VCS repository is locked and the entire package is checked out from the VCS and installed in the Integration Server with a IS lock assigned to the developer. The locking ensures no other developer can make changes to the code at the same time.
Once checked in the lock is released from IS and VCS allowing others to change the package.
Manage revision history
Every checkin (including initial add) operation should captures user comments and IS package version number and adds the same to the revision update history. This is one of the ways to map package version with the VCS revision number. Refer to the example below:
No comments:
Post a Comment