we are going to use TFS (Azure Devops) and ConnectWise Manage at the same time.
In short, we need to provide synchronization between those two systems when working with a working item / a ticket correspondingly, i.e. we can insert the reference to TFS working item into ConnectWise ticket - then corresponding TFS working item will be updated with ConnectWise ticket reference and vice versa. Also, some fields are to be re-used in both systems and updated.
I've started to look for the information, but seems cannot find anything basic - where to start from and how to implement this (how it will look like - some intermediate listener listening for both servers and updating items here and there or... ? What language to be used - is it some of .NET language using some specific framework? Or just some PowerShell scripts? What authentication is to be used? What settings do I need to ask our organisation to make in their Azure Devops / ConnectWise account? etc.)
Could you please point me in right direction?
I found a way to integrate Azure devops with ConnectWise Manage. You can try connect your Azure DevOps and ConnectWise Manage via Zapier. It's easy to connect Azure DevOps + ConnectWise Manage and requires absolutely zero coding experience.
You can synchronize between the two services by selecting a trigger and then selecting an action.
Related
I have been researching on how i can create/update a work item in Azure DevOps from logic apps using Azure DevOps rest apis? We need this for an integration with another CRM tool. Please reply if this can be done and how?
Thanks,
Gopal
You can either use this REST API in order to create work item. You will have to maintain PAT:
https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.0&tabs=HTTP
Update work item:
https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/update?view=azure-devops-rest-7.0&tabs=HTTP
Or - what I would recommend - you can use Azure DevOps connector (for Logic App it is part of Standard Class):
https://learn.microsoft.com/en-us/connectors/visualstudioteamservices/
Create Work item task anchor:
https://learn.microsoft.com/en-us/connectors/visualstudioteamservices/#create-a-work-item
Update work item task anchor:
https://learn.microsoft.com/en-us/connectors/visualstudioteamservices/#update-a-work-item
Simple guide how to set up such task in Logic App:
https://codegumbo.com/index.php/2021/05/27/using-an-azure-logic-app-to-create-azuredevops-work-items-from-a-sql-server-dataset/
After reproducing from my end, I have received the same error.
You are receiving this because as soon as you try to hit the endpoint it asks for login which requires token and hence you are getting redirected. One of the workarounds to make this work is to provide required scope as mentioned in this official documentation.
One of the ways that worked for me is to use the DevOps Connector directly from logic apps. Below is the flow of my logic app.
We are using Azure Devops Server 2020 and have a project using the XML process model. The project belongs to an old collection which do not support the Inheritance model. When reading the article below I get the feeling it's possible to upgrade to use the Inheritance model. But my options in the administration UI are not the same as in the article. I guess it's because the collection itself does not support the inheritance model. Therefore I have created a new collection which supports the Inheritance model and wonder if there is a way to move my project to the new collection? Or is there any other way to upgrade my project to use the Inheritance model? The UI for the new collection does by the way look like the UI in the article.
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/upgrade-hosted-to-inherited?view=azure-devops
I am afraid that this feature: Clone a Hosted XML process to an Inheritance process cannot be implemented in azure devops server.
According to the doc, this feature only exists in the Azure Devops Service. When you select azure devops server 2020 in the drop-down box in the upper left corner, you can directly see that it is not supported.
Here is a suggestion ticket about this feature. Our product group has decided not to implement this feature on azure devops server.
For those customers who wish to go to Inherited, you have the
following choices.
Move to the Azure DevOps Service
Create a new inherited collection and continue your project work
within that collection
On the other hand, you cannot directly move the team project to Inheritance Process Collection.
Azure Devops also does not support the movement of team projects between collections.
Here is a suggestion ticket about this feature: make it possible to move a Team Project between Team Project Collections
So if you want to create a new inherited collection and continue your project work within that collection, you could try to use the third party tools to migrate content of the project to new collection. For example:
Migration Tools for Azure DevOps
WIMigrator
This can get complicated. But you could refer to this ticket:
Currently there is no way to convert from XML to inherited on Azure DevOps Server (on-prem). Or next step is going to be able to allow mixed mode collections. Then figure out the right migration path from XML to Inherited. We are expecting to have mixed mode available some time on the Azure DevOps Server 2020 release. Probably update 1 or 2.
It seems that the mixed mode process can meet your needs. But this function has not yet been implemented，you may still need to wait for the implementation of this feature.
I use Azure DevOps to track work items and bugs for a project. I'd like to grant certain people external to the project a read-only view of work items that are related to them (eg. tagged Person X), but without having to grant them access to DevOps. I have been toying with the idea of setting up a flow in Power Apps to continuously update a shared excel spreadsheet based on work items in DevOps, but I fear I might be missing easier/better options. How would you provide a limited read-only view of a backlog to externals?
I'd like to grant certain people external to the project a read-only
view of work items that are related to them (eg. tagged Person X), but
without having to grant them access to DevOps.
For this issue , I am afraid that this is unachievable in azure devops. At present, there is no such permission setting in azure devops to restrict external people can only read work items with specified tag.
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. Thank you for helping us build a better Azure DevOps.
I have a question about Microsoft DevOps (formerly Visual Studio Team Services or VSTS). I have multiple applications that are set up as separate projects, but we have basically one team of devs. Some of the older projects are TFS based some are git.
Ideally I would like to create a board based on the team and 'attach' projects to the board. Or something that ends up being roughly the equivalent of this.
I can't seem to find anything close to this. Does anyone have any ideas? Or any suggestions?
Thanks for your help!
As I mentioned in my comment you can use the AzureDevOps Rest API.
Representational State Transfer (REST) APIs are service endpoints that
support sets of HTTP operations (methods), which provide create,
retrieve, update, or delete access to the service's resources
Most REST APIs are accessible through our client
libraries,
which can be used to greatly simplify your client code.
Once you created your own board, you can fill up the details using the REST API response.
I would like to move the backlog items and any related linked items to another tenant, any ideas?
There's nothing built in that does this.
You'll either have to write your own solution or look into one of the various migration or integration tools that are available on the market. None of them provide full fidelity migration, however.
As Daniel said that there isn’t built-in tool.
You can build an application with REST API to create the new workitems per to the workitems in another VSTS. Regarding Work Item creating REST API, there is bypass rules that can remain System.CreatedDate and System.CreatedBy value: Make an update bypassing rules.
On the other hand, there is 3rd tool: OpsHub Visual Studio Online Migration Utility