Seeking the thrill of transformative tech? Explore the art of designing and implementing DevOps solutions on Azure. Master the shift towards CI/CD, testing, and delivery, while preparing for the Designing and Implementing Microsoft DevOps Solutions exam!
Prepare and test your skills
Prepare and test your skills
GitHub Flow is a lightweight workflow for managing code changes using branches. Developers start from a stable main branch and create feature branches for new work. To protect the main branch, teams set up branch protection rules in GitHub, which can require changes to be approved via a pull request before merging. This workflow connects with Azure Pipelines to automate building, testing, and deploying code, ensuring only validated changes progress.
When a developer pushes code to a feature branch, it automatically triggers a CI pipeline in Azure DevOps. This pipeline builds the code and runs tests to ensure the changes work and don't break existing functionality. Teams can add extra checks, like security scans, to the pipeline. This provides fast feedback to developers about the health of their code before it is merged.
A process flow diagram showing a feature branch triggering a CI pipeline in Azure DevOps, followed by a pull request review, and a CD release pipeline deploying through staging gates to production.
After code passes CI tests, it moves into the continuous delivery stage. CD pipelines in Azure DevOps automate deployments to environments like staging for further testing. Teams set up release pipelines to promote code through these stages. Deployment gates, such as an Azure Policy compliance check, can be added to ensure a deployment only proceeds if it meets all organizational requirements, adding safety before production.
It is important to track why changes were made. Teams link GitHub commits and pull requests to work items (like bugs or user stories) in Azure DevOps. This creates a clear history showing who made a change, when, and which project requirement it fulfills. This traceability is crucial for auditing, understanding impact, and rolling back if necessary.
The pull request is the central tool for collaboration. It provides a space for team discussion, code review, and approval before merging. Teams can also configure notifications in Azure DevOps to alert them about build and deployment statuses. This keeps everyone informed and enables quick action if a pipeline fails, ensuring the entire development and release process runs smoothly.
Clear communication during software delivery requires a structured flow of feedback. By customizing notifications and automating alerts, teams can identify and address problems without manual tracking. The goal is to connect development actions directly to the communication tools and project boards developers use daily.
To keep stakeholders informed without overwhelming them, configure Azure DevOps notification subscriptions. These route targeted alerts about pull requests, build outcomes, and deployments to the responsible team members. Clear routing rules reduce resolution times because the right person is notified immediately when an event occurs.
Service hooks drive automated actions by binding Azure DevOps events to external systems. When an event triggersâlike a failed buildâthe service hook sends an automated payload to tools like Azure Boards or Slack. This integration removes manual steps from the triage process and ensures system states are synchronized across all development environments.
GitHub issue templates standardize how users report bugs and request features by requiring specific details. When a user opens a new issue, the template prompts them for pre-defined information like steps to reproduce and expected results. This consistent data collection allows triage teams to quickly categorize, prioritize, and assign work.
Teams can automate the creation of issues directly from build and deployment failures. When an automated testing pipeline detects an error, it triggers a workflow that automatically opens a new GitHub issue or Azure Boards work item. This ensures bugs are captured in a failed state before they reach production, letting developers focus on fixing defects.
To link GitHub and Azure Boards, you first establish a service connection authenticated using a personal access token (PAT). This token acts as the credential that allows the two platforms to trust each other and exchange data. The connection is configured in Azure and then tested to ensure it works.
Once connected, GitHub activitiesâlike issues, pull requests, and commitsâare mapped to corresponding Azure Boards work items. This links code work in GitHub directly to project management tasks in Azure Boards. For example, a commit message can reference a work item ID, and the system automatically creates a link between them.
After mapping, automated updates synchronize status changes, tags, and links between the two platforms. When a pull request is merged in GitHub, the linked Azure Boards work item can automatically update to a Resolved state. This bidirectional flow depends on the connector service, which monitors events on both sides and propagates updates.
Credentials used for the integration, such as PATs, should be stored securely. Azure Key Vault is the recommended place to store connection strings, passwords, and tokens instead of placing them in Git repositories. For enhanced security, you can use Microsoft Entra ID integration for login, which reduces the need to manage long-lived tokens.
Code and test traceability means tracking every piece of code and its tests from creation to deployment. When traceability works, teams can answer questions like "which code change caused this bug?" without guessing. Azure provides three main tools that work together: Azure Repos, Azure Boards, and Azure Pipelines.
Azure Repos is where code is stored and managed. To ensure traceability, teams set up branch policies that enforce rules before code can be merged. One key policy requires each commit to be linked to a work item like a task or bug report. This creates a direct connection between the code change and the reason for the change.
Azure Boards is the work tracking system for managing bugs, tasks, and features. It connects directly with Azure Repos, so when code is committed or a pull request is created, the related work item automatically updates. This gives teams a unified view where they can see all code changes, pull requests, and work items in one place.
Azure Pipelines handles building, testing, and deploying code through CI/CD. When code passes through the pipeline, test results and code coverage data are published and linked back to the specific commits and work items that triggered the build. The pipeline combines this information into quality reports that show whether the code meets required standards before it reaches production.
To visualize workflow metrics, teams must first gather the correct underlying data from their projects. Work item queries in Azure DevOps serve as the primary data source, pulling specific records like user stories based on set criteria. These queries retrieve items that have transitioned through various lifecycle states, such as proposed, active, and completed.
Once the queries are defined, teams display this data using specialized visual components on Azure DevOps dashboards. Cumulative Flow Diagrams track the volume of work items in each state over time, making it easy to see if work is piling up in a specific phase. Line Charts are ideal for showing historical trends, and Analytics Widgets provide pre-built metrics that reduce the need for manual calculations.
Understanding the differences between flow metrics is critical. Cycle Time measures the span from when a work item enters an active state to when it reaches a completed state. Lead Time begins much earlier, measuring the entire lifecycle from the moment a user submits a request to when the value is delivered to production. Time to Recovery tracks the interval between a system failure and its return to a healthy state.
Teams use these configured dashboards to pinpoint inefficiencies. If a Cumulative Flow Diagram shows a widening band for testing, it signals a bottleneck where items are waiting too long for validation. By continuously analyzing these visual trends, teams can make targeted adjustments to their workflows, reduce waste, and measure the impact of their process improvements.
The first step is to decide what to measure by setting up Key Performance Indicators (KPIs). Common KPIs for project planning include Sprint Velocity, Cycle Time, and Backlog Health. These metrics help the team understand their pace, identify delays, and manage future workload.
To get the data for these KPIs, you write queries using Work Item Query Language (WIQL), the special query language used in Azure DevOps. Authoring a query means using the WIQL syntax to ask for specific work items, such as all tasks completed in the last sprint. Optimizing a query makes it run faster by simplifying logic and filtering on indexed fields.
The final step is to turn the query results into easy-to-understand visuals. You can implement dashboards within Azure DevOps to display charts and graphs for your KPIs. These dashboards pull data from your optimized WIQL queries to provide a central place for the whole team to see project health and track progress against goals.
Development telemetry tracks how your application behaves and performs while developers are building and testing it. Azure provides two main tools for this: Azure Monitor and Application Insights. Azure Monitor collects data from your cloud resources, while Application Insights focuses specifically on how your application code performs.
KPIs tell you whether your application is working well. Response Time measures how long the app takes to answer a request. Error Rate counts problems that occur over time. Resource Utilization watches CPU, memory, and network usage to prevent slowdowns caused by overloading your servers.
To collect telemetry data, you create a diagnostic setting that sends logs to an Azure Log Analytics workspace where you can query them. Azure Monitor offers different log collection tiers, so you can save money by using basic logs for data you rarely query and full logs for important diagnostics.
Application Insights is built specifically for monitoring application code. Enabling workspace-based Application Insights gives you better tools for controlling costs. When your app generates too much telemetry data, use sampling to keep only a representative portion. You can also preaggregate metrics, which combines numbers before sending them to Azure, reducing network data.
Kusto Query Language (KQL) lets you search and analyze the telemetry data that Azure collects. Start your queries with the where operator to filter data earlyâthis makes your query run faster. When searching text, prefer has over contains because has is quicker. Use the materialize() function to calculate a repeated value once.
Once you have telemetry flowing, create custom metrics that match your application's specific needs. Run KQL queries regularly to surface performance problems. Set up alerts that notify your team when telemetry crosses certain thresholds, so you can fix issues before they affect users.
The most important metrics to track focus on the health and effectiveness of your tests. The Test Success Rate shows the percentage of tests that pass. Code Coverage measures how much of your application's code is actually run during tests. Test Duration tracks how long tests take to run, which is important for keeping your development pipeline fast.
To gather these metrics, you must add instrumentation to your testing process. Within Azure Test Plans, you can configure settings to collect data on test runs and outcomes. For applications, you integrate Application Insights to automatically capture performance data and exceptions during test execution.
Once data is collected, you use Kusto Query Language (KQL) to examine it. You write KQL queries to filter, summarize, and analyze the test results stored in services like Application Insights. These queries turn raw data into actionable information.
The final step is to present the information clearly. You can build dashboards in Azure Monitor to display the results of your KQL queries as charts and graphs. These dashboards give teams a real-time, visual snapshot of test health, which can be monitored during development or displayed in release pipelines.
Azure provides several services that generate security data. Azure Key Vault tracks who accesses your secrets and keys. Azure Policy watches your resources and flags any that do not meet your security rules. Microsoft Defender for Cloud scans your environment for threats and sends alerts when it finds suspicious activity.
A Log Analytics workspace acts as a central repository that gathers logs from all your Azure resources so you can query them together. Kusto Query Language (KQL) lets you write queries that sift through millions of log entries to find security issues. You can combine KQL with Log Analytics to build interactive dashboards that update in real time.
Azure Dashboards let you combine charts, graphs, and log queries into a single view that shows your security health at a glance. Workbooks go further by letting you add explanatory text alongside your metrics. Setting up alerts through Azure Monitor ensures that critical issues reach the right people fast.
Enable threat detection on all critical services. Review security recommendations from Microsoft Defender for Cloud regularly. Use metric dimensions to add context; for example, tracking which user accounts fail most often tells you whether a specific account is compromised.
To understand the health of a delivery pipeline, teams must track specific performance indicators. Lead time measures the time from a code commit to deployment. Deployment frequency measures how often a team releases updates. Change failure rate is the percentage of deployments that result in a failure. Mean time to recovery is the average time to restore a service after an outage.
Tracking these metrics requires setting up proper data collection. Using Log Analytics workspace insights, teams can run queries to find trends in their deployment data. For applications running in Kubernetes, teams use Container insights alongside Azure Monitor managed service for Prometheus to gather metrics from the network, cluster, and application layers.
Managing delivery metrics also requires balancing performance, cost, and security. High-volume logging can become expensive, so teams should configure cost optimization settings to filter out unnecessary telemetry data. For the data tier, tools like Database watcher help track database health, while recommendations from SQL Database Advisor guide teams on optimization.
Azure Monitor gathers a wide set of performance metrics from services such as SQL Database and virtual machines. Query Performance Insights in SQL Database shows which queries consume the most resources and can recommend improvements. By tracking metrics like CPU and memory, you can spot bottlenecks and decide when to scale or tune a service.
Azure Monitor helps protect your environment by detecting threats and scanning for vulnerabilities. Threat detection in SQL Database alerts you to suspicious activity. A vulnerability assessment tool scans databases for misconfigurations and provides remediation steps. These features generate security recommendations and compliance reports.
Using historical usage data, Azure Monitor can suggest ways to reduce spending. For SQL Database, recommendations include moving to elastic pools, which let you share resources among multiple databases. Azure Monitorâs cost analysis tools track resource consumption over time, making it easier to identify underused resources.
The Database watcher service collects deep telemetry about database performance and presents it in a unified dashboard. Metrics Explorer lets you chart multiple metrics on a single graph. Dashboards and Workbooks are customizable reports that combine metrics, logs, and visualizations for at-the-glance monitoring.
Kusto Query Language (KQL) is the query language used in Azure Monitor to analyze log data. With KQL you can filter, aggregate, and join records from multiple sources, making it possible to investigate performance issues and identify trends that precede failures. By authoring KQL queries, operations teams can respond proactively to anomalies.
A wiki in Azure DevOps acts as a central place where teams write and share project documentation. Team members use Markdown to format text, add headings, links, and tables. For process flow and sequence diagrams, the wiki supports Mermaid syntax, which lets you describe diagrams in simple text that the wiki renders as a visual chart.
Release documentation tells users and other teams what changed in a new version of the software. Release notes can be created in Azure DevOps by pulling information from work items, commits, and pull requests linked to the release pipeline. For API documentation, teams often use tools that generate reference docs from code comments, then publish the output to a wiki or static website.
Git history contains a record of every commit, branch, and merge, which can be turned into readable documentation. Tools and scripts can parse commit messages, tags, and linked work items to generate changelogs. In Azure DevOps, a pipeline can run a script after each release to extract this information and update a wiki page, keeping documentation in sync with what was delivered.
Webhooks send real-time notifications from one service to another when an event occurs, such as a work item being updated. In Azure DevOps, you can configure a webhook to post a JSON payload to a URL of your choice, for example a Slack channel. The receiving service can then trigger its own actions, connecting Azure DevOps with external tools without requiring polling.
Azure Boards can be linked to GitHub repositories so that work items stay connected to the code changes that resolve them. When you commit a message that includes a work item ID, the commit appears in the Azure Boards work item, and the status can update automatically. This integration helps developers stay in GitHub while product owners track progress in Azure Boards.
Microsoft Teams can receive notifications from GitHub or Azure DevOps through connector apps or webhooks. For example, you can add the Azure DevOps app to a Teams channel so that when a build completes, a card appears in the channel with the details. This setup keeps everyone on the team informed about changes without leaving the chat environment.
Cycle Time measures the span from when a work item enters an active state to when it reaches a completed state. In contrast, Lead Time measures the entire lifecycle from the moment a user submits a request to when the value is delivered to production.
Telemetry queries run faster when they start with the where operator to filter data early. Additionally, using the has operator instead of contains speeds up text searches, and using the materialize() function calculates repeated values once.
Teams authenticate the integration between GitHub and Azure Boards by establishing a service connection using a personal access token (PAT). To maintain security, credentials such as tokens and connection strings should be stored in Azure Key Vault rather than Git repositories, or teams can use Microsoft Entra ID integration to reduce the need for long-lived tokens.
Mermaid syntax enables teams to describe process flow and sequence diagrams using simple text inside an Azure DevOps wiki. The wiki then automatically renders that text as a visual chart alongside standard Markdown content.
StudyCerts
StudyCerts