DevOps is a cultural and technical movement that breaks down the traditional barriers between software developers (the people who write code) and IT operations (the people who run that code on servers). For the AZ-400 exam, and for real-world work, you need to understand how DevOps principles and tools like Azure DevOps enable organisations to deliver software faster, safer, and more reliably, directly turning a business idea into a working feature for users without the old-world delays and finger-pointing.
Jump to a section
A simple way to picture Introduction to DevOps and Azure DevOps
A family kitchen is a place of constant activity, collaboration, and sometimes chaos. The kitchen represents the entire software development lifecycle, from the initial idea for a meal (a feature request) to the final delicious dish served to the family (a software update deployed to users).
In a traditional kitchen (old-school IT), the head chef would write the entire recipe alone, hand it to a prep cook, who would then pass ingredients to the line cook, who would cook everything at the end and finally serve it. If the dish was cold, or the sauce was wrong, the entire process had to restart, often taking days. The 'wall' between the head chef and the line cook was a mountain of written orders and waiting.
DevOps and Azure DevOps is like giving that family a shared digital cookbook and a communication system. The head chef (developer) writes a small part of a recipe (code), immediately uploads it to a central app (Azure DevOps Repos). The system automatically checks the ingredients (automated testing), combines them with other recipes (continuous integration), and if everything looks good, a notification pops up on the line cook's screen (operations) to start cooking (deployment). The Azure DevOps portal is their shared kitchen whiteboard where they track every spice added, every oven temperature change, and every guest complaint in real time. This transforms a chaotic, error-prone process into a smooth, fast, and reliable family dinner service.
At its core, DevOps is a combination of cultural philosophies, practices, and tools that increases an organisation's ability to deliver applications and services at high velocity. The name itself is a portmanteau of 'Development' and 'Operations,' highlighting the goal: to unify these two historically siloed teams into a single, collaborative unit.
Before DevOps, the typical software development lifecycle followed a 'Waterfall' model. A business analyst would write a huge requirements document. Developers would then code in isolation for months, throwing the finished code 'over the wall' to an operations team. Operations would struggle to deploy it, find bugs, and then blame the developers. Developers would blame operations for a bad environment. This cycle was slow, wasteful, and led to long release cycles—sometimes taking six months or a year to update a single piece of software.
DevOps seeks to solve this by implementing several key practices:
Continuous Integration (CI): Developers merge their code changes into a central repository many times a day. Each merge triggers an automated build and a suite of automated tests. This catches integration bugs early, before they become expensive to fix. In Azure DevOps, this is done using Azure Pipelines.
Continuous Delivery (CD): This is the natural extension of CI. After the CI pipeline passes, the code is automatically prepared for release to production. The software is always in a 'deployable' state. A manual approval process might be needed to actually push the button, but the heavy lifting is automated.
Infrastructure as Code (IaC): Instead of manually configuring servers, you manage your infrastructure (servers, networks, databases) using configuration files and code. This is typically done with tools like Terraform or ARM templates in Azure. It makes infrastructure repeatable, version-controlled, and auditable.
Monitoring and Logging: DevOps teams use robust monitoring and logging tools (like Azure Monitor) to track application performance, user behaviour, and system health in real time. This feedback loop helps them catch problems before they affect customers and informs future development decisions.
Microservices Architecture: Instead of building one giant application (a monolith), you build many small, independent services that communicate with each other. This allows teams to update one part of an application without taking down the whole thing.
Azure DevOps is the Microsoft toolchain that provides a unified platform to implement these practices. It is a set of developer services that includes:
Azure Repos: A set of version control tools (Git repositories) for managing your code.
Azure Pipelines: The CI/CD service for building, testing, and deploying your code to any platform.
Azure Boards: A set of agile planning tools for tracking work items, features, and bugs (like a digital project board).
Azure Test Plans: A tool for manual and exploratory testing.
Azure Artifacts: A place to host, share, and manage packages (like NuGet or npm) used in your build process.
Why did DevOps replace the old way? Because the old way is too slow and risky in a world where a competitor can update their app twice a day. A company using DevOps can deploy hundreds of times per year with lower failure rates and faster recovery times when something does go wrong. This directly translates to faster delivery of value to customers.
Plan and Track Work
Using Azure Boards, the team creates 'work items' like User Stories (a feature from a user's perspective) and Tasks (small technical steps). This replaces sticky notes and email chains. For example, a User Story might be 'Customer can log in with their Google account'. The team estimates effort and assigns it. This step is crucial because it creates a single, transparent source of truth for what everyone is working on, directly linking business requirements to code changes.
Write and Commit Code
A developer creates a new 'branch' (a copy) of the main code in Azure Repos. They write code for the new feature (e.g., the Google login button). Once done, they commit their changes locally and then 'push' that branch to Azure Repos. They then create a 'Pull Request' (PR) asking for their code to be merged into the main branch. This step is vital because it isolates work-in-progress from the stable codebase and allows for code review.
Build and Test (Continuous Integration)
When the Pull Request is created, Azure Pipelines automatically triggers a 'Build Pipeline'. This pipeline checks out the code, compiles it, runs hundreds of unit tests and static analysis tools. If all tests pass, the code gets the green light to be merged. If a test fails, the developer is notified instantly. This is the 'CI' part. It ensures that any integration issues between different developers' code are caught within minutes, not weeks.
Release and Deploy (Continuous Delivery)
After the code is merged into the main branch, a 'Release Pipeline' in Azure Pipelines takes over. It first deploys the new build to a staging environment (which mirrors production). Automated integration tests run against the staging site. Then, a manual 'approval gate' requires a QA manager to click 'Approve'. Once approved, the pipeline automatically deploys the build to the production servers. This step defines 'Continuous Delivery'.
Monitor and Learn (Feedback Loop)
Once the new feature is live, Azure Monitor tracks key metrics like page load times, error rates, and server CPU usage. The team sets up alerts for unusual spikes. If a bug slips through, like the Google login crashing on old browsers, the alert fires. The team can then quickly fix it, commit the fix, and the whole pipeline starts again. This step closes the loop, turning operations data into input for the next plan, which is the essence of a mature DevOps practice.
Imagine you work as a junior DevOps engineer for a mid-sized e-commerce company called 'ShopBright'. ShopBright has an online store that customers use to buy home goods. The company has a small team of five developers and two operations staff. Currently, their deployment process is a nightmare. Developers write code on their laptops, then manually copy files to a shared drive. An operations person then logs into a server, copies the files, and restarts the website. This process happens once a month, takes a full day, and breaks the site every single time.
Your manager asks you to modernise this process using Azure DevOps. Here is exactly what you do step by step:
Source Control with Azure Repos: You create a Git repository in Azure Repos. You teach every developer how to git push their code to this central repository. Now, instead of a shared drive, you have a single source of truth for all code, with history and version control. This is the foundation for everything else.
Build Automation with Azure Pipelines (CI): You create a 'Build Pipeline' in Azure Pipelines. This is a YAML file (a configuration file) that defines what happens every time a developer pushes code. For ShopBright, the pipeline:
Checks out the latest code from Azure Repos.
Installs the required software dependencies (like Node.js packages).
Runs all the unit tests (hundreds of automated tests that check if individual pieces of code work).
Packages the application into a deployable artifact (like a .zip file).
Stores that artifact in Azure Artifacts.
Now, every time a developer pushes code, they get a green checkmark or a red X within 15 minutes. They know immediately if their code broke something.
Release Automation with Azure Pipelines (CD): You create a 'Release Pipeline' that takes the artifact from the Build Pipeline and deploys it. First, you define a 'staging' environment (a test server that looks like the real website). Whenever a new build is ready, the pipeline automatically deploys it to staging. You configure an approval gate: the QA team lead must manually click a button to approve the deployment to the live production website after they test it on staging. This combination of automation and manual approval dramatically reduces human error.
Monitoring with Azure Monitor: You set up Azure Monitor to collect performance data from the live website. You create a dashboard showing page load times, error rates, and server CPU usage. If an error spike occurs after a new deployment, the team gets an alert. This replaces the old method where a customer would call to complain before anyone knew the site was down.
The result? Deployments now happen every week, take 20 minutes, and the site rarely breaks. The operations team no longer fears 'deployment day'. The developers feel more confident because they get faster feedback. The business is happier because features ship faster, like an instant 'wishlist' feature that a competitor just launched.
The AZ-400 exam, 'Designing and Implementing Microsoft DevOps Solutions', tests your ability to design a DevOps strategy and implement it using Azure DevOps. The exam does not just ask you to memorise definitions; it asks you to apply concepts to realistic scenarios. Here is exactly what they test about this introduction chapter:
Core Tested Concepts: - The definition and goals of DevOps (culture, automation, measurement, sharing - CAMS). - The difference between Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment. - The purpose of Azure Boards for work tracking. - The role of Azure Repos as a Git-based source control. - The distinction between a Build Pipeline (CI) and a Release Pipeline (CD). - The concept of Infrastructure as Code (IaC) and its benefits. - The importance of monitoring (Azure Monitor) as a feedback loop.
Question Patterns and Traps: - 'Drag and Drop' to order the CI/CD pipeline steps correctly (e.g., 'Push code -> Build -> Run tests -> Package -> Deploy to Staging'). - 'Multiple Choice' with one correct definition among distractors. Trap: confusing 'Continuous Delivery' (manual approval needed for production) with 'Continuous Deployment' (fully automated to production). The exam loves this distinction. - 'Case Study' where a company is described with specific pain points (long release cycles, blaming between Dev and Ops). You must select the DevOps practice that solves that specific pain point. The trap here is choosing a solution that is technically correct but does not address the specific described symptom (e.g., suggesting 'Microservices' when the real problem is 'lack of automated testing'). - 'Best tool for the job' questions. Example: 'Which Azure DevOps tool would you use to track progress on a new feature request?' Correct answer: Azure Boards (specifically a Work Item like a User Story), not Azure Repos or Pipelines. - 'Always choose the most automated, secure, and efficient option' is a guiding principle. If a question asks how to deploy to a server, the answer that involves a manual step (like RDPing in) is almost always wrong compared to one that uses an Azure Pipeline Release step.
Key Definitions to Memorise for the Exam: - DevOps: A cultural and technical movement to break down silos between Dev and Ops. - CI: Automatically building and testing every code change. - CD: Automating the release process so you can deploy any good build to production with the push of a button (or an approval). - Azure Pipelines: The CI/CD service. - Work Item: A general term for a piece of work tracked in Azure Boards (e.g., Bug, User Story, Task).
DevOps is a cultural and technical movement that unifies software development (Dev) and IT operations (Ops) to enable faster, more reliable software delivery.
The core technical practices of DevOps are Continuous Integration (automated build and test) and Continuous Delivery (automated release preparation), supported by Infrastructure as Code and monitoring.
Azure DevOps is not a single tool; it is a suite of five services: Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, and Azure Artifacts.
Continuous Integration (CI) means every code push triggers an automated build and test, catching bugs early; Continuous Delivery (CD) means your software is always ready for release to production.
Azure Pipelines is the specific service within Azure DevOps that handles both CI (build pipelines) and CD (release pipelines).
A key exam distinction is that Continuous Delivery requires a manual approval for production deployment, while Continuous Deployment is fully automated with no human gate.
Infrastructure as Code (IaC) is the practice of managing servers, networks, and databases through machine-readable definition files, not manual configuration, making it versionable and repeatable.
Monitoring with tools like Azure Monitor provides the critical feedback loop that tells you if your DevOps process is actually working in production.
These come up on the exam all the time. Here's how to tell them apart.
Continuous Integration (CI)
Focuses on the process of merging code and running automated tests.
Ends with a packaged build artifact that can be deployed.
Happens automatically on every code push to a branch.
Its goal is to detect integration errors early.
Continuous Delivery (CD)
Focuses on the process of deploying that artifact to an environment.
Starts after a build artifact is available.
Often includes manual approval gates before going to production.
Its goal is to make the release process low-risk and repeatable.
Azure Repos
Stores and manages the actual source code files.
Supports branching, merging, and pull requests.
Replaces tools like a shared network drive for code.
Integrated with Pipelines for CI triggers.
Azure Boards
Manages the planning and tracking of work items.
Supports processes like Scrum and Kanban.
Replaces spreadsheets and sticky notes for project management.
Integrated with Repos via linking work items to commits.
Manual Deployment
Requires a human to log into a server and run commands.
High risk of human error (wrong command, wrong server).
Slow and not easily repeatable or auditable.
Often happens infrequently due to the fear of breaking things.
Automated Pipeline Deployment
Is triggered by a commit or a manual button press in Azure Pipelines.
Low risk because every step is defined in code and tested.
Fast, repeatable, and provides a full audit log of every deployment.
Enables frequent, small releases.
Waterfall Methodology
Phases (Requirements, Design, Code, Test, Deploy) happen sequentially.
Feedback is gathered very late, months after development starts.
Large releases with high risk of failure.
Teams are siloed (Dev does development, Ops does operations).
DevOps Methodology
Phases are iterative and overlapping (continuous planning, testing, deploying).
Feedback is gathered continuously through monitoring and automated tests.
Small, frequent releases with low risk and fast recovery.
Teams are cross-functional (Dev and Ops collaborate daily).
Mistake
DevOps is a specific job title or role that a single person holds, like 'DevOps Engineer' meaning they are the only one doing automation.
Correct
DevOps is a culture and a set of practices that involves the entire team, not a single person. A DevOps engineer enables collaboration and builds the toolchain, but the entire Dev and Ops team must adopt the culture.
Companies often hire a single 'DevOps person' thinking they can magically fix all release problems, ignoring the necessary cultural shift across the team. Beginners hear this title and assume it describes a solo superhero role.
Mistake
Azure DevOps is just a single tool, like a fancier version of GitHub, and you only use it to store code.
Correct
Azure DevOps is an integrated suite of five distinct services (Boards, Repos, Pipelines, Test Plans, Artifacts) that work together to manage the entire software lifecycle from planning to monitoring.
The name 'Azure DevOps' sounds like one thing (like 'Azure VMs'). Many beginners only see Repos and miss the power of Pipelines and Boards, thinking it is just a code storage platform.
Mistake
Continuous Delivery means that every single code change automatically goes straight to production users immediately, with no human intervention.
Correct
Continuous Delivery means every change is in a deployable state, but a manual approval gate is usually in place before deploying to production. Continuous Deployment is the fully automated process with no human check.
The two terms sound extremely similar ('delivery' vs 'deployment'), and many study guides use them interchangeably in casual conversation, causing confusion on the exam which specifically tests the difference.
Mistake
Once you adopt DevOps and Azure Pipelines, software releases will never fail and will be completely bug-free.
Correct
DevOps dramatically reduces the risk and frequency of failures, but it does not eliminate them. The goal is smaller, more frequent releases that are easier to fix when they fail, making recovery faster (Rapid Recovery, not Zero Failure).
Marketing hype around 'DevOps magic' leads beginners to believe it is a silver bullet. The exam tests understanding that the real value is in 'faster recovery' and 'smaller blast radius', not perfect releases.
Mistake
DevOps is only useful for large tech companies like Google or Microsoft, not for a small business or a small team.
Correct
DevOps principles and tools like Azure DevOps are incredibly valuable for small teams. They can eliminate manual, repetitive work (like copying files to a server) that a small team cannot afford the time for, and they provide the same fast feedback and quality benefits.
Beginners see case studies from massive enterprises and think the overhead is too high. In reality, Azure DevOps is offered as a SaaS (Software as a Service) platform with a free tier, making it accessible to even a single developer.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, there is a generous free tier for small teams (up to 5 users) that includes all five services (Boards, Repos, Pipelines with limited build minutes, etc.). Larger teams or companies needing more build minutes or users pay a subscription fee.
The build pipeline (CI) is concerned with taking source code and turning it into a build artifact (like a compiled .exe or .zip file). The release pipeline (CD) takes that artifact and deploys it to different environments (dev, test, staging, production).
For the AZ-400 exam, you need to understand the concepts and how to configure the pipelines, but you do not need to be a software developer. However, you will need to read and understand basic configuration files (like YAML) which are code-like, but not programming logic.
Yes, absolutely. Azure Pipelines can connect to repositories hosted on GitHub, Bitbucket, and other Git providers. Azure Repos is not mandatory to use Azure Pipelines.
Instead of a system administrator logging into a server and clicking around to install software or change settings, they write a text file describing exactly what the server should look like. That file is 'run' by a tool (like Terraform) which automatically configures the server to match the file.
Scripts are a manual step that can be inconsistent. Azure Pipelines provides a structured, auditable, repeatable process. It manages dependencies between steps, provides a visual dashboard of success/failure, integrates with work tracking, and handles advanced scenarios like approval gates and rollbacks that simple scripts do not support well.
You've finished Introduction to DevOps and Azure DevOps. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?