DevOps Wiki: How to enable download of attachment
Hello, I do have a git based wiki in ADO with the following structure: | ---- REAGME.md | ---- .attachments | ---- config.xml Within README.md I want to reference config.xml in a way that: 1. enforces the file to be downloaded and not opened 2. ensures a meaningful file name proposal for the download For "common" markdown this would be something like: ... [Config](./.attachments/config.xml?download=true&name=config.xml) ... unfortunately ADO performs some URL-encoding to this relative link and tries to find a file named: - ./attachments/config.xml%3Fdownload%3Dtrue%26name%3Dconfig.xml This file cannot be found (why should it, such a file does not exist) My questions are: 1. How to properly format the relative link in ADO markdown to make the attachment downloadable 2. How to properly format the relative link in ADO markdown to define the attachments name Exclusion: - The answer "Use an absolute link like https://..../" is not an option as no-one will ever be able to maintain this across multiple branches Thank you in advance 😉Integrating Azure DevOps with Jira Service Management: Real-World Use Cases
If your development team works in Azure DevOps while support operates in Jira Service Management (JSM), you're probably dealing with manual ticket updates, information silos, and delayed responses. This friction slows down ticket resolution and creates unnecessary back-and-forth between teams. You can integrate both systems to automate data exchange and keep everyone on the same page. In this post, we'll explore why this integration matters, common use cases I've seen from teams using both platforms, and the key features you should consider when setting up your integration. Why Integrate Azure DevOps with Jira Service Management? When you integrate Azure DevOps with JSM, ticket escalation becomes automatic. A critical bug reported in JSM creates a work item in Azure DevOps with complete context—error logs, customer details, priority level, and all relevant information. Status updates sync bidirectionally. Your support team sees development progress without switching tools. Developers get full customer context without leaving Azure DevOps. The real benefits: Eliminate copy-paste errors Real-time visibility into work status Faster incident resolution Clear audit trails for SLAs and post-mortems Each team stays productive in their preferred environment Without integration, support agents need to check Azure DevOps regularly for updates to relay to customers. This creates delays, introduces errors, and wastes time on both sides. Common Use Cases for Azure DevOps + JSM Integration I have worked with hundreds of teams integrating these platforms. Here are the most common scenarios: 1. Incident and Bug Escalation This is probably the most common use case. Critical bugs reported in JSM automatically create high-priority work items in Azure DevOps with error logs, affected user details, and complete customer context. As developers update the work item, adding comments, changing status, or resolving the bug, those changes flow back to JSM automatically. Support agents can keep customers informed without constantly asking the dev team for updates. Use Case: Current Setup: Support uses JSM for customer tickets. Development uses Azure DevOps for bug tracking. Problem: Manually updating both systems is time-consuming and error-prone. Solution: Two-way sync ensures bugs and updates flow automatically between both systems. 2. Feature Request Management When customers submit feature requests through JSM and they get approved, they automatically flow to Azure DevOps as backlog items with inline images, custom fields, attachments, and more. When development completes the feature, the original JSM request closes automatically and notifies the customer. Use Case: Current Setup: Product managers collect feature requests in JSM. Developers track work in Azure DevOps. Problem: Manually creating work items for approved requests takes time, and context gets lost. Solution: Approved JSM requests automatically create Azure DevOps work items with full context. 3. Multi-Platform Sync for MSPs A central JSM instance can route tickets to different Azure DevOps projects based on work item type. This works especially well for MSPs managing multiple clients. You can connect your JSM instance with multiple client Azure DevOps environments while keeping data completely isolated per client. Use Case: Current Setup: An MSP uses one JSM instance. Multiple clients use separate Azure DevOps environments. Problem: Routing tickets manually to the right client's Azure DevOps is inefficient. Solution: Conditional routing based on customer tags or custom fields automatically sends tickets to the correct Azure DevOps project. 4. Post-Merger System Integration When two companies merge, one might use JSM for service management while the other uses Azure DevOps for development and QA. Rather than forcing everyone onto a single platform immediately, you can connect both systems to let teams continue using their existing tools during the transition. Use Case: Current Setup: Merged company with different tool stacks. Problem: Forcing immediate migration disrupts workflows. Solution: Integration bridges the gap while you plan a longer-term consolidation strategy. Key Features to Consider When Choosing Your Integration Approach Bidirectional vs. Unidirectional Sync Bidirectional sync is essential when both teams need to update shared information like status, priority, and comments. Updates flow both ways automatically without sync conflicts. For some use cases, you might only need one-way sync. For example, JSM → Azure DevOps for escalations where only support creates tickets, but developers provide all updates. Selective Filtering You don't want to sync everything. Look for solutions that let you sync only tickets meeting specific criteria: priority levels, labels, custom fields, or status values. Example filters: Only sync JSM tickets with "escalate-to-dev" label Only sync Azure DevOps bugs tagged "customer-reported" Only sync high and highest priority items This keeps Azure DevOps boards focused on actionable work rather than cluttered with routine requests. Field Mapping Flexibility JSM and Azure DevOps use different field structures. Your integration needs to handle transformations between JSM's field structure and Azure DevOps work item fields without losing data. Common mappings: JSM Status → Azure DevOps State JSM Priority → Azure DevOps Priority Custom fields require explicit mapping rules Scalability The solution should handle your current ticket volume and grow with your organization. Look for reliable performance, error handling, retry mechanisms, and the ability to add more integrations as your needs expand. Security and Compliance Essential security features: Encryption in transit and at rest OAuth or Basic authentication ISO certification Role-based access controls For MSPs: Complete data isolation between client environments Audit logging for compliance requirements Conflict Resolution You need clear rules for what happens when both sides update the same field simultaneously. Common approaches include last-write-wins logic or timestamp-based priority. Technical Implementation Approaches Webhooks + REST APIs Azure DevOps Service Hooks, combined with JSM REST API, provide real-time bidirectional sync. This is the recommended approach for most teams. The flow works like this: Change happens in Azure DevOps Service Hook triggers webhook Integration middleware receives a webhook Middleware calls the JSM REST API to update the ticket The same flow works in reverse for JSM → Azure DevOps updates. Custom Middleware For complex requirements, custom middleware gives you maximum flexibility: Custom field transformation logic Complex routing rules Conditional synchronization Workflow orchestration Error handling and retry logic Common technology stacks include Azure Functions, Logic Apps, or custom Node.js/Python microservices. Third-Party Integration Platforms Many teams opt for dedicated integration platforms rather than building from scratch. These platforms offer pre-built connectors for both JSM and Azure DevOps, significantly reducing implementation time. What third-party platforms typically provide: Pre-configured connectors that understand both JSM and Azure DevOps data structures out of the box Visual or scripting interfaces for setting up field mappings, filters, and sync rules with or without writing code Managed infrastructure so you don't need to host and maintain your own integration servers Built-in error handling and retry logic that handles API failures automatically Audit logging and monitoring dashboards for tracking sync activity and troubleshooting issues Support for complex scenarios like multi-project routing, conditional logic, and custom field transformations Regular updates to keep pace with API changes in both platforms When to consider third-party platforms: You need to get integration running quickly without significant development effort Your team lacks in-house expertise in API integration You want managed infrastructure rather than maintaining your own servers You need support and documentation for troubleshooting You plan to integrate multiple tools beyond just JSM and Azure DevOps You require complex field mappings and conditional routing that would be time-consuming to build Trade-offs to consider: Recurring subscription costs vs. one-time development investment Less control over the exact implementation compared to custom solutions Dependency on the platform's feature set and release cycle Data flows through a third-party service (though reputable platforms offer strong security and compliance) Most platforms available in the Azure DevOps marketplace or Atlassian marketplace offer free trials, allowing you to test their capabilities before committing. Choose the right approach considering the above trade-offs and advantages I have discussed. Good luck! Let's discuss if you have anything specific in mind related to this post.
Azure Devops - Best way to create a burndown chart for an Epic
Hi, What is the best way to create a chart that would should the burndown (or burnup) of Story Points completed on User Stories under one or more Epics? I have never been able to do this within Azure DevOps itself. Have just picked up PowerBi and can't do it there either! Regards M
Help with Burnup / Burndown ?
I'm trying to build a burnup or burndown by feature. I know that's not a native feature in ADO right now, so I built it using tags. Even though most of the stories were written (and some completed) well in advance of May 17, I created the tag on the 17th, and it appears they're being plotted against the last changed date. Am I doing something wrong, or is this known behavior?The default azure-pipelines.yml is broken
Create a new project. Create an azure repo and clone it with ssh. Run go mod init and create a main.go file in the cloned repo. Commit and push the changes. Create a pipeline using your repo. An azure-pipelines.yml is created as shown below. Run the new pipeline. It gives the error below. My go.mod has go 1.19 and if I change the .yml to 1.19 it gives the same error with /usr/local/go1.19. How do I fix this, and where do I file a bug against the Pipeline default .yml file? 2022-11-01T03:06:15.6247802Z [command]/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/d62a4714-ede5-408d-9b1f-efbae06e65a3.sh 2022-11-01T03:06:15.6248305Z go: cannot find GOROOT directory: /usr/local/go1.11 2022-11-01T03:06:15.6248734Z go: cannot find GOROOT directory: /usr/local/go1.11 2022-11-01T03:06:15.6249112Z go: cannot find GOROOT directory: /usr/local/go1.11 2022-11-01T03:06:15.6282871Z ##[error]Bash exited with code '2'. Here is the .yml: # Go # Build your Go project. # Add steps that test, save build artifacts, deploy, and more: # https://docs.microsoft.com/azure/devops/pipelines/languages/go trigger: - master pool: vmImage: ubuntu-latest variables: GOBIN: '$(GOPATH)/bin' # Go binaries path GOROOT: '/usr/local/go1.11' # Go installation path GOPATH: '$(system.defaultWorkingDirectory)/gopath' # Go workspace path modulePath: '$(GOPATH)/src/github.com/$(build.repository.name)' # Path to the module's code steps: - script: | mkdir -p '$(GOBIN)' mkdir -p '$(GOPATH)/pkg' mkdir -p '$(modulePath)' shopt -s extglob shopt -s dotglob mv !(gopath) '$(modulePath)' echo '##vso[task.prependpath]$(GOBIN)' echo '##vso[task.prependpath]$(GOROOT)/bin' displayName: 'Set up the Go workspace' - script: | go version go get -v -t -d ./... if [ -f Gopkg.toml ]; then curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh dep ensure fi go build -v . workingDirectory: '$(modulePath)' displayName: 'Get dependencies, then build'CI/CD pipeline for microservice.
Hi All, We are new to Azure DevOps and start managing our project and planning to have CI/CD pipeline from our microservice. We are planning to have the below flow for each service: 1. Whenever the main branch is updated, run the Azure Pipeline (Build/Test/Review) 2. If Build succeeded, decide whether to deploy the changes on UAT by running the UAT Release pipeline manually. 3. Test on UAT. If everything works fine then ready to deploy on Production. 4. Create a release tag for the particular commit for which we created the build and tested it on UAT. 5. Run the Production Release pipeline manually to deploy the release on Production env. Is our flow correct? Please give us suggestions. We also have some questions: 1. Do we create branches for Releases or use tags? And when to create it, before deploying to UAT or after deploying on UAT? (Note: we are not sure whether we will deploy the changes to production immediately after deployment and testing on UAT, there may be a possibility that we will add some more features to the on UAT and then deploy on Production). 2. Should we create and push Docker Image in the Azure pipeline or Release pipeline? And how many image tags should we create? (say one with the release tag and one with the latest tag). Thanks Saurabhazure devops work item duplicates when inserting csv
I am moving from one ADO Board to another. So I have downloaded the CSV from the old board via queries and tried uploading. For all items which arent 'New' I have to manually edit which I have accepted will be a manual effort. The main problem is for every workitem which is 'new' and doesn't have an error duplicates itself. This is the same case for all 'new' work items. Sometimes it can be duplicated 8 times. How do I stop the duplicates
Trying to get list of commits using ADO API from specific tag ("Release ..."), not seeing the option
Trying to get list of all commits for a GIT repo in ADO from a specific tag (Release ...), not seeing the option in Management API https://learn.microsoft.com/en-us/rest/api/azure/devops/git/commits/get-commits?view=azure-devops-rest-7.0&tabs=HTTP
