Free Extension: Generate AI Development Prompts from Azure DevOps Work Items — Verity Framework
Hi Azure DevOps community, I wanted to share a free extension we just published to the Visual Studio Marketplace: the Verity Framework ADO Extension. **What it does** It adds a "Verity Prompt" tab to your work items. When you populate five custom fields on a User Story or Delivery Item, the extension generates a structured prompt ready to paste into Claude Code, Cursor, or GitHub Copilot Workspace. The five fields: - VF Intent — the problem and who experiences it - VF Value — the expected outcome - VF Appetite — time/resource ceiling (not an estimate) - VF Trust Criteria — Gate 2 hardening requirements - VF Failure Scope — Narrow / Moderate / Broad / Systemic **Why it matters** Most engineers using AI tools start from a blank context or a vague task description. The extension carries the team's planning judgment — including production risk level and hardening requirements — directly into the implementation context. It also includes field validation that flags vague Trust Criteria, incorrectly formatted Appetite values, and solution-framed Intent statements before generating the prompt. **Setup** About 20 minutes. You add five custom fields to your existing User Story work item type (no new work item type required). Full instructions are in the extension tab. **Install** Search "Verity Framework" on the Visual Studio Marketplace or visit idearoost.com/verity for the full framework context. Free. No subscription required. Happy to answer questions about the field definitions or the setup process. — Jacques Steward, IdeaRoost
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 😉
Is it possible to define and visualize new metrics (e.g. ratios) in dashboard widgets in Azure DevOp
I am creating some Azure DevOps Dashboard visuals. Some of the metrics I want to create do not seem to be included in the built in Azure DevOps widgets. As two particular examples: (i) I am using a Velocity widget. But instead of showing the sum of Story Points planned and completed, I just want to show the ratio completed/planned for each iteration (i.e a small change, that does not seem to be supported by the Configure Widget options)https://i.stack.imgur.com/0BHVL.png (ii) I want to show the ratio (Count of WorkItems with priority 1 or 2) / Count of all WorkItems The "Chart for Work Items" widget provides something close, allowing a visual of a chosen type (Bar, Pie etc) showing the Count or Sum of a field from a query, grouped by another field. But this doesnt allow for a ratio to be calculated. I cannot find any other widget type (built in, or within the Marketplace) that allows calculation of such ratios. I am sure that there is a way to define brand new widgets, to add to the marketplace, but that is more than I would want to undertake. Also I know that it is possible to pull data from DevOps into a tool like PowerBI, but I would prefer to stay in DevOps if possible. Is there something I am missing, where in DevOps it is possible to define/visualize new metrics like ratios?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?Exciting Announcements: New Data Connectors Released Using the Codeless Connector Framework
Microsoft Sentinel’s Codeless Connector Framework or ‘CCF’ (formerly called Codeless Connector Platform [CCP]) represents a paradigm shift in data ingestion, making it easier than ever for organisations to do more with Microsoft Sentinel by integrating diverse data sources seamlessly. Designed to simplify and expedite the onboarding of data sources, CCF eliminates the need for extensive coding expertise and maintaining additional services to facilitate ingestion, allowing security teams to focus on what truly matters – safeguarding their environment. Advantages of the Codeless Connector Framework The Codeless Connector Framework offers several compelling benefits: Ease of Use: CCF configuration-based templates allows advanced users to create data connectors without writing exhausting code, making the onboarding process quicker and more accessible to a broader audience. Flexibility: Users can customise data streams to meet their specific needs; optimizing efficacy while ensuring more control on the data being ingested. Scalability: The connectors built using CCF follows a true SaaS auto-expansion model making them highly scalable and natively reliable for large data volumes. Efficiency: By reducing the time and effort required to develop and deploy data connectors, CCF accelerates the availability of critical insights for security monitoring and more rapidly expands the value Microsoft Sentinel provides. What are we up to? We recognize that Codeless Connectors offer substantial advantages over Azure Function App based ingestion in Microsoft Sentinel in most cases. That motivates us to continue investing in modernizing our ingestion patterns for out-of-box connectors; one connector at a time. Another goal of modernizing these connectors is to replace the deprecated HTTP Data Collector API with the Log Ingestion API to send data to Microsoft Sentinel. Announcing the General Availability of New Data Connectors We are continually improving the Data Collection experience for our customers and are thrilled to announce that the following data connectors are now Generally Available (GA) on the Codeless Connector Framework. Atlassian Confluence Ingesting Confluence audit logs allows organizations to monitor collaboration activity, detect security risks, and troubleshoot configuration issues using Confluence audit records. Auth0 With the Auth0 Connector, organizations can effortlessly integrate authentication and authorization data from Auth0 into Microsoft Sentinel. This connector provides valuable insights into user activities and access patterns, bolstering identity security and compliance efforts. Azure DevOps Audit logs from Azure DevOps, allows security teams to monitor user activities, detect anomalous behavior, and investigate potential threats across DevOps environments. Box The Box Connector facilitates the ingestion of file storage and sharing data from Box into Microsoft Sentinel. By leveraging this connector, security teams can monitor file access and sharing activities, ensuring data integrity, and preventing unauthorized access. Google Cloud Platform Load Balancer With GCP Load Balancer and Web Application Firewall (Cloud Armor) logs, security teams can monitor inbound network activity, enforce security policies, and detect threats across GCP environments. Proofpoint POD The ingestion of email security logs allows organizations to monitor message traceability, detect threats, and investigate data exfiltration attempts by attackers and malicious insiders. Proofpoint TAP Email threat intelligence logs, including message and click events, provides visibility into malware and phishing activity to support custom alerts, dashboards, and threat investigation. SentinelOne The SentinelOne Connector enables seamless ingestion of threat intelligence and endpoint security data from SentinelOne into Microsoft Sentinel. This integration empowers security teams to enhance their threat detection capabilities and respond swiftly to potential threats. New Connectors in Public Preview CrowdStrike Falcon Data Replicator (S3 based Polling) Google Cloud Platform VPC Flow Google Cloud Platform DNS Google IAM These new additions are not new out-of-box sources in Microsoft Sentinel, but they do improve how data is collected. The previously Azure Function App based polling has now been upgraded to the Codeless Connector Framework for these products to ensure data collection adheres to the more scalable; advantageous pattern with CCF. As noted previously, the newer version of these connectors replaces the deprecated HTTP Data Collector API with the Log Ingestion API to send data to Microsoft Sentinel. Call to Action! Microsoft Sentinel customers collecting data from any of the mentioned sources using Azure Function Apps are advised to migrate their ingestion streams to newer versions to utilize the Codeless Connector Framework. While we continue to improve the data collection experience across all connectors, we encourage our customers and partners to join the Microsoft Security Communities to benefit from early insights about the latest and greatest with Microsoft Security. Call to Action for ISV Partners We invite our ISV partners to migrate their Azure Function App-based data connectors to the Codeless Connector Framework. By leveraging CCF for data ingestion, we can ensure that our mutual customers benefit from streamlined data integration and enhanced security monitoring in Microsoft Sentinel. We are committed to ensuring partners have all the support needed in this transformation. For any support, please reach out to us at Microsoft Sentinel Partners. Join us in this transformative journey to empower our customers by unlocking the full potential of their security investments with Microsoft Sentinel’s Codeless Connector Framework. References Create a codeless connector for Microsoft Sentinel Migrate from the HTTP Data Collector API to the Log Ingestion API to send data to Azure Monitor LogsThe 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'
