Important Perspective
Classic is not "wrong". Many enterprises still use it for older .NET, IIS, VM, and regulated release flows. Your job is to understand it well enough to maintain it, debug it, and migrate it when the team is ready.
Classic Pipelines
Understand Azure DevOps Classic Build and Release pipelines, how the visual designer works, where Classic still fits, and how to operate it safely while planning a gradual move to YAML.
🧒 Simple Explanation (ELI5)
Classic Pipelines are like building with a drag-and-drop control panel instead of writing a recipe in a text file. You click buttons, add tasks, connect stages, and tell Azure DevOps what to do. It is useful for teams that want to see the pipeline visually, but it is harder to version, review, and reuse than YAML.
If YAML is like writing the instructions in a notebook, Classic is like arranging blocks on a whiteboard. Both can work. The trade-off is that the whiteboard is easier to start with, but the notebook is easier to copy, review, and improve over time.
💡
🔧 Technical Explanation
What "Classic" Means in Azure DevOps
Classic Pipelines are GUI-defined automation workflows stored in Azure DevOps rather than fully described in a repository file. There are two major forms:
- Classic Build Pipeline for compiling, testing, packaging, and publishing artifacts.
- Classic Release Pipeline for promoting those artifacts across environments like Dev, QA, UAT, and Production.
Classic Build runs tasks on an agent similar to YAML jobs. Classic Release adds environment-specific workflows, approvals, gates, and deployment history. Under the hood, both still use agents, tasks, variables, artifacts, and service connections.
Core Building Blocks
| Component | What It Does | Example |
|---|---|---|
| Task | A reusable unit of work | NuGet restore, VSBuild, HelmDeploy, Azure CLI |
| Agent Job | A group of tasks that run on one agent | Build app and run tests on windows-latest |
| Artifact | Output from build consumed by release | ZIP package, Helm chart, container manifest |
| Environment | A deployment target stage in release | Dev, QA, Prod |
| Approval | Human gate before or after deployment | Ops lead approves production release |
| Gate | Automated quality check | Query work items, check REST endpoint, monitor alert status |
Classic Build Flow
Classic Build Pipeline
Code Commit
→
Classic Build
→
Artifact Publish
→
Release Pipeline
Classic Release Flow
Classic Release Progression
Artifact Source
Build Artifact
Container Image
→
Environments
Dev
QA
Prod
→
Controls
Approvals
Gates
Deployment Logs
🤝 Why Teams Still Use Classic
- Legacy build definitions already work and are business-critical.
- Release approvals and visual environment flows are familiar to operations teams.
- Some teams are not comfortable reviewing YAML in pull requests yet.
- Migration takes time when hundreds of tasks and variables exist.
⚠️
Trade-off
Classic pipelines hide logic in the UI. That means changes are harder to peer review, harder to branch, and harder to audit in Git history. That is the main reason most modern teams prefer YAML for new work.
🛠️ Hands-on
Create a Classic Build Pipeline
- Go to Pipelines → Builds → New Pipeline.
- Select Azure Repos Git as the source.
- Choose the Classic Editor instead of YAML.
- Select the repository and branch, then start with an empty job.
- Add tasks such as UseDotNet, NuGet restore, VSBuild, VSTest, and Publish Build Artifacts.
- Save and queue the build.
text
Typical Classic Build Tasks 1. Get sources 2. Install SDK / runtime 3. Restore dependencies 4. Build solution 5. Run tests 6. Package output 7. Publish artifact
Create a Classic Release Pipeline
- Go to Pipelines → Releases → New pipeline.
- Choose an empty job or a template such as IIS or Azure App Service.
- Link the build artifact from the previous pipeline.
- Create environments like Dev, QA, and Prod.
- Add pre-deployment approvals for production.
- Add deployment tasks like Azure CLI, Helm Deploy, or Kubernetes tasks.
text
Example release sequence Build artifact arrives -> Dev deploy automatically -> QA deploy after smoke test passes -> Production waits for manual approval
Where Classic Connects to AKS and Helm
You can use Classic Release to deploy to AKS using HelmDeploy@0 or AzureCLI@2. You still pass the built image tag and call Helm with environment-specific values. The Kubernetes and Helm concepts remain the same; only the pipeline authoring experience changes.
bash
helm upgrade --install webapp ./charts/webapp \ --namespace production \ --set image.repository=myacr.azurecr.io/webapp \ --set image.tag=$(Build.BuildId) \ --wait --timeout 10m
🐛 Debugging Scenarios
Scenario 1: Release Did Not Start
Symptoms: Build succeeded, artifact exists, but no release was created.
- Check whether Continuous deployment trigger is enabled on the artifact.
- Verify branch filters on the release artifact source.
- Confirm the build actually published the expected artifact name.
Scenario 2: Agent Job Stuck Waiting
Symptoms: Release says "Waiting for an available agent".
- Check if the selected agent pool has online agents.
- Review job demands and capabilities.
- Verify no long-running deployment is monopolizing the only agent.
Scenario 3: Helm Task Fails in Classic Release
Symptoms: The HelmDeploy task fails with authentication or timeout errors.
- Validate the Kubernetes service connection and namespace.
- Check whether the AKS cluster can pull from ACR.
- Run
kubectl get pods -n <namespace>andkubectl describe podto inspect failures instead of assuming the pipeline is the issue.
⚡
Root-Cause Discipline
When a Classic release fails, the root cause is often in the target platform, not the release definition. Distinguish between pipeline orchestration problems, agent problems, and application deployment problems.
📋 Interview Questions
Beginner
What is a Classic pipeline?
A GUI-defined build or release workflow in Azure DevOps where pipeline logic is configured through the web interface instead of being fully stored as YAML in the repository.
What is the difference between Classic Build and Classic Release?
Classic Build produces artifacts, while Classic Release consumes those artifacts and deploys them across environments with approvals and gates.
Why do some organizations still use Classic pipelines?
Because they have legacy processes, existing task-heavy release definitions, strong operational familiarity, and migration effort that must be planned carefully.
Can Classic pipelines deploy to Azure and Kubernetes?
Yes. They use the same tasks, service connections, and target platforms as YAML pipelines.
What is a release approval?
A manual checkpoint where a person must approve an environment deployment before it proceeds.
Intermediate
When would you choose Classic over YAML temporarily?
When a team is maintaining a stable legacy flow with heavy use of visual approvals or when migration risk is higher than immediate benefit, but only with a clear modernization roadmap.
What are the main disadvantages of Classic pipelines?
Poor Git-based versioning, harder code review, weaker reuse, and logic hidden in the UI instead of living beside application code.
How do release gates improve production safety?
They automate verification checks before promotion, such as monitoring queries, REST calls, or work item validation, reducing risky manual judgment.
How do artifacts connect build and release pipelines?
The build publishes a named output, and the release consumes that immutable output so deployment is based on a known build result rather than rebuilding code during release.
How would you secure a Classic release pipeline?
Restrict edit permissions, protect service connections, store secrets in variable groups or Key Vault, enforce approvals, and audit who can deploy to sensitive environments.
Scenario-Based
A release is green, but the app is down. What do you check first?
I verify target health directly: pod status, ingress, service endpoints, image pull status, and application logs. A green release only proves the release tasks finished, not that the application is healthy.
A production release is stuck waiting forever. How do you triage it?
I check for pending approvals, unmet gates, agent availability, and environment locks. Then I inspect the exact stage logs to find the blocking checkpoint rather than rerunning blindly.
How would you plan migration from Classic to YAML for a critical app?
I inventory tasks, variables, approvals, service connections, and artifacts; recreate the build in YAML first; validate parity in a lower environment; then move release logic stage by stage with rollback preserved.
A task works in Dev but fails in Prod. Why might that happen?
Different variables, permissions, service connections, namespaces, approvals, or target infrastructure state. Environment-specific configuration drift is usually the first suspect.
How do you explain Classic vs YAML to a non-DevOps manager?
Classic is quicker to click together, but YAML is easier to version, review, reuse, and scale. Classic helps maintain old flows; YAML is the better long-term operating model.
🌍 Real-World Usage
A large enterprise often has a mixed state: old monoliths on Classic Release, newer services on YAML, and a formal migration plan. Engineers must operate both safely. In practice, the best teams document their Classic pipelines, reduce UI-only complexity, and gradually move reusable logic into YAML templates.
🧾 Summary
Classic Pipelines are the visual predecessor to YAML pipelines. They still matter in real organizations, especially around release orchestration, approvals, and legacy workloads. Learn them to support production responsibly, but prefer YAML for new delivery platforms because it is more reviewable, reusable, and scalable.