# Classic pipeline

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/classic-pipeline

## Quick definition

A Classic pipeline is a way to automatically build, test, and deploy software using a visual editor in Azure DevOps. You drag and drop tasks to create a workflow instead of writing code in a YAML file. It is the older style of pipeline that is being replaced by YAML pipelines but is still supported and used in many organizations.

## Simple meaning

Imagine you are a chef in a busy restaurant kitchen. You have a series of steps to make a dish: wash the vegetables, chop them, cook them, plate them, and send them to the table. A Classic pipeline is like having a laminated instruction card with pictures and checkboxes that you follow every time. You can see each step clearly and tick it off as you go. In the world of software development, a Classic pipeline works the same way. It is a set of instructions that tells the computer how to take the code a developer wrote, build it into a working program, run tests to make sure it works, and then send it to a server where people can use it. The key thing is that you build this instruction card by dragging and dropping tasks in a visual screen, not by writing computer code. It is easy to understand and change because you can see all the pieces, like a flowchart for your code. For example, you might have a task that says “get the latest code from the team’s shared folder,” followed by “compile the code into an executable,” then “run the automated tests.” Each task is a step in your recipe. Classic pipelines are very beginner-friendly because you do not need to know a special scripting language to set them up. However, they have limitations. If you want to add complex logic like “if this test fails, send an email to the team,” it can be harder to do in the visual designer. Also, because the pipeline is stored in the Azure DevOps database and not as a plain text file, it is harder to review changes or track version history compared to the newer YAML pipelines that are stored as code files in your project repository.

Classic pipelines are sometimes called “Release Pipelines” or “Build Pipelines” depending on whether they focus on building the code or deploying it to a server. In Azure DevOps, you can create a Classic build pipeline to compile your code and run tests, and then a Classic release pipeline to deploy that compiled code to different environments like development, testing, and production. Each environment can have its own set of approval gates and tasks, such as running a database migration script before deploying the new code. The visual designer shows all environments as columns, with tasks listed vertically. You can link a build pipeline to a release pipeline so that every time a new build succeeds, it automatically triggers the release pipeline. This is very powerful because it automates the entire process from code change to live deployment with very little manual intervention.

As a beginner, you should know that Classic pipelines are still widely used in companies that started using Azure DevOps before YAML pipelines became popular. Many existing projects have hundreds of Classic pipelines that work reliably. Even though Microsoft encourages moving to YAML pipelines, Classic pipelines are not going away anytime soon. They will be supported for the foreseeable future. Understanding how Classic pipelines work will help you maintain older projects and also give you a foundation to understand the concept of pipelines in general. When you hear the term “pipeline” in an IT context, it almost always means an automated workflow that takes code from a developer’s machine and delivers it to users. Classic pipelines are just one specific way of building that workflow in Azure DevOps.

## Technical definition

A Classic pipeline in Azure DevOps is a visual, web-based designer used to define Continuous Integration (CI) and Continuous Delivery (CD) workflows without writing YAML code. It is part of the Azure Pipelines service, which is a cloud-based or on-premises automation platform. The Classic pipeline model uses a drag-and-drop interface where tasks are added, configured, and ordered to create a sequential or parallel execution plan. Tasks are the atomic units of work, each performing a specific action such as building code with MSBuild, running unit tests with VSTest, copying files to a server using FTP, or publishing artifacts to Azure Artifacts.

Classic pipelines are divided into two main types: Build Pipelines and Release Pipelines. A Classic Build Pipeline takes source code from a repository (Azure Repos, GitHub, Bitbucket, or Subversion) and produces build artifacts such as .exe files, .dll libraries, or container images. It typically includes tasks for restoring dependencies, compiling code, running tests, and publishing the build output. The build pipeline can be triggered manually, on a schedule, or automatically upon code commits or pull request completions. Each build run is assigned a unique build number and stores logs, test results, and artifacts for later retrieval.

A Classic Release Pipeline takes the artifacts produced by a build pipeline and deploys them to one or more environments (stages). Each stage can have its own set of tasks, approval gates, and pre-deployment/post-deployment approvals. Environments are typically named like “Development,” “Test,” “Staging,” and “Production.” The release pipeline can also include conditional logic using “Conditions” on tasks or stages, such as “Run this task only when the previous task succeeded” or “Only deploy to Production if all tests in Test pass.” Variables and variable groups are used to customize behavior across stages without hard-coding values. For example, a variable named “DatabaseConnectionString” can have a different value in Development vs Production.

The underlying implementation of Classic pipelines uses Azure DevOps REST APIs and a task execution agent. The agent can be a Microsoft-hosted agent (provided and managed by Microsoft) or a self-hosted agent (installed on your own infrastructure). The agent pulls the pipeline definition from Azure DevOps, downloads the necessary tasks from the marketplace or built-in library, and executes them in the order specified. Each task runs in its own process and can write output to the console, which is captured and displayed in the pipeline run logs. The security model uses service connections to authenticate with external services like Azure subscriptions, GitHub, Docker registries, or Kubernetes clusters. Service connections can be scoped to specific pipelines or all pipelines in the project.

One important technical aspect is that Classic pipelines are stored as JSON definitions inside the Azure DevOps database, not as files in the source repository. This means they cannot be version-controlled as easily as YAML pipelines, which are stored as .yml files in the repo. However, you can export a Classic pipeline definition as JSON and save it in your repository for backup or migration purposes. The visual designer also supports the concept of “phases” in build pipelines, which allow parallelism (e.g., running builds for different architectures simultaneously). For release pipelines, the phases are represented as “stages” with deployment queues and gates (like waiting for a manual approval or checking a monitoring system before proceeding).

In terms of best practices, Classic pipelines should be kept simple to avoid the pitfalls of the visual designer becoming cluttered. Use variables to centralize configuration, document each stage’s purpose, and implement approval gates for production deployments. Also, consider using pipeline caching to speed up builds by caching dependencies like NuGet packages or npm modules. While Classic pipelines are fully functional, Microsoft has deprecated the visual editor for new features, meaning all new enhancements are focused on YAML pipelines. Nevertheless, Classic pipelines remain a supported and stable option for teams that prefer a graphical approach or need to maintain legacy workflow definitions.

## Real-life example

Imagine you are the manager of a sandwich shop that makes custom sandwiches for customers. You have a standard process for making each sandwich, but you want to make sure that every sandwich is made the same way every time, especially when you have many employees working different shifts. You decide to create a “Sandwich Pipeline” using a whiteboard with magnetic cards. Each card represents a step: “Take the bread,” “Spread butter,” “Add lettuce,” “Add tomato,” “Add meat,” “Add cheese,” “Wrap and label.” The cards are placed in order on the whiteboard, and there are separate sections for different types of sandwiches: one column for vegetarian, one for chicken, and one for beef. Each column has its own set of cards specific to that recipe. This whiteboard is your visual pipeline. Any employee can look at the whiteboard and know exactly which steps to follow for each type of sandwich. If a new employee starts, you just point to the whiteboard and say “Follow the cards.” The beauty is that you can easily rearrange the cards if you want to add a new step, like “Toast the bread,” or remove a step that is no longer needed.

Now translate this to IT. The whiteboard is the Classic pipeline editor in Azure DevOps. The magnetic cards are the tasks that you drag and drop into the pipeline. The different columns for vegetarian, chicken, and beef sandwiches correspond to different stages in a release pipeline, such as Development, Staging, and Production. Each stage can have its own set of tasks, just like each sandwich type has its own recipe. When a customer orders a sandwich (a code commit happens), the pipeline starts at the first card, executes the step, and moves to the next card until the sandwich is ready (the code is built, tested, and deployed). If a step fails, like the toaster breaks (a build error), the pipeline stops and the employee knows something went wrong. They can check the logs (the error message) to see where the problem occurred.

The reason this is a Classic pipeline analogy is because everything is visual and managed on the whiteboard. You do not need to write down a recipe in a notebook (YAML file). Anyone can look at the whiteboard and understand the flow. However, if you want to do something complicated, like automatically ordering new bread when the inventory runs low (conditional logic), the whiteboard becomes limiting. You would need to add extra instructions like “If bread count is less than 10, call the supplier.” That is harder to represent with a simple card. This is why YAML pipelines are often preferred for complex scenarios-they allow you to write those conditional rules directly in code. But for the average sandwich shop, the visual whiteboard works perfectly fine, and that is why Classic pipelines are still a very practical tool for many software teams.

## Why it matters

Classic pipelines matter because they provide an accessible and visual way to automate software delivery, which is a core practice in DevOps. In a practical IT context, automation reduces human error, speeds up deployment cycles, and ensures consistency across environments. Classic pipelines lower the barrier to entry for teams that are new to CI/CD because they do not require knowledge of scripting languages like YAML or PowerShell. A junior developer or even a quality assurance engineer can open the pipeline editor, add a task to run tests, and see the results without writing a single line of code. This democratization of DevOps practices is critical for organizations trying to adopt agile methodologies and deliver features faster.

For IT professionals working with Azure DevOps, Classic pipelines are still a major part of many existing projects. Migrating from Classic to YAML pipelines is not always trivial; it requires effort, testing, and team training. Therefore, knowing how Classic pipelines work is essential for maintaining and extending these legacy systems. Even if you start a new project today with YAML pipelines, you will likely encounter Classic pipelines in a job role that involves Azure DevOps administration or migration. Understanding both allows you to bridge the gap and support teams that are not ready to move to YAML.

From a business perspective, Classic pipelines offer a robust solution with approval gates, audit trails, and manual interventions that are necessary for regulated industries like finance or healthcare. For example, a release pipeline can require a manager to approve the deployment to production, and that approval step is visible in the pipeline logs. This supports compliance requirements such as SOX or HIPAA. Classic pipelines also integrate with Azure Boards, allowing you to associate work items with releases, so you can track which features were deployed in which release. This end-to-end traceability is vital for change management.

Another reason Classic pipelines matter is that they are not going away. Microsoft has committed to supporting them indefinitely, even as they push YAML pipelines as the future. Teams that have invested heavily in Classic pipelines can continue using them without fear of sudden deprecation. This gives organizations the stability they need while they plan their long-term strategy. For certification seekers, understanding Classic pipelines is directly relevant to the AZ-400 exam, which covers designing and implementing DevOps practices using Azure DevOps. Questions about Classic pipelines appear in the exam, particularly regarding release management, artifact management, and deployment patterns. Candidates who ignore Classic pipelines risk losing points on questions that ask about the differences between Classic and YAML pipelines or how to configure approval gates in a release pipeline.

Finally, Classic pipelines serve as a learning tool. When you first learn CI/CD, the visual representation helps you grasp the linear flow from code commit to deployment. Once you understand that, moving to YAML pipelines becomes easier because you already know the concept; you are just learning a new syntax. Classic pipelines are not just a legacy feature; they are a practical, accessible, and enduring component of the Azure DevOps ecosystem that every IT professional should understand.

## Why it matters in exams

Classic pipelines are a significant topic in the AZ-400 exam (Microsoft Azure DevOps Solutions). The exam objectives include “Design a build strategy” and “Design a release strategy,” both of which explicitly reference Classic and YAML pipelines. You might be asked to choose between using a Classic build pipeline or a YAML pipeline given a set of requirements. For example, a scenario might describe a team that wants to store pipeline configuration as code in the repository, and you must identify that a YAML pipeline is the correct choice. Alternatively, the scenario might describe a team that prefers a graphical interface for non-developers to manage releases, and you point to Classic pipelines.

The exam also tests your knowledge of how to configure approval gates in Classic release pipelines. You could see a question where you are shown a diagram of a release pipeline with stages and ask: “Which type of approval is configured to require a manager’s sign-off before deploying to production?” The answer would be a “pre-deployment approval.” Another common question pattern: “You need to ensure that a build pipeline runs only when code is pushed to the main branch. How should you configure the trigger?” In a Classic build pipeline, you would set the CI trigger in the triggers tab, selecting the main branch. In a YAML pipeline, you would use a trigger block. The exam will ask you to differentiate between these two approaches.

the AZ-400 exam covers artifact management. You might be asked how to publish artifacts from a Classic build pipeline so that they can be used by a release pipeline. The correct answer is to use the “Publish Build Artifacts” task. Similarly, you might need to know how to link a Classic release pipeline to a specific build pipeline and set up a continuous deployment trigger so that every successful build starts a release. This is a frequent exam scenario.

Another area is variable management. The exam will test your ability to use variables in Classic pipelines, including variable groups linked to Azure Key Vault for secrets. You could see a question like: “You need to store a database password securely and use it in your Classic release pipeline. What should you do?” The answer would be to create a variable group in Azure DevOps, link it to an Azure Key Vault secret, and then reference the variable in the pipeline.

One tricky exam trap is around the concept of “phases” in Classic build pipelines versus “stages” in release pipelines. Some questions try to mix these up. For example, a question might ask: “You need to run unit tests and code coverage in parallel during the build. What should you add?” The answer is multiple phases in a Classic build pipeline, not multiple stages. Stages are only in release pipelines.

Also, the exam may present a scenario where you need to set up a self-hosted agent for a Classic pipeline because the build requires specific software not available on Microsoft-hosted agents. You would need to know how to register an agent and configure the pipeline to use that agent pool.

Finally, there are questions that ask about the limitations of Classic pipelines. For instance, “You want to version control your pipeline configuration alongside your source code. Which pipeline type should you use?” The answer is YAML pipeline, because Classic pipelines are stored in Azure DevOps database and not as files. Understanding these distinctions is critical for scoring well on the AZ-400 exam.

## How it appears in exam questions

Classic pipelines appear in Azure DevOps exam questions in three main patterns: scenario-based, configuration-based, and troubleshooting-based questions. Understanding how these question types are structured will help you prepare.

Scenario-based questions: You are given a fictional company with specific requirements. For example, “Contoso Ltd. has a team of junior developers who are not experienced with YAML scripting. They need to set up a build pipeline that runs automatically for every code commit. The pipeline must compile the code and run unit tests. Which pipeline type should you recommend?” The correct answer is a Classic build pipeline because of the visual interface and ease of use for non-experts. Another scenario: “Fabrikam Corp. needs to deploy their application to three environments: Dev, Test, and Production. They want a manager to approve the deployment to Production manually. Which pipeline configuration should you use?” You would set up a Classic release pipeline with multiple stages and a pre-deployment approval gate on the Production stage.

Configuration-based questions: These ask you to perform a specific task in the interface or choose the correct setting. For instance, “You are configuring a Classic build pipeline. You want the pipeline to be triggered only when code is pushed to the ‘release’ branch. Which option should you modify?” The answer: In the “Triggers” tab, enable CI trigger and specify the branch filter. Another example: “You need to pass the build number from a Classic build pipeline to a Classic release pipeline. How do you achieve this?” The correct approach is to use the build pipeline as an artifact source in the release pipeline, and then reference the Build.BuildNumber variable. Configuration questions may present a screenshot of a pipeline editor and ask, “Where would you add a PowerShell script task that runs on the build agent?” You must identify the correct location (e.g., Agent job phase -> Add task).

Troubleshooting-based questions: These present a problem and ask you to identify the cause. For example, “A Classic release pipeline fails at the Production stage with an approval timeout error. The deployment requires a manager’s approval but the approval was never requested. What could be the issue?” Possible answers: The approval gate was not configured properly, or the approver’s email address is incorrect, or the pipeline does not have permission to send notifications. Another common troubleshooting question: “A Classic build pipeline succeeds but the artifact is not available in the release pipeline. What might be wrong?” The cause could be that the artifact was not published using the “Publish Build Artifacts” task, or the artifact name was misspelled, or the release pipeline is referencing the wrong build pipeline.

there are compare-and-contrast questions: “What is a primary difference between a Classic pipeline and a YAML pipeline?” The answer might be that Classic pipelines are stored in Azure DevOps database while YAML pipelines are stored as files in the repository. Or “Which pipeline type allows branching strategies for templates?” YAML pipelines support repository-level branching for template files, while Classic pipelines do not.

Finally, expect questions about pipeline variables and security: “You have a Classic release pipeline that deploys to an Azure Web App. The web app name is stored in a variable. Which task type would you use to replace the variable value in a configuration file during deployment?” The answer is the “File Transform” task or the “Replace Tokens” task. These questions test your practical knowledge of pipeline configuration.

To succeed, you need hands-on experience creating and running Classic pipelines in Azure DevOps. Theoretical knowledge alone is not enough because many questions require you to know the exact names of tasks, tabs, and options in the user interface.

## Example scenario

You are a DevOps engineer at a company called GreenLeaf Software. The development team has just finished a new feature for their online gardening app. The feature allows users to upload photos of their plants and get care tips. The code is stored in Azure Repos. The team wants to set up an automated process that builds the code, runs all existing tests, and deploys the new version to a test server so that the quality assurance team can verify the feature before it goes live. The team is small and not all developers are familiar with YAML scripting. They prefer a visual approach where they can see each step.

You decide to use a Classic pipeline. Here is how you configure it step by step:

First, you create a Classic Build Pipeline. You select the source repository that contains the gardening app code. You choose the default agent pool (Microsoft-hosted Windows agent) because the app is built on .NET Framework. In the visual editor, you add a task to restore NuGet packages, which downloads the libraries the app needs. Then you add a task to build the solution using MSBuild with the “Release” configuration. Next, you add a task to run unit tests using VSTest. After tests pass, you add a “Publish Build Artifacts” task to save the compiled binaries and web.config files as a zip file named “GardeningApp.zip”. You name the artifact “drop” and set the pipeline to trigger automatically on every commit to the “main” branch.

Now, you create a Classic Release Pipeline. You link it to the build pipeline you just created, so that the release pipeline uses the “drop” artifact produced by the build. You add a stage called “Test Environment”. In that stage, you add a task to deploy the artifact to an Azure App Service. You configure the Azure subscription and the app service name using variables. You also add a task for running database schema migration using a SQL script. In the pre-deployment conditions for the Test stage, you set up a manual approval so that a senior developer must approve the release before it deploys to the test server. This approval ensures that only reviewed code gets deployed.

You then configure an automatic trigger from the build pipeline so that every time a new build succeeds, a new release is automatically created and queued for approval. The QA team can then see the release in the “Releases” tab and know that a new version is ready for testing. If the build fails (e.g., a unit test fails), the release does not get created because the artifact is not produced.

This scenario demonstrates how Classic pipelines enable a team to set up a complete CI/CD workflow with minimal scripting effort. The visual designer allows the team to see the flow, add approvals, and manage multiple environments easily. It is a realistic scenario that an IT professional might encounter in a small-to-medium-sized software company.

## Common mistakes

- **Mistake:** Thinking that Classic pipelines are completely deprecated and should never be used.
  - Why it is wrong: Microsoft has not deprecated Classic pipelines. They are still fully supported and are a valid choice for many teams, especially those that prefer a visual interface or have existing investments in Classic pipelines.
  - Fix: Evaluate whether a Classic or YAML pipeline best fits team skills, project requirements, and maintainability. Classic pipelines are not obsolete.
- **Mistake:** Confusing build phases in Classic pipelines with release stages.
  - Why it is wrong: Phases are used in Classic build pipelines to run tasks in parallel on different agents, whereas stages are used in Classic release pipelines to represent different deployment environments (dev, test, prod). Equating the two leads to confusion in exam questions and real-world design.
  - Fix: Remember: Build pipelines use “phases” for parallel execution; release pipelines use “stages” for sequential or gated deployments across environments.
- **Mistake:** Assuming that Classic pipelines can be version-controlled and branched just like YAML pipelines.
  - Why it is wrong: Classic pipeline definitions are stored as JSON in Azure DevOps database, not as files in the source repository. You cannot create a branch of a Classic pipeline directly. You can export/import JSON, but it is not the same as having the pipeline code in the repo.
  - Fix: For version-controlling pipeline definitions, use YAML pipelines stored in the repository. If you must use Classic, export the JSON and save it manually in the repo for backup, but be aware that you lose automatic branch linking.
- **Mistake:** Forgetting to add a “Publish Build Artifacts” task in a Classic build pipeline.
  - Why it is wrong: Without this task, the build output is not stored as an artifact. The release pipeline will have nothing to deploy. Many beginners assume the build output is automatically published, but you must explicitly add the task.
  - Fix: Always add a “Publish Build Artifacts” task as one of the final steps in your Classic build pipeline. Name the artifact something clear like “drop” and specify the path to the compiled files.
- **Mistake:** Overlooking the need for agent pools and agent capabilities when using Classic pipelines.
  - Why it is wrong: Some builds require specific software (e.g., Node.js version, Docker) that may not be available on the default agent. If you do not select the correct agent pool (e.g., Ubuntu vs Windows) or do not configure a self-hosted agent, the pipeline may fail with “Agent not found” or missing tools.
  - Fix: In the pipeline settings, choose the appropriate agent pool for your build requirements. If you need custom software, set up a self-hosted agent and ensure it has the necessary capabilities.
- **Mistake:** Misconfiguring the CI trigger in Classic build pipelines by not setting branch filters.
  - Why it is wrong: By default, a CI trigger in Classic pipelines triggers on every branch update. This can cause unnecessary builds for feature branches or work-in-progress commits. Also, forgetting to disable the CI trigger for release branches can cause infinite deployment loops.
  - Fix: In the “Triggers” tab, enable CI trigger and specify the branch filters (e.g., include “main” and exclude “feature/*”). Be intentional about which branches trigger the pipeline.

## Exam trap

{"trap":"The exam may describe a scenario where a team wants to store pipeline configuration as code and use branching strategies for the pipeline itself. Many learners will immediately think of Classic pipelines because they are familiar, but this is a trap.","why_learners_choose_it":"Learners might see “pipeline” and think of what they know best (Classic) without carefully reading the requirement for “storing as code” or “branching.” Also, Classic pipelines can be exported as JSON, leading to the false impression that they are “code.”","how_to_avoid_it":"Always read the requirement carefully: “store as code in the repository” and “use branches for pipeline changes” are the key phrases that point to YAML pipelines. YAML files (.yml) live in the repo, so they can be branched, reviewed via pull requests, and versioned alongside application code. Classic pipelines cannot do this natively. If you see these requirements, choose YAML pipeline."}

## Commonly confused with

- **Classic pipeline vs YAML pipeline:** A YAML pipeline is a pipeline definition written as a YAML file stored in the source repository. Classic pipelines are stored in Azure DevOps database and edited via a visual designer. YAML pipelines allow branching, code reviews, and template reuse. Classic pipelines are easier for beginners but have limited version control. (Example: If you need to branch the pipeline configuration for a hotfix, you use a YAML pipeline. With Classic, you cannot branch the pipeline itself; you would need to copy the pipeline definition manually.)
- **Classic pipeline vs Release pipeline (Azure DevOps):** All Classic release pipelines are a subset of the broader concept of release pipelines in Azure DevOps, but not all release pipelines are Classic. You can also have YAML-based release pipelines (multi-stage YAML pipelines). Classic release pipelines are specifically the ones created with the visual release editor. (Example: When someone says “release pipeline” in an Azure DevOps context, it might refer to either Classic release pipeline or YAML multi-stage pipeline. Always clarify the type when designing a solution.)
- **Classic pipeline vs Build pipeline (Azure DevOps):** Similarly, “build pipeline” is a generic term. A Classic build pipeline is the older visual version. A YAML pipeline can also serve as a build pipeline if it contains only build tasks and no deployment stages. The distinction is in how the pipeline is defined (visual editor vs YAML file). (Example: If you create a pipeline from the “Build” tab and use the visual editor, it is a Classic build pipeline. If you create it by committing a .yml file, it is a YAML pipeline that performs a build.)

## Step-by-step breakdown

1. **Select source repository** — You connect the Classic build pipeline to your source code repository (e.g., Azure Repos, GitHub). This tells the pipeline where to fetch the latest code when triggered. Choosing the right branch is critical because the pipeline will build the code from that branch.
2. **Choose agent pool** — You select which compute environment will execute the pipeline tasks. Microsoft-hosted agents are pre-configured with popular tools, but you can also use self-hosted agents if you need specific software or more control. The agent pool must have the required capabilities (e.g., .NET SDK, Python) for the build to succeed.
3. **Add build tasks** — Using the visual task catalog, you add tasks in order. Common tasks include “NuGet restore” (download dependencies), “MSBuild” (compile code), “VSTest” (run unit tests), and “Publish Build Artifacts” (save outputs). Each task can be configured with parameters like solution path, test filter, and artifact name.
4. **Configure triggers and variables** — You set triggers (CI, scheduled, or manual) to define when the pipeline runs. You also define variables that can be used in task parameters, which allows you to reuse the pipeline across different branches or environments. Variables can be plain text or secret (encrypted).
5. **Create release pipeline and link artifact** — After the build pipeline is ready, you create a Classic release pipeline. You add an artifact source pointing to the build pipeline you just created. This means each successful build will produce an artifact that the release pipeline can consume for deployment.
6. **Add deployment stages and tasks** — You define stages like “Dev,” “Test,” and “Prod.” In each stage, you add deployment tasks such as “Azure App Service Deploy” or “PowerShell script.” You also configure pre- and post-deployment approvals, gates (e.g., health checks), and deployment queues to control the flow.
7. **Save and run the pipeline** — You save the pipeline definition and trigger a build (manually or via a commit). The pipeline executes each task sequentially (or in parallel if phases are used). Logs are generated in real-time. If a task fails, the pipeline stops and reports the error. You can then review the log to fix the issue and re-run.

## Practical mini-lesson

When working with Classic pipelines in Azure DevOps, there are several practical considerations that professionals need to know to use them effectively. First, understand the difference between build and release pipelines. A Classic build pipeline is responsible for turning source code into deployable artifacts, while a Classic release pipeline takes those artifacts and deploys them to environments. In the real world, you often need to chain them together using continuous deployment triggers. This means after a successful build, the release pipeline automatically creates a new release and optionally starts the deployment to the first stage. You set this up by going to the release pipeline, selecting the artifact source (your build pipeline), and enabling the continuous deployment trigger on the artifact.

Another important practical skill is managing variables and secrets. In Classic pipelines, you can define pipeline-level variables that are accessible during the run. However, for secrets like API keys or passwords, you should use variable groups linked to Azure Key Vault. This allows you to store secrets securely and reference them in your pipeline without exposing them in logs. For example, to use a secret variable named “SqlPassword,” you create a variable group, link it to a Key Vault secret, and in your pipeline you reference it as $(SqlPassword). The system automatically hides the value in logs.

One common mistake professionals make is not using the “File Transform” or “Replace Tokens” tasks when deploying to multiple environments. In a Classic release pipeline, you can use configuration transforms to modify app settings or connection strings per stage. For example, in the Dev stage, the Web.config might point to a development database, while in the Prod stage, it points to the production database. You can achieve this by adding a File Transform task that replaces tokens like #{DbConnection}# with the value from a variable defined at the stage level. This is much cleaner than hard-coding values.

Another practical aspect is handling approvals and gates. In a Classic release pipeline, you can set pre-deployment approvals (before the deployment starts) and post-deployment approvals (after the deployment finishes). These are often used for production deployments to ensure a manager or lead reviews the release. You can add deployment gates like querying Azure Monitor for any active alerts before proceeding. This is critical for minimizing downtime.

From a troubleshooting perspective, always check the logs. Classic pipeline logs are rich and include timestamps, task output, and error messages. If a deployment fails, the log will typically show which task failed and why. For example, if an Azure App Service deployment fails, the log might say “ERROR: Failed to deploy using Web Deploy, Error code: ERROR_USER_NOT_AUTHORIZED” indicating a permissions issue. You would then check the service connection permissions.

Finally, consider maintenance. Classic pipelines can become complicated with many stages and tasks. Over time, they may be hard to modify without breaking something. It is good practice to document each pipeline’s purpose and its stages. Also, periodically clean up old pipeline runs to save storage space. Azure DevOps retains pipeline runs indefinitely unless a retention policy is set. You can configure retention at the project level or per pipeline to delete runs older than a certain number of days. This helps manage your DevOps project efficiently.

## Memory tip

Classic pipelines = Visual editor, drag-and-drop, stored in Azure DevOps database. YAML pipelines = Code files, branching, stored in repo. If it is not a .yml file, it is Classic.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/classic-pipeline