Hi we’re looking at using git for our SSRS Report. Just wondering if its possible to stop users being able to deploy a ‘bad’ copy of a report without doing a commit/merge request first?
Thanks for joining us! I think I can answer your question and help you come up with a workflow that works for your process, but I have to admit that I don’t really know much about SSRS or the reports that it creates.
Could you please give me a bit of background information into your current report generation workflow?
Hi @that-pat ,
Thanks for getting back to me.
What we’ve like to be able to do is makes changes to a reprot and commit these to Dev. Once they are commited and been reviewed we’d then like to merge these into the master.
Only then we would like users to be able to deploy them.
The trouble in SSRS with reporting is that when you are in the project you can just right click and hit deploy on the report which isn’t ideal as you can still deploy a ‘bad’ copy of the report.
Any ideas/suggestions how we can stop this? So that only when the merge request has been accepted/closed we can deploy?
I know believe we can use auto deploy in GIT, but this is far to much hassle as we have multiple report servers for different clients.
As stated previously, I’m not an expert in SSRS, so you might get some better ideas from Microsoft Support for SSRS, but looking at this article on deploying reports in SSRS, it looks like there is a permissions model that you might be able to use to help limit who can deploy reporrts if I understand this correctly.
If you need to have a lot of control over who can publish what, setting up a continuous deployment system is probably the way to go so that you can have all deployments made by a machine user instead of by individual users. I know that you said that this is too much hassle, but if this control is important to you, that’s probably the easiest way to get this level of control.
Fortunately, most continuous deployment systems do have a way to copy deployment jobs or allow you to set up a deployment template so that once you go through the effort of setting up one workflow, ever subsequent workflow should be easier to set up. It might be worth trying to set this up as a proof of concept for one project and seeing if that eliminates the problem of bad deployments.
Figuring out these processes is always a bit of a pain, especially when dealing with user permissions, so I hope this information is helpful. If I can be of further help, please let me know.
I would suggest that you run two instances of SSRS, Prod and Dev , and restrict the permission on Prod so that only limited Admins and a Service Account are able to write to it, while having the Dev instance less restrictive (you could do this on a single instance, but there would be more busy work to implement). Then have a process which deploys from your master (or other) branch to SSRS Prod using the Service Account, which can be kicked off by appropriate users.
The biggest hiccup is that you don’t have a great way of knowing what differs from Prod and master. You either have to fetch everything from Prod (rather slow), compare and push differences, or you need to use something like Git Notes to add a Last Updated to the Git Object, then you can pull use just last updates times and decide what to push from there.
Using something like ReportingServiceTools, a powershell library for SSRS, may help.