We have a setup so initially report is deployed to the draft folder of the server and then we manually move that report to its folder. The problem is that we have lots of subscriptions that needs to be recreated in the SSRS interface every time and thats annoying.
So is it possible to setup those subscriptions in Visual Studio so each deployed version of the report would have all subscriptions ready to go?
The project definition has event generator, which will trigger the batch file you difined, then each time you build new version the event will be triggered.
If you want to triggered the event after running some tasks of new build, you could write batch file to trigger the build and run the task.
Related
I'm wondering if there was a way in Team Services for a release definition to have a step that backs up the directory for the application before it deploys the updated code.
I currently do a manual process before we deploy an update of an application where I take the application directory and back it up to a compressed file with the name containing the date of the deployment in the file name, which we do to satisfy our requirements for backups to our Change Control Board. I would like to make this automated process so that it's done the same way each time, even if I'm not the one over the deployment. I know you can do command line tasks and I could write a command line application that takes certain parameters but would like to know if Team Services may already have a task in place that can take care of this.
There are a Copy Files and a Zip Files task which you can drop into your process. You can even make the tasks conditional. There isn't a "backup" task per-se.
However, there is no "rollback" task, the normal thing to do would be to schedule a new release with the previous version to install. Or to fix the issue and trigger a new release with the fixed contents.
I'm currently working on developing a custom workflow with many custom behaviors and scripts. I'm using the Alfresco Maven SDK to build and test my project as I develop it. This necessitates that I restart the repository-tier tomcat server every time I want to make a change/update my workflow files. I am getting quite frustrated with how long this takes each time, and it means that I'm wasting time while waiting for the server to restart, especially when I've made a small typo in one of my files.
I'm looking for a way (if it's possible) to update my files (in particular the bpmn process file) and apply these changes to my Alfresco instance without having to restart the tomcat servers each time. I've set to true in my service-context.xml, and I have also tried to redeploy the workflow from the admin-workflow-console, but my changes do not take place unless I manually restart the server.
I am using: Alfresco Community 5.2, Maven SDK 2.2
Any tips or suggestions would be very welcome!
Yes, you can do it by
workflow admin console
URL
http://<server>:<port>/alfresco/s/admin/admin-workflowconsole
Ex :: deploy alfresco/workflow/<workflow-definition>.xml
path for your workflow definition file.
Refer this docs for more information
https://community.alfresco.com/docs/DOC-5079-workflow-console
I have an application which is running on machine with production database,I need to do a quick test against test database, for this I need to create the second publish which will start the new installation instead of updating the production application.
I tried changing product name, but it just update the product name. Is there any setting available in publish, which forces the second publish to start a new installation instead of updating the old first one?
Creating copy of the project will solve the problem, but it would be nice to create the 2 different publish from the same project.
For now changing assembly name and product name does the trick. But I wonder if its possible to publish both production and test simultaneously with different app and publish settings!!
We are using TFS/VS 2010 to run Selenium tests which are scheduled in the TFS controller. After the build and tests are finished I would like to run the failed tests from that build.
Currently I am doing this by using a Windows Scheduled Task and executing a batch file which calls a powershell script which gets the latest build version (and failed tests) and then executes them (using mstest) and finally publishes the results back to build.
I just want this to happen without a windows scheduled task, it is too fickle. I believe I need to edit ProcessTemplate.xaml and add an event (InvokeProcess) to achieve this, I just can't find much on it.
Thanks in advance!
I currently have a CI environment setup using the following tools:
VCS - ClearCase (UCM enabled)
CI Server - Jenkins
Build Engine - MSBuild
Basically Jenkins is polling my UCM Project's Integration stream every 2 minutes and building via a msbuild script I wrote.
While in ClearCase it is not a best practice having a individual stream for each developer, good CI demands private builds to be run before commiting the code. Added to that, ideally i would have atomic commits, which ClearCase provides just on the form of Deliver to stream.
Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins.
My question is, how can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer? Am I missing something?
Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins
You can write your build script in order to detect if a deliver is in progress.
A deliver is characterized by an activity named deliver.xxx: you can list its content and see if any version in it is in checkout. If yes, the deliver is in progress.
If the most recent deliver has only checked-in versions, you can safely start your build.
Or:
How can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer
A private area for Jenkins to use would be a snapshot view on each developer stream.
As the name suggests, a snapshot view would take a snapshot of the code, but you need to define a criteria suggesting that Jenkins can build what the snapshot view has updated.
What I have seen used is a 'BUILD' shifting label (a label you re-apply on the newly updated code, and used by Jenkins in his snapshot view with a selection rule based on that label):
The developer move his/her label when he/she thinks the current code is ready to be build, and a Jenkins jobs update its snapshot view on the developer stream, based on the versions referenced by said shifting label 'BUILD'.