This documentation is no longer maintained and may contain obsolete information. You should instead refer to Application onboarding.
On this page:
By default, when accepting a version and setting it as the current version, the source code Deployment Path points to the Deployment folder configured in the CAST Management Studio (Window > Preferences > Platform Settings). You can, however, choose to store the deployed source code in your own standardized file system hierarchy. There are many ways to organise this and the document below is just one way of doing so.
|Note that this is entirely optional and CAST highly recommends that the default paths defined in the CAST Management Studio (Window > Preferences > Platform Settings) are used where possible.|
The source code of the application to be analyzed should be stored on the fastest disk of the server since the analysis process requires multiple accesses to the application source code and it is highly dependent on I/O performance of this drive. CAST recommends you map this application storage drive to the S:\ drive. A file system hierarchy should be created as specified below.
It is recommend you store the application source code and its processed version in the following set of folders:
The database extraction needs to be managed separately from the source code of the application and a similar file system structure is recommend that include the following folders:
Similarly each third party component part of the application need to be processed in a separate set of folders:
CAST recommend to store the analysis logs on a separate drive - the I:\ drive
The logs and storage folders used by CAST Management Studio should be stored at:
as shown below (CMS Preference windows):
|Note: these configurations are shared by all users of the analysis server.|
Several applications don’t provide the environment libraries such as weblogic’s jar files or other third party tools API. These libraries are common to several applications. To gain efficiency and avoid having to reprocess these libraries for each application - e.g. un-compile jar files - it makes sense to store them in a centralized location/folder. CAST recommends using the following folders and naming conventions:
All the different templates for UA, UI and Function Point filters needs to be stored in a shared location in order to facilitate maintenance if you are facing a large deployment:
During the analysis it is recommended to create a backup of the various analysis configuration and logs. Additionally, backup of the three core database schemas is also highly recommended. CAST recommends storing analysis logs on the R:/ drive using the following directory structure and naming conventions:
|The R drive can be a low performance drive since this is used only for backup and archive purposes (a NAS drive for example).|
After successfully on boarding an application the next step to support ongoing re-analysis is to pursue the automation of the analysis process via the creation of CLI scripts and batch files - see Analysis Automation v1. This automation may address the import of the source code, unzipping source code in the target folder, clean up the code, pre process the code, and kick off the analysis and snapshot generation as well as the generation of report and the wrapping up of the analysis activity by generating backup and archiving the analyzed source code.
CAST recommends you organize your automation scripts on the I:/ drive in the following folders and adopting the indicated naming convention. Access to this folders should be restricted to the CAST Admin:
|It is a CAST recommended best practice to a have one batch named <appName>.bat stored in I:\Automation\Batch, which is used to kick off the automated analysis process.|