October 26, 2015 at 4:54 pm
I run a small reporting team / business intelligence team that uses the full Microsoft stack of tools - ie, SSRS, SSIS and SSAS. Over time, most of the team have cultivated their own idiosyncratic workflows. For the most part, since we typically work autonomously, this hasn't been a major issue as long as basic good practices are maintained. But we are increasingly working on larger, collaborative projects and I want the team to cultivate some standardised approaches.
To that end, I'd really appreciate any thoughts on some of the following issues;
* How do you structure your reporting services projects? eg, do you create a new project for each... "group" of reports? If so, how do you group reports?
* How do you handle versioning and source control? Do you use a version control system? If so, which one?
* How you move from development to production? In particular, how does this work if you are using a version control system?
* What do you use for documentation? What about report meta data - eg, do you document report "owners"?
Whenever I try to google for "best practices" and "reporting services", I tend to get results around deployment of the infrastructure. I'm struggling to find resources on best practices for actually using the products.
October 26, 2015 at 9:01 pm
I use the below approach in my company , its worked for me so far and is actually something carried over from my days as a BI developer
* How do you structure your reporting services projects? eg, do you create a new project for each... "group" of reports? If so, how do you group reports?
Single solution multiple projects , projects are decided by business alignment for example all reports that are viewed by the same business function go in the same project, where a report is viewed by multiple teams they either get thier own copies or the report belongs to the team that requested it.
* How do you handle versioning and source control? Do you use a version control system? If so, which one?
I use Source control to handle versioning , TFS and Collabnet are good choices.
* How you move from development to production? In particular, how does this work if you are using a version control system?
TFS supports CI and as such is a better tool for managing version control for the MS Stack. deployments are still done manually mainly because we don't have too many reports deployed at the same time anyway.
* What do you use for documentation? What about report meta data - eg, do you document report "owners"?
Don't really use or know of any software that documents SSRS Reports , we use a WORD Doc complete with user permissions , field description the works.
Whenever I try to google for "best practices" and "reporting services", I tend to get results around deployment of the infrastructure. I'm struggling to find resources on best practices for actually using the products.
You might find some good practices if you start looking for SSRS Reports with share point or just plain document management practices.
October 27, 2015 at 9:42 am
* How do you structure your reporting services projects? eg, do you create a new project for each... "group" of reports? If so, how do you group reports?
Multiple projects, usually demarcked on business area and/or permission groups; e.g. most groups have a 'normal' and 'restricted' project.
* How do you handle versioning and source control? Do you use a version control system? If so, which one?
TFS
* How you move from development to production? In particular, how does this work if you are using a version control system?
Deploy straight from TFS with 2 clicks 🙂
* What do you use for documentation? What about report meta data - eg, do you document report "owners"?
Paper trail mostly, although have a selection of meta reports to audit report use & performance.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply