I'm looking at a possible script to automated the rpd deployment from one environment to another (dev,test,prod). Has anyone ever worked on such a script on a Windows based platform. There is a runbat.cmd in OBIEE, however there are no instructions on how to build the script.
Any suggestions would be greatly appreciated.
Thanks
Yes, you can automate rpd deployments using wlst scripting language: to connect to weblogic, lock configuration, upload the new RPD, save changes and perform a system restart.
However you'll probably have to perform some aditional tasks to the RPD before uploading it, tipically, changing the connection information, because it will be different between enviroments. For that you'll need to automatically patch the RPD with the correct connection information, using XUDML files.
Here are two blogpost with examples on how to do this, you can adapt the scripts to your own needs:
http://www.askjohnobiee.com/2013/03/how-to-automatic-repository-deployment.html
http://adventuresinobiee.blogspot.co.uk/2013/02/scripted-rpd-deployments-using-udml-and.html
Regards
Ana GH
Related
We are trying to establish a continuous deployment environment. Conflicted how to do ARM deployments. Deploying all the resources as a group is much better them handling them individually.
ARM has a nice declarative syntax. We are telling what we intend to create" without having to write the sequence of programming commands to create it. Which is great but how should we run them ?
Two options come up to my mind
I.I could download the templates and use power shell.
II. Trigger using Azure automation
III. x
What is the best practice ?
Reference
Octopus integration from source code
If you're doing this as part of your CI/CD chain, you probably want to check in the templates and deployment scripts with your source code. That way, the definition of the infrastructure is kept with the code that's intended to run on it.
If this is part of some other workflow, it really depends on the workflow :)
I would suggest using powershell\cli and just invoke the template from the uri, that is the easiest way of doing that (instead of downloading it). This can be run with anything that is capable of running a custom script task, or specific CI\CD systems that have steps to deploy ARM Template (VSTS\Octopus\probably something else)
I would advice against Azure Automation for that cause.
Also, I do suggest separate code from arm templates
we are currently using a powershell script (~800 lines of code) to deploy an asp.net website, setting up the databases and modifying some xml nodes / text files. Can we use the wix toolset to do that? I am not very familiar with it. Or is it possible to copy our installation folder to the target system and executing the powershell file on it, using the wix toolset?
Yes, WIX can handle this.
You can start with this tutorial that includes enabling feature in IIS, installing website and change config files.
Just had a similar question / problem. My problem was that I couldn't get a powershell script working. I wrote a guide over here that migth help you. Feel free to ask if you need further assistance! :)
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
We currently use Ant to automate our deployment process. One of the tasks that requires carrying out when setting up a new Service is to implement monitoring for it.
This involves adding the service in one of the hosts in the Nagios configuration directory.
Has anyone attempted to implement such a thing where it is all automated? It seems that the Nagios configuration is laid out where the files are split up so that they are host based, opposed to application based.
For example:
localhost.cfg
This may cause an issue with implementing an automated solution as when I'm setting up the monitoring as I'm deploying the application to the environment (i.e - host). It's like a jigsaw puzzle where two pieces don't quite fit together. Any suggestions?
Ok, you can say that really you may only need to carry out the setting up of the monitor only once but I want the developers to have the power to update the checking script when the testing criteria changes without too much involvement from Operations.
Anyone have any comments on this?
Kind Regards,
Steve
The splitting of Nagios configuration files is optional, you can have it all in one file if you want to or split it up into several files as you see fit. The cfg_dir configuration statement can be used to have Nagios pick up any .cfg files found.
When configuration files have changed, you'll have to reload the configuration in Nagios. This can be done via the external commands pipe.
Nagios provides a configuration validation tool, so that you can verify that your new configuration is ok before loading it into the live environment.
I'm looking to automate the deployment of XMLA scripts. I've come across an article that gives a small demo, but I'm hoping to find more info.
Specifically, where is the documentation for Microsoft.AnalysisServices.Xmla.XmlaClient and what is the best approach for overridding the database and connection values that are embedded in the XMLA script?
I assume you are just trying to deploy the analysis service cube. This utility has commandline switches and can suport configuration for different targets
Analysis Services Deployment Wizard
If you need to add further customizations, you can always process the resulting xml files with either xslt, powershell, or .net
ascmd.exe can also run xmla scripts:
ascmd.exe commandlline utility
Apparently Microsoft.AnalysisServices.Xmla.XmlaClient is an undocumented library that is actually part of Management Studio and is not re-distributable. I think that using one of Jason's suggestions or the AMO library are your only approaches.