I have been tasked to look into ways to automate the deployment process for our SSRS 2012 reports. Are there any good tools out there? I'm thinking of something along the lines of press a button and the report gets deployed.
Thanks!
To deploy our SSRS reports, we're using this lovely powershell project:
https://github.com/timabell/ssrs-powershell-deploy
Usage:
.\Deploy-SSRSProject.ps1 -path YourReportsProject.rptproj -configuration Release -verbose
or you can use the alternate parameter set:
.\Deploy-SSRSProject\Deploy-SSRSProject.ps1 -path .\AFS.Reports.rptproj -ServerUrl http://localhost/Reportserver -Folder MyReports -DataSourceFolder "MyReports/Data Sources" -DataSetFolder "MyReports/Datasets" -verbose
The full deployment story (for us):
ssrs-powershell-deploy scripts, .rptproj, .rds, .rdl files are all packaged into a nuget package by our build server.
Octopus Deploy extracts the nuget package on our SSRS server and calls Deploy-SSRSProject.ps1
Visual Studio Deployment
Visual Studio is actually really good at automatic deployment. I've used it a number of times with great results. You need to split your solution into separate projects for each folder on the report server and then it will take a bit of time to configure each project & deployment environment. But after that initial time investment it works wonders and when you add a new project you can simply copy the deployment settings for an existing project.
MSDN article: Set Deployment Properties (Reporting Services)
Rs.exe Utility
Alternatively you can use the Rs.exe utility which comes with SSRS. It is a command-line utility used for automatic deployment and administration. I haven't personally use this one, but I know of it. It is my understanding that there are also third party utilities which leverage Rs.exe in order to automate report deployment but I haven't used any of them so I can't recommend any.
More info on MSDN: RS.exe Utility (SSRS)
I'm sure there are also other third-party tools you could get but I haven't ever looked into them. I've always found the Visual Studio deployment functionality sufficient for my needs.
I have done it using devenv which is located in:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. The ... 10.0 folder is based on the version no. of your Visual Studio so I have only used this version so cannot vouch for anything else. If you view the help /? commandline switch you can see there are options to build and/or deploy a solution.
In brief I used: devenv {solutionfile} /Deploy {configuration} /Project {projectname}.
I did not use any deployment software but I did know how to code in C#.NET so pays to be familiar with System.IO and System.Xml name spaces.
Given the requirement deploy any file (so reports, datasets or datasources) that has been modified within the past 2 week sprint.
So basically my .net code worked as follows (NB: there are ares that you might have to consider first how well do you know how solution and project files work and if you have more than 1 platform - a platform for the uninitiated is a different set of project build and deployment settings):
Read the sln file line by line to get list of projects for the specific platform that are ready to be built/deployed, for simplicity my code assumed only one platform and all projects were to be deployed
The list from 1 gives me the subproject\subproject.rptproj settings in which I can break on the backslash to get the subfolder name from which I can iterate over all files in the project folder and check each file for the LastWritten datetime stamp of the file to determine what files that need to be deployed.
I back-up the entire file (declaration and contents)
If a file has not changed I edit the project file on the fly using xml and remove all unwanted files (ProjectItem's) not to be deployed
If there are dataset or datasource files changed then I also edit the respective configuration section of the project file and modify the particular configuration section accordingly
Run my build solution process i.e. devenv with commandline args (FYI: I did not encounter any .NET exceptions in this step)
Restore my project file
Providing your SSRS solution is configured correctly and the person running the .net commandline solution has permissions to deploy all should be well. Was easy enough to share my commandline solution source code to anyone else in my team to run to avoid having to white-list the exe if your company has employed such restrictions.
Related
I am using Azure Devops in my project which means my SSIS project is stored in a file location that looks like this: C:\Users\johan\source\repos\Data Warehouse\Scripts. We are using the Project Deployment model.
In Visual Studio configuration manager I would like to make the DEV configuration dependent on the user. So for André this would change into C:\Users\andre\source\repos\Data Warehouse\Scripts and for Kasper into C:\Users\kasper\source\repos\Data Warehouse\Scripts. This would allow developers to run a changed script directly from Visual Studio. I could also have a fixed folder with scripts somewhere, but in that case a developer must copy his changed script to this folder to make it work.
I know parameters can't be variable but is there any other way to make this location dependent on the current user? These scripts are for example Powershell scripts that are executed from a package.
I've been working with SSIS reading different files - from CSVs to XLSXs - with no problems. My paths are relative, so SSIS searches for the files from the project's folder.
Well, today my colleague tried to run a package and he got a curious error message saying that the file could not be found under the "C:\windows\system32" folder. There's no configuration that would point SSIS to that folder and with me and a third colleague it's working well.
After some investigation we discovered that the problem has nothing to do with the user itself, but with how the user opens the project. Since the beginning I've been opening the project by double clicking the ".dtproj" file. My colleague first opens the SSIS development interface then opens the project file from the menu.
Has anyone noticed that behavior? What could be the cause for that?
error message print
Microsoft Visual Studio 2008
Version 9.0.30729.4462 QFE
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: IDE Standard
This happens because the different ways of launching the IDE end up with different current directories for the IDE process. You can test this by creating a package with only a Script Task, with the one line:
MessageBox.Show(Environment.CurrentDirectory);
And then running this project after launching it both ways.
Double-clicking the project or solution file sets the folder containing that file as the current directory. (I assume this is standard Windows process launching behaviour when starting a process based on the file extension association.) SSIS packages then look in the current directory when the path to the configuration file is relative.
We use relative paths to configuration files all the time to simplify deployment, and have to always remember to open the solutions by double-clicking the SLN file.
I've been trying to follow the
Setting Up Stackdriver Debugger for Java applications on Google Compute Engine, but am running into issues with Stackdriver Debug.
I'm building my .war file from a separate build server, then deploying it to my GCE server. I added the agent to the start command via /etc/defaults, and my app appears in the https://console.cloud.google.com/debug control panel. The version I set in the run command matches the revision that shows up in the source-context(s).json files.
However when I click open the app, I see the message that
No source version information was provided by the deployed application
I connected the app's git repo as a mirrored cloud repository, and can browse the source files in the sidebar of the Stackdriver Debug page. But, If I browse to a file and add a breakpoint I get an error that the error "File was not found in the executable."
I have ran the gcloud preview app gen-repo-info-file command, which created two basic json files storing my git repo and revision. Is it supposed to do anything else?
I have tried running jetty using both normal and extracted modes. If I have jetty first extract the war file, I can see the source-context.json filesin the WEB-INF/classes directory.
What am I missing?
https://github.com/GoogleCloudPlatform/cloud-debug-java#extra-classpath mentions
you can update the agentPath showing your WEB-INF/class directory.
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes
For multiple class paths:
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes:/another/path/with/classes
There are a couple of things going on here.
First, it sounds like you are doing the correct thing with gen-repo-info-file. The debugger agent should pick up the json files from the WEB-INF/classes directory.
The debugger uses fuzzy matching to find source files, so as long as the name of the .java file matches a file in your executable, you should not get that error.
The most likely scenario given the information in your question is that you are attaching the debugger to a launcher process, rather than your actual application. Without further details, I can't absolutely confirm that, though.
If you send us more details at cdbg-feedback#google.com, we can look more closely at your case to see if we can understand exactly what's happening, and potentially improve our documentation, since it sounds like you followed the docs pretty closely.
I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).
So, I'm enjoying using composer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using deployhq, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.
My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.
When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).
So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?
Any answers would be greatly appreciated.
James
There will always be arguments as to the best way to do things such as this and there are different answers and different options - the trick is to find the one that works best for you.
Firstly
I would first take a step back and look at how you are managing your composer.json
I would recommend that all of your packages in composer.json be locked down to the exact version number of the item in Packagist. If you are using github repo's for any of the packages (or they are set to dev-master) then I would ensure that these packages are locked to a specific commit hash! It sounds like you are basically there with this as you say nothing updates out of the packages when you run it.
Why?
This is to ensure that when you run composer update on the server, these packages are taken from the cache if they exist and to ensure that you dont accidentally deploy untested code if one of the modules happens to get updated between you testing and your deployment.
Actual deployments
Possible Method 1
My opinion is slightly controversial in that when it comes to Composer for many of my projects that don't go through a CI system, I will commit the entire vendor directory to version control. This is quite simply to ensure that I have a completely deployable branch at any stage, it also makes deployments incredibly quick and easy (git pull).
There will already be people saying that this is unnecessary and that locking down the version numbers will be enough to ensure any remote system failures will be handled, it clogs up the VCS tree etc etc - I won't go into these now, there are arguments for and against (a lot of it opinion based), but as you mentioned it in your question I thought I would let you know that it has served me well on a lot of projects in the past and it is a viable option.
Possible Method 2
By using symlinks on your server to your document root you can ensure that the build completes before you switch over the symlink to the new directory once you have confirmed the build completed.
This is the least resistance path towards a safe deployment for a basic code set using composer update on the server. I actually use this method in conjunction with most of my deployments (including the ones above and below).
Possible Method 3
Composer can use "artifacts" rather than a remote server, this will mean that you will basically be creating a "repository folder" of your vendor files, this is an alternative to adding the entire vendor folder into your VCS - but it also protects you against Github / Packagist outages / files being removed and various other potential issues. The files are retrieved from the artifacts folder and installed directly from the zip file rather than being retrieved from a server - this folder can be stored remotely - think of it as a poor mans private packagist (another option btw).
IMO - The best method overall
Set up a CI system (like Jenkins), create some tests for your application and have them respond to push webhooks on your VCS so it builds each time something is pushed. In this build you will set up the system to:
run tests on your application (If they exist)
run composer update
generate an artifact of these files (if the above items succeed)
Jenkins can also do an actual deployment for you if you wish (and the build process doesn't fail), it can:
push the artifact to the server via SSH
deploy the artifact using a script
But if you already have a deployment system in place, having a tested artifact to be deployed will probably be one of its deployment scenarios.
Hope this helps :)