Fatwire’s CS 7.6: Content Server Developer Tools (CSDT): review

Fatwire recently released 7.6 version of the product with one of the interesting addition is CSDT (Content Server Developers Tool). Accoridng to Fatwire,

CSDT enables developers to work in a distributed environment using tools such as the Eclipse Integrated Development Environment (IDE) and version control system (VCS) integration. CSDT does not interfere or integrate with other development models. Using CSDT, a development team can manage Content Server resources and exchange those resources with other members of the team

One of the important factor which comes along with CSDT is file system representtion of CS repository. What CSDT does is convert the native CS asset representation to .mail.xml files and vice-versa.
This enable developers to work either in CS or in eclipse. Once the resources are in filesystem, its much easy from management and deployment point of view.

Positives

• Easy to setup and get started
• Finally a development tool to make developers life easy with more controlled release and code management
• Develop JSP elements with standard Eclipse features such as tag completion, syntax highlighting, debugging, and so on
• Command line utility to export, import ,list both CS and workspace artefacts
• Manage most of the CS work from within eclipse, including log level changes, access to log files etc.

After playing a bit with the development tool, here are my findings around CSDT OOTB usage:

• While exporting/importing data from CS using command line utility, there is no way to specify absolute path for datastore. It is always relative to export/envision within CS directory
• CSDT import requires workspace to be present on the server before running the script within export/envision. There is no way to specify remote workspace/zip file, though you can start the process remotely
• Incremental builds, for example, only changed files from CVS, can’t be achieved using import command line utility as the utility looks for all the dependency files to be present in workspace even though they have not changed
• “modifiedSince” option on command line only works for Assets and not for other Fatwire artefacts
• Logging available is limited
• Listing commands (listds, lisrcs) doesn’t check for dependency
• There is no option to see if the existing artefacts within a workspace meets all the dependecy checks before importing in an environment, though when you run import it log errors of not locating the dependent files
• There is no support to export/import workflow artefacts from CS and vice-versa
• There is no option available to export users association to sites

So, typical steps for moving a new site from one CS instance to other includes:

1. Export/check-out from CVS @SITE, @ROLE, @ASSET_TYPE, @TREETAB, @STARTMENU, @ELEMENTCATALOG, @SITECATALOG, @ALL_ASSETS for a site
2. Import all the exported artefacts in a specific order with @SITE first and maintaining all dependencies
3. Manually setup workflow in the new environment (assuming there is no connectivity between the instances)
4. Manually configure users to site association

And Bingo, new CS instance is up and running with the latest managed code.