Forum Widgets
Latest Discussions
Branch is not created by az repos ref create command
I want to automate branch creation for my project. I am using the command az repos ref create --name testrelease/$MAJ_VER.$MIN_VER.$PATCH_VER --object-id xxxxxxxxxxxxxxxxxxxxxxxx --org https://dev.azure.com/myorg/ --project myproj--repository myrepo I see the response, 2023-11-30T16:00:57.5538690Z { 2023-11-30T16:00:57.5539015Z "customMessage": null, 2023-11-30T16:00:57.5539286Z "isLocked": false, 2023-11-30T16:00:57.5539489Z "name": "refs/testrelease/0.3.0", 2023-11-30T16:00:57.5539871Z "newObjectId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", 2023-11-30T16:00:57.5540718Z "oldObjectId": "0000000000000000000000000000000000000000", 2023-11-30T16:00:57.5541098Z "rejectedBy": null, 2023-11-30T16:00:57.5541701Z "repositoryId": "123212312321321312312312312321312312321", 2023-11-30T16:00:57.5542107Z "success": true, 2023-11-30T16:00:57.5542284Z "updateStatus": "succeeded" 2023-11-30T16:00:57.5545083Z } 2023-11-30T16:00:57.6145902Z ##[section]Finishing: create a branch But I couldnt find the branch created in azure devops.
Ownership of an Azure DevOps organisation
I and my colleagues have had Visual Studio Enterprise subscriptions for many years now (since they were MSDN Universal), through the company we work for. Some time ago I set up an Azure DevOps organisation under my account, and it is now used for all our repositories, pipelines, etc. I'm getting to the age were retirement is an option, and I'm concerned about the organisation being tied to my VSEnt subscription rather than our company's Azure account. I've been doing a bit of research on it, and the advice talks about creating a tenant and connecting the organisation to its Entra directory. My organisation is already connected to our Entra directory though, and we've always been able to add users from our AD. Would this have been done automatically because the account linked to VSEnt was part of our AD? More importantly, does this mean the organisation would survive the expiry of my VSEnt subscription? I'm currently the owner of the organisation, but changing that seems fairly straightforward. With that change and presence of the Entra link, does that mean I've nothing to worry about, or is there more to do?
Jira Service Management and Azure DevOps Integration: Optimize ITSM and Development Workflows
This article dives into how integrating Jira Service Management (JSM) with Azure DevOps can improve ITSM and development workflows. Let’s face it, businesses can no longer ignore the friction that comes from siloed support and dev teams. Integration, when done right, brings real-time updates, better visibility, and a smoother customer experience. For such integrations, you need tools that help you connect these multiple platforms together. Integration isn’t about one side changing its behavior to meet the needs of the other. It’s about combining strengths, working together, and reducing waste of time and resources on both sides. Exalate connects teams within and across companies by providing a scalable, reliable, and AI-assisted integration solution, eliminating the need to switch between multiple ITSM systems. How does Exalate work? Exalate works as a dedicated app on each system you want to integrate. Each tool admin stays in control. You decide what goes out and what comes in. Exalate is a script-based integration solution. It’s Groovy-based scripting engine allows the flexibility to implement deep integration between Jira and Azure DevOps. Got an edge case that doesn’t quite fit in the standard mold? Bring it on. It’s also available for other systems like Salesforce, ServiceNow, Freshdesk, Zendesk, and more. To make scripting faster (and more approachable), it also provides AI Assist. You describe your sync logic in plain language, and it turns it into dynamic sync rules, right inside the Exalate admin console. Replica and Triggers Exalate allows you to define sync rules that hold what data gets shared and how it maps across systems. Sync rules have a replica. A replica is a copy of an issue/work item that holds the data you want to share. Each integrating side has incoming and outgoing sync rules. In Jira, the outgoing sync will define what information should be transferred to Azure DevOps, and the incoming sync will decide how you map the information coming from Azure DevOps. Triggers kick off syncs automatically, based on conditions written in native query languages like JQL (Jira Query Language) or WIQL (Work Item Query Language). Some common use cases that you can implement. First Use Case: Support Escalation to Dev When a customer raises a ticket in JSM, some of those need to be escalated to the dev team in Azure DevOps, either as Bugs or Features. Map request types from JSM to work item types in Azure DevOps e.g., ‘Report a bug’ → Bug | ‘Suggest a feature’ → Feature Sync status and priority between both platforms. This ensures both teams stay aligned as tickets progress Triggers Used When the project name is SUPP and the request type is a bug or feature, send the ticket over to Azure DevOps. Second Use Case: Product Support Flow The product team creates epics and user stories in Azure DevOps. These entities on the project board are unidirectionally synced to Jira Cloud as epics and stories. The relation hierarchy between Azure DevOps and Jira is maintained. For instance, ‘Relations’ in Azure DevOps are mapped as ‘Issue links’ in Jira. Statuses are synced between Jira Cloud and Azure DevOps to reflect accurate progress. Integrate Azure DevOps and Jira: Get Started Integrating Jira and Azure DevOps is not only a tech decision, it’s a business strategy. With Exalate, you can tailor the integration to your workflow, your logic, and your comfort level. Got a unique use case? Think Exalate might be the answer to your scattered support processes and manual ticket escalations? Drop a comment below, or if you’d rather chat one-on-one, book a call with us. Let’s make your integration work for you, not the other way around.
Get content from text file and save it into a variable - Azure YML
I have a txt file and I'm trying to save all the content in a variable but I'm only getting the first line of the content into the variable greetings.txt - hello: 123 - hello: 456 - hello: 789 azure-pipeline.yml variables: - name: MY_TEXT_FILE value: 'greetings.txt' readonly: true # Save text file content in this variable - name: GREETINGS_CONTENT value: '' steps: - task: Bash@3 displayName: 'Save text file content in a variable' inputs: targetType: 'inline' script: | echo "##vso[task.setvariable variable=GREETINGS_CONTENT]$(cat $MY_TEXT_FILE)" - task: Bash@3 displayName: 'Another task' inputs: targetType: inline script: | # This is only printing the first line of the txt file # I want to save ALL the txt file content in the variable echo "My greetings are: $GREETINGS_CONTENT" Results after 'Another task' is executed: Actual results: - hello: 123 Expected results: - hello: 123 - hello: 456 - hello: 789 What I need to update so I can get the expected results?
🚀 Azure Control, Data, & MGMT Planes: The Backbone of Cloud Efficiency 🌐
Azure operations can be divided into Three categories (Control Plane - Data Plane - Management Plane) This post describes the differences between those three types of operations. Tip : Suppose that the word "plane" means "function" understand this definition like this !! # Control Plane (Function) # @ The Control Plane is responsible for managing and configuring Azure resources. @ It handles administrative tasks such as creating, updating, and deleting resources. @ All requests for control plane operations are sent to the Azure Resource Manager URL For Azure global, the URL is " https://management.azure.comm. " @ Azure Resource Manager handles all control plane requests. It automatically applies the Azure features you implemented to manage your resources, such as: Azure role-based access control (Azure RBAC) - Azure Policy - Management Locks - Activity Logs @ After Azure Resource Manager authenticates the request, it sends the request to the resource provider, which completes the operation. @ The control plane includes two scenarios for handling requests - "green field" and "brown field". @ Green field refers to ---> new resources. Brown field refers to ---> existing resources. # Data Plane (Function) # @ The Data Plane is responsible for interacting with the actual data within Azure resources. @ Once a resource is created, operations like reading, writing, and processing data occur in the Data Plane. @ Requests for data plane operations are sent to an endpoint that's specific to your instance. Ex : "myaccount.blob.core.windows.nett " ---> for storage account @ Operates independently of the Control Plane, meaning even if the Control Plane is unavailable, the Data Plane remains accessible. # Management Plane (Function) # @ The Management Plane oversees monitoring, security, and configuration of Azure services. @ It ensures that resources are operating efficiently and securely. Ex : Azure Monitor: Collecting logs and metrics from resources Ex : Azure Security Center: Managing security policies and compliance. Ex : Azure Automation: Running scheduled tasks for resource management.
Continous deployment to Azure container registry is very very slow
How have other people solved this problem? We have a solution with 10 or so projects, each which publishes a container to our Azure container registry It takes around 15 minutes to build and publish each project, most of the time is spent pulling container images and uploading them to Azure container registry This is awful, and a real step backwards from our previous process.
