This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
One file in Azure Pipelines
Azure Pipelines in this window is one pipeline file a person can review. The file is azure-pipelines.yml at the root you named, on the branch in the ticket. The generators can draft a container build, a Kubernetes deploy, or a Terraform plan and apply. You draft one of those, not all three. Nothing here connects to the forge.
The first job tests or plans. It cannot apply and it cannot deploy. Apply and deploy are later jobs, protected, and manual until a plan job has been boring. A green first run is not permission to touch production.
A variable group holds secrets. The yaml does not. A personal access token is not the cloud identity. prompt-for-this in a sample is the gap. A real token in the yaml is a token you rotate and remove.
The service connection is the workload identity, and it is not attached to this first job. Owner on that connection is a draft you reject. The identity is a workload identity with the small policy from the IAM guide. It is not your personal key and not an owner role.
A plan job first, on a branch you named
Name the repository and the branch. Draft one pipeline. Read every step. If a step deploys, delete it from this first file or gate it so this branch cannot reach it. The picture from the CI/CD guide still applies: check, plan, stop.
Write the pool or the agent you expect. A hosted agent and a self-hosted agent are different trusts. Pick one and say which network it can reach.
Search the file for keys, passwords, and kubeconfigs. There should be none. The secret names may appear as references. The values do not. A registry login uses the platform store.
The Kubernetes deploy draft and the Terraform apply draft wait even if the generator can write them today. Pick build, or pick plan. The other two files are later tickets. Production is not the cluster and not the account in this file.
# Azure Pipelines note. One file. One job that cannot apply.
# The file is azure-pipelines.yml at the root you named, on the branch in the ticket.
# Secrets come from the platform store.
# No personal cloud key. No owner role.
# prompt-for-this is not a token.
# Production is not the target of the first run.
A change you can finish
Enabling the plan or test job on the named branch is the later change. Deploy stays off.
Rollback is the previous pipeline file. You do not roll back a bad file by changing production to match it.
- Name the repository and the branch.
- Draft one job that tests or plans.
- Remove deploy and apply from that first file.
- Point secrets at the store.
- Confirm the identity is not an owner and not a person.
- Search the file for tokens.
- Leave the other two generators for later tickets.
Mistakes that outlive the command
Azure Pipelines fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Three generators committed in one hour.
- The first job deploying to production.
- A personal access key in the yaml.
- An owner or administrator role on the job.
- A kubeconfig committed beside the pipeline.
- Apply with no manual gate.
- A secret value instead of a reference.
- The wrong branch protected, or none.
- A service connection with Owner rights, or a personal access token in the yaml.
- Editing production because the job failed.
- Calling a green check a release.
Decisions to write down before the window
Decision 1 for Azure Pipelines. One file is in the ticket. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 2 for Azure Pipelines. The branch is named. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 3 for Azure Pipelines. The first job cannot deploy. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 4 for Azure Pipelines. Secrets are references. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 5 for Azure Pipelines. No token is in the file. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 6 for Azure Pipelines. The identity is a workload identity. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 7 for Azure Pipelines. The identity is not an owner. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 8 for Azure Pipelines. Production is not the target. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 9 for Azure Pipelines. The other generators wait. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 10 for Azure Pipelines. A manual gate exists before any later apply. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 11 for Azure Pipelines. The first job has no service connection. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 12 for Azure Pipelines. A second person can point at the stop. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
The hour you stop
Write the account, the project or subscription, the region, and the clock time before you change anything for Azure Pipelines. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.
One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.
A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.
Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.
Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next account waits until someone else can repeat the proof from the notes. Azure Pipelines is done for this window when the proof is written, not when a CLI printed a success line.
This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.
Azure Pipelines checks before the job is enabled
Check 1 in Azure Pipelines checks before the job is enabled. The file and the branch are in the ticket. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 2 in Azure Pipelines checks before the job is enabled. A search found no token. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 3 in Azure Pipelines checks before the job is enabled. The first job plans or tests only. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 4 in Azure Pipelines checks before the job is enabled. The identity is not an owner. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 5 in Azure Pipelines checks before the job is enabled. Production is not named as the target. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 6 in Azure Pipelines checks before the job is enabled. A second person read the stop. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 7 in Azure Pipelines checks before the job is enabled. The repository is one you administer. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 8 in Azure Pipelines checks before the job is enabled. The agent choice is written. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 9 in Azure Pipelines checks before the job is enabled. The hostname in the prompt matches the hostname in the ticket for Azure Pipelines. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 10 in Azure Pipelines checks before the job is enabled. The result line includes the time and the person, not only the command. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 11 in Azure Pipelines checks before the job is enabled. You can point at the rollback value without searching a chat history. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 12 in Azure Pipelines checks before the job is enabled. Done is a sentence a second person can repeat: the proof for Azure Pipelines happened, and the next host is not started early. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
- Azure Pipelines Docker Build & Push Pipeline Generator
- Azure Pipelines Deploy to Kubernetes Pipeline Generator
- Azure Pipelines Terraform Plan & Apply Pipeline Generator
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar. A published page is linked. The others are named until they are published.
- Cheat Sheet: Azure Pipelines YAML Cheat Sheet
- Troubleshooting: Azure Pipelines Troubleshooting Guide
- How-To: Azure Pipelines: Docker Build & Push Pipeline Example
- How-To: Azure Pipelines: Deploy to Kubernetes Pipeline Example
- How-To: Azure Pipelines: Terraform Plan & Apply Pipeline Example
- How-To: Azure Pipelines: Deploy to AWS Pipeline Example
- How-To: Azure Pipelines: Deploy to Azure Pipeline Example
- How-To: Azure Pipelines: Deploy to GCP Pipeline Example
- How-To: Azure Pipelines: Node.js CI Pipeline Example
- How-To: Azure Pipelines: Python CI Pipeline Example
- How-To: Azure Pipelines: Java Maven CI Pipeline Example
- How-To: Azure Pipelines: .NET CI Pipeline Example
- How-To: Azure Pipelines: Go CI Pipeline Example
- How-To: Azure Pipelines: PHP CI Pipeline Example
- How-To: Azure Pipelines: Ruby CI Pipeline Example
- How-To: Azure Pipelines: Rust CI Pipeline Example
- How-To: Azure Pipelines: Static Site Deploy Pipeline Example
- How-To: Azure Pipelines: Security Scanning Pipeline Example
- How-To: Azure Pipelines: Release & Versioning Pipeline Example
- How-To: Azure Pipelines: Matrix Testing Pipeline Example