What lessons have we learned about managing report projects and what are the best practices?
Since each report is stored in a separate XML-based RDL file, Reporting Services projects play well with version control. Visual Studio Team System and Visual Source Safe integrate with the Visual Studio/BIDS shell and third-party source control solutions like SVN may be managed from the file system. Reports that have sub reports, drill-through reports or other dependencies should be managed in a BIDS project. Report Builder 2.0 or 3.0 may also be used but designers should mange their reports on the server rather than in the file system. It’s best to use one tool or the other for any given report.
The deployment approach can be no different than your application development build process but it shouldn’t be over complicated. Over all, experience has proven that report projects are best kept simple because you typically don’t have the same level of component interdependencies that you would in dev. projects.
In my experience, there are two different approaches that may work depending on your team structure and methodology. You can manage the reports through all deployment phases from Visual Studio. This puts the developer/report designer in the position to manage reports coming out of testing and into production, which may not always be ideal in a formal IT environment. The other approach is to have the developer/report designer deploy reports to a dev server and then for a deployment manager to capture and manage the RDL files in file system based version control, using scripts to deploy to QA, UAT & Production.
Keeping report definitions in projects and the server(s) synchronized can be tricky but it’s manageable as long as you set ground rules for the team, use version control and conduct regular status checks. RDL files don’t have build numbers so it’s important to keep one official copy of the most recent RDL in a designated project or folder. The RDL Scripter, mentioned in another blog post, can be a useful tool for cloning deployed reports to the file system.