BusinessObjects, Web Intelligence , Crystal Reports

Crystal report version control

April 4th, 2009 by Kevin McManus Leave a reply »

BOE handles report migration in a slightly different way than a JSP file for example. Reports are primarily identified by a GUID and not solely on the name. Also the directory in which an object is referenced plays a large role so report objects should be kept in a maximum of two structures. One for unit testing and one for synchronization per the steps below.

In summary
1) Reports should be kept on a network share or subversion with version numbers in the file name and in the report properties.
2) Once reports are modified they should be published (File menu –> save as –> enterprise) to a TEST folder on level down from the main folder in the BOE Repository on the TEST BOE Server.
3) This version will have a new version number in the report properties and in the description.
4) The TEST Report Launch application that points to the TEST BOE Server and will see that folder within the application. The reports can then be tested. If they work sufficiently the Report should be published to the main folder from designer (File menu –> save as –> enterprise) without the version number in the title but still with the version number in the report properties. This replaces the existing report on the UAT server but PRESERVES the unique id that keeps the reports in sync with Prod BOE. UAT or system testing by a fellow team member can occur with the report in this main folder location.
5) This report in the designer can then also be checked into the network share or subversion.
6) Then the import wizard will migrate between the main folders in TEST with PROD. The DEV folder where the versioned reports are kept is not migrated to production.

Other points
a) As discussed the best practice no one should ever publish a report directly to PROD, nor have the rights to do so. It is protected and serviced only through proper administration. This supports the checks and balances that ensures that testing is properly completed and that roll-backs are easier.
b) Reports are not moved. Reports are published per the steps above so that if there is an issue identified during testing the prior version is already available online and clearly versioned so that it can be reverted on the TEST server without any affect on production. In the event that this reverted report needs to be imported to production the steps above will ensure that the proper version is in sync between environments.
c) This means that reports are not developed or published directly to the BOE PROD server keeping it pristine.

Kevin McManus
www.mcmanussoft.com

Advertisement

Comments are closed.