I’ve been on kind of a DevOps kick lately because of some work that I’ve been doing for a customer. It’s been in my head that automation is one of the key pieces of a good DevOps solution. While I was talking to a different customer, it came out that they didn’t have their SQL Server schema code or SQL Server Reporting Services (SSRS) code under source control. It hit me that if you don’t have your code under source control, then it’s darned close to impossible to start getting any DevOps automated deploys going.
It’s easy enough to get your SQL Server schema under source control — open up Visual Studio, create a SQL Server Data Tools project, and then do a database import. Done. That’s about 2 minutes of work. Granted, this isn’t always perfect because you’ll probably need to do some cleanup of the inevitable dead code in your database schema but getting your code *at least* under version control is simple.
For SQL Server Reporting Services (SSRS) code, it’s a lot harder because there really isn’t a great tool. If you don’t already have your *.rdl files under version control, it’s going to be a manual process to save the RDL files one-by-one to disk and then check them in.
Well, in order to get your *.RDL files under version control quickly, I wrote a simple export utility. It’s got two commands: listfolders and exportreports.
The list folders command allows you to view the folders in your SSRS server so you can decide where you’d like to export your *.RDL from.
Here’s an example listfolders command that I ran against the SSRS in my Team Foundation Server:
ssrsutil listfolders /servername:demotfs2015 /fromfolder:/
Lets say that you want to export the *.rdl files for all the SSRS reports in the “scrum-tfvc-20150805” folder. Here’s a sample for the exportfolder command.
ssrsutil exportreports /servername:demotfs2015 /fromfolder:/TfsReports/DefaultCollection/scrum-tfvc-20150805 /tofolder:c:\temp\exportedrdl
And here’s what gets exported to that folder:
Both of these commands assume that you installed SQL Server Reporting Services in the default configuration and that the SSRS administration web service is located at http://servername/ReportServer/ReportService2010.aspx. Well, I realize that not everyone installs their SSRS this way. If you have a different value, both the listfolders and exportreports commands take an additional argument called /urlinstallbase.
To use this custom location, open the Reporting Services Configuration Manager and click the Web Service URL item in the left menu. Whatever the “Virtual Directory” value is is the value that you’ll pass using the /urlinstallbase parameter.
— DevOps got you down? Are your application deploys taking forever? Do you wish you could go from developer check-in to deployed application without so much pain? We can help. Drop us a line at firstname.lastname@example.org.