Short disclaimer: I'm not an Azure DevOps admin, just a technical person who created a few work-items and configured a couple of processes in Azure Dev Ops.
As for Versions being related to Iterations - that's for sure, however it's not a 1-on-1 match: Jira also has Sprints, which also map onto iterations, as they seem to be very close to a time-scoped sort of thing. Overall, however, milestones could be modeled through iterations.
As for Components, the Area path does seem very interesting in the sense that it is designed to group work to sub-teams. However, components in Jira might not be necessarily tied to a set of people, but could rather be used for Tracing Impact of a certain issue. While Jira Portfolio's Team field might be a better fit to describe the people responsible for current issue.
For both Versions <> Iteration and Components <> Area, there's same sort of situation, where Jira has a multi-value field, while Azure DevOps demands to pick only one. Which could be solved by creating multiple issues per each version. All of these work items could be linked in sync to the same Jira Issue.
For context:
Short disclaimer: I'm not an Azure DevOps admin, just a technical person who created a few work-items and configured a couple of processes in Azure Dev Ops.
As for Versions being related to Iterations - that's for sure, however it's not a 1-on-1 match:
Jira also has Sprints, which also map onto iterations, as they seem to be very close to a time-scoped sort of thing.
Overall, however, milestones could be modeled through iterations.
As for Components, the Area path does seem very interesting in the sense that it is designed to group work to sub-teams. However, components in Jira might not be necessarily tied to a set of people, but could rather be used for Tracing Impact of a certain issue. While Jira Portfolio's Team field might be a better fit to describe the people responsible for current issue.
For both Versions <> Iteration and Components <> Area, there's same sort of situation, where Jira has a multi-value field, while Azure DevOps demands to pick only one. Which could be solved by creating multiple issues per each version. All of these work items could be linked in sync to the same Jira Issue.
I'd also found this article on modeling the release cycle: https://www.reddit.com/r/azuredevops/comments/qa3d4j/suggestions_on_how_to_model_a_release_or/
Where people suggest to have work item types for Epics, Releases and such, and then use relations (Azure's issue links to relate them).
I'll start coding on the Versions <> Iteration, Components <> Area and show some results on Mon Mar 14th