I want my Frends process to have Schedule triggers with several schedules. For example, each Wednesday at 07:00 and each Monday on 12:30. Can I add both?
Yes you can, just add multiple different Schedule triggers. It is strange that documentation doesn't mention that.
Full disclosure: I work in a team that made FRENDS.
Related
I'm trying to implement automatic backfills in Argo workflows, and one of the last pieces of the puzzle I'm missing is how to access the lastScheduledTime field from my workflow template.
I see that it's part of the template, and I see it getting updated each time a workflow is scheduled, but I can't find a way to access it from my template to calculate how many executions I might have missed since the last time the scheduler was online.
Is this possible? Or maybe, is this the best way to implement this functionality on Argo?
In azure devop, we can see the project stats, for example this one. But it is only showing upto 30 days activities.
I am wondering if there is a way (maybe some API call) to show activities over a whole year? We area trying to do a end of year report for big boss and would be nice to show how many deployments we done,how many PR were completed etc over the whole year.
By checking the API that it called behind the scenes, you should have something like
https://ORG.visualstudio.com/GUI/_apis/build/Metrics/Daily?minMetricsTime=2021-11-05T13%3A08%3A08.556Z
You can manipulate this value on browser and change the date to an older one for example (2020-12-16)
As I am not working with an Azure Devops repos for long time I cannot test the behavior, but it maybe work.
I would like to set a more precise time for starting the sprint in DevOps, currently it allows only dates to be configured.
Is there a way to set a certain start time hour/minutes for a sprint?
For this issue , as Daniel mentioned in the comment, currently azure devops does not support setting the time accurate to the hour/minute for the spirit.
You could add your request for this feature on our UserVoice site , which is our main forum for product suggestions. After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
Simple answer. Don't move your US across sprints. If you have created tasks for the US or work has started on any tasks in the US from previous sprints, then leave the US in the previous sprint and move the tasks over.
That way you can track which stories are incomplete at the end of each sprint and understand your actual velocity more easily.
The danger of moving unfinished work over is that you may have 90% finished a large story and give yourself a false image of success in your current sprint, affecting future estimations.
In Azure DevOps you can schedule a release as many times as possible. In my example, I want to create a release 3 times a day Monday - Friday
But, if I need to actually deploy those releases 3 times a day Monday - Friday, I can't. There is only one slot available and user can't add more.
Is this a limitation of Azure DevOps and how I can actually deploy my release (not create them) 3 times a day?
This is not available at present.
Not sure if totally got your point, what you are looking for is something similar to schedule redeploy.
When you submit a pre-deployment approval for a stage, you can defer the deployment until a specified time. You could not select or specify multiple times here.
You could submit a feature request in Develop Community: https://developercommunity.visualstudio.com/spaces/21/index.html
As Patrick pointed out, this currently isn't possible. You can set multiple schedules for a release but individual stages can't be scheduled more than once. As a workaround, you could clone the stage and then set different schedules for it.
I’m about to write a workflow in CRM that calls itself every day. This is a recursive workflow.
It will run on half a million entities each day and deactive the record if it was not been upodated in the past 3 days.
I’m worried about performance has anyone else done this.
I haven't personally implemented anything like this, but that's 500,000 records that are floating around in the DB that the async service has to keep track of, which is going to tax your hardware. In addition, CRM keeps track of recursive workflow instances. I don't have the exact specs in front of me, but if a workflow calls itself a set number of times within a certain timeframe, CRM will kill the workflow.
Could you just write a console app that asks the Crm Service for records that haven't been updated in three days, and then deactivate them? Run it as a scheduled task once a day, and then your CRM system doesn't have the burden of keeping track of all those running workflow instances.
EDIT: Ah, I see now you might have been thinking of one workflow that runs on all the records as opposed to workflows running on each record. benjynito's advice makes sense if you go this route, although I still think a scheduled task would be more appropriate than using workflow.
You'll want to make sure your workflow is running in non-peak hours. Assuming you have an on-premise installation you should be able to get away with that. If you're using a hosted instance, you might be worried about one organization running the workflow while another organization is using the system. Use the timeout and maybe a custom workflow activity, if necessary, to force the start time to a certain period.
I'm assuming you'll be as efficient as possible in figuring out which records to deactivate. (i.e. Query Expression would only bring back the records you'll be deactivating).
The built-in infinite loop-protection offered by CRM shouldn't kill your workflow instances. It stops after a call depth of 8, but it resets to 1 if no calls are made for an hour. So the fact that you're doing this once a day should make you OK on the recursive workflow front.