Azure DevOps integration

[mnelli19]

Hi, is integration with Azure DevOps Service also planned?

Thank you

[em-jones]

@mnelli19 I just want to chime-in with some anecdotal context.

I've run into enough tools that don't support Azure Devops without some sort of hacking that I think that this effort should be ADO's responsibility to start conforming to github/gitlab semantics instead of putting it on all these individual products.

Recent projects besides this one: Airbyte -> the absence of the .git suffix affects their dbt integration plural.sh -> their console source code building fails when not using gitlab/github

It would be nice if these projects included ADO in their scope, but, I just don't think it's worth it to these projects because of the small market share.

All this is to say: let's put more pressure on ADO instead of these projects.

[mnelli19]

Thanks for your answer, Could you kindly tell me what changes would be necessary to comply with the github/gitlab semantics so that I can possibly request them?

I know other tools that have also integrated Azure Devops (for example Pelorus) even if at a later time and for this reason I was asking if it was also on the roadmap for these.

Thank you Greetings

[em-jones]

off the bat, we know a couple things based on what these tools are dependent on:

• data sources/schemas
  • this project is able to map git VCS operational data from both gitlab and github APIs, so the underlying resources would, ideally be presented through the same HTTP/GraphQL schema
• authentication
  • the ssh git repo interface appears to be the same format across gitlab and github, but varies on ADO
  • last I checked, I don't think that ado supports ed25519 keys

I'm sure that there's more there, but where we'd like to see shared interfaces would be in the way we model the git specific schemas and authentication mechanisms. I think that's a reasonable ask. When we get into the Pipelines and PM interfaces, then things get more tricky. Pipelines shouldn't be that different between the products at the base level. Everything just a workload composed of a DAG of smaller workflows. There's no reason those need to be named differently. They're fundamentally doing the same thing. The same could be said for project management, except for how the same words often mean different things/different words mean the same thing across organizations. That, to me, would be the hardest variant to overcome in the process of standardization these schemas, because that is so tightly coupled to organizations(all of whom still think they have the right answer to PM).