July 19, 2019 at 12:13 pm
My workplace is looking at moving to a continuous deployment / continuous integration model for our development, including SSRS reports. Right now, while we have system generated change tracking that can be used for comparing report definitions from the catalog table , right now, our Auditors do not consider this sufficient for proving change control. With our current approach, we deploy individual reports rather than the entire SSRS project. With this method, we are able to point to the reports other than the ones that have been deployed as part of a change and show the modified date. If we move to deploying based on a project, the modified date always updates, even if the RDL definition has not changed. While there are a number of ways to deploy specific reports such as through powershell, it involves having to maintain non-default code on our CI tool (Teamcity).
Does anybody have any idea of a better way to manage the deployments while using just msbuild to do them, or if there is something else that can be used to show through a front-end, or even a screenshot of something within the database that only specific reports were modified? Unfortunately, our auditors are really fond of screenshots.
July 19, 2019 at 12:33 pm
IMHO, the auditors are incorrect here and need to be trained that your controls are much more finite than their broad recommendation.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply