saadware

Introduction

A lot of the code that gets written for any software project can end up being for the supporting systems surrounding the end product. This can include build systems, tests, installers, deployment tools, etc. I’ve found that some of the greatest explorations in learning can be found by writing these systems. One gets to learn potentially new technologies and be a little more experiential with how they approach the problems. To me, some of my favorite projects have been for the supporting systems. One of those recent projects gave me the opportunity to dive a bit deeper into PowerShell.

History

This actually all started years ago when we wanted to find a good way to deploy SSRS reports during part of our one-click build and deploy system, powered by NAnt. We ended up writing a custom NAnt task which worked very well. It could take a source directory tree and pretty much replicate it to SSRS, all using the web service. It ended up being a very efficient, low impact way to deploy reports and resources. We were able to also use this little NAnt gem to deploy reports on a real customer install. Albeit we had to distribute a trimmed NAnt system in our deploy package. This worked for a while but we soon outgrew what the system could provide in a reasonable manner.

The biggest downside is that our NAnt task was pretty much an all or nothing deploy. There was no in between. Plus, being an XML build system, if we wanted to change any aspect of the deploy it required editing the NAnt project file. We therefore turned to PowerShell to help us accomplish this.

Solution

We’ve created (and are using internally) a full blown PowerShell Provider to help us accomplish this task:

In performing administrative tasks, the user may need to examine data stored in a data store (for example, the file system, the Windows Registry, or a certificate store). To make these operations easier, Windows PowerShell defines a module called a Windows PowerShell provider that can be used to access a specific data store, such as the Windows Registry. Each provider supports a set of related cmdlets to give the user a symmetrical view of the data in the store.

As you can see a provider fits the bill perfectly and the solution ends up being super dynamic as it currently allows for the following operations on SSRS:

• list items on a report server
• navigate the report server structure
• create/delete reports
• create/delete folders
• create/delete data sources
• create/delete resources

With this in place one can either script the deployment or wrap it up in a pretty GUI front-end by using a Runspace in your favorite .NET language.

Open Source

All of this has been placed on CodePlex under the SSRS PowerShell Provider (ssrsposh) project and is available for the all. It has served our immediate purpose and hopefully it will serve others. If not, my hope is for it to continue to evolve to meet those needs of others.

More to come in the future.