December 3, 2007 at 2:46 am
I'm trying to work out a better way to move reports through the development lifecycle and I would appreciate your advice or examples of how you do this, and the pro's and con's.
At the moment, I'm deploying reports to a Test server for users to test and approve. Once they approve, I'm deploying the reports from the Development (VisualStudio) to Production. I'm concerned about following the deployment lifecycle and moving these files from DEV to Production, particularly in cases where there is a fair amount of configuration necessary in the deployment. For example, I frequently develop one report that runs against several databases. In the absence of being able to choose datasource as a report parameter, I deploy multiple copies of the report, each pointing to the required destination. Each data source needs to be updated, posing manual configuration risks.
What do you do? Is there anyway to copy files from server to server, or do I need to investigate report server script files?
Thanks.
December 4, 2007 at 7:57 am
First, I'm not sure you're aware, but in Reporting Services, by default you don't overwrite your data source when you repromote a report. Therefore, your production data sources remain fixed / stable once you set them up and configure them.
I would also suggest that you make sure you test your reports in a development environment before promoting to you "test" server for the users. This could be either a local implementation of report services (on your PC) or on to a development server. There's some subtle differences in Visual Studio vs Report Services and you may not find it always renders the same.
Make sure you take some time to correctly configure your deployment targets (via Configuration Manager).
In a environment where duties are separated by job function, and where different people have strict security policies, I'd recommend the following set up. Of course, some may consider this overkill (it's set up with bank perspective on division of labour), but you'll get the idea:
For Development
- VS project resides on a commonly accessed server. Project should be preconfigured for all target environments.
- Project must be checked into change management tool (Visual Source Safe) before it can be promoted.
To promote to Testing (Quality Assurance).
- QA Group check the Source safe status. Copies the project to QA file server.
- Checks QA deployment options (target, data source overwrite).
- QA Group opens the project (via VS) and promotes the reports to QA report server(s)
- adjusts / checks all data sources.
To Promote to Production.
- Production implementation group opens the project from the QA file server.
- Checks production deployment options
- promotes the reports to prod report server(s).
- adjusts / checks all data sources.
NB. Add a file to the Miscellaneous folder (i.e. a text file) for special instructions and other "read me" issues. This can/should include things like any deleted item (reports or data sources), special security setup) and anything else you can think of. Train everyone to use / check this file when dealing with a project they might otherwise be unfamilure with.
December 4, 2007 at 9:07 am
I used to also keep a branch in VSS that shows what's being deployed at any point in time. So once you've decided what needs to move, branch (copy) that in VSS into a deployment project. This will help you keep straight what changes and what you need to check on.
December 4, 2007 at 9:11 am
How do you copy the Reports from the Test/UAT server where they've been deployed?
Great responses.
Thanks.
December 4, 2007 at 9:16 am
You're actually deploying from the VS project, not from the Report Server. That's why the project is copied to the QA file server, to maintain tight control over what happens to it (i.e. no changes in QA folks!). You use VS to deploy to production.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply