CI/CD & GitOps Guide — MyAdminDesk

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.

A pipeline is a review with a clock

A pipeline here is a picture of steps a person can name: get the file, check it, and stop before production. The visualiser helps you see that picture. The strategy selector helps you name how a later deploy would replace instances. Neither tool connects to a forge or a cluster.

GitOps, on this page, means the desired file lives in git and a person reviews the diff before a cluster changes. It does not mean a robot applies every push to production. The platform guides are where a specific product's file is drafted. This page chooses the shape.

A long-lived cloud key in the repository is the failure. The platform's secret store holds credentials. The job that can apply is protected and manual until you have run a plan job that cannot apply.

Pick one strategy when you are ready to deploy: recreate, rolling, or a blue-green cut you can undo. Write it. Do not implement all three to compare them on a live service.

One picture, a plan job, no key in git

Sketch the pipeline: a change on a branch, a check, a plan, and a stop. Use the visualiser if it makes the stop obvious. The first successful run does not deploy. It shows the plan or the test result.

Choose a strategy with the selector only if a deploy ticket already exists. Record the strategy and how you would undo it. If you cannot say the undo, you do not have a strategy. You have a hope.

Write where secrets live. Search the sample file for keys. prompt-for-this stays as a reminder. A real token never lands in the yaml you commit.

The infrastructure guide owns the file the pipeline would plan. The platform guide owns the product syntax. You do not write three product files in this hour.

# Pipeline note. The first job plans or tests. It does not apply.
# One strategy, when a deploy exists.
# No long-lived cloud key in the repository.
# A protected manual step guards apply.
# prompt-for-this is not a token.

A change you can finish

Turning on a plan job in a lab project is the later change. Apply stays off.

Rollback of a bad pipeline file is the previous file. Rollback of a deploy you have not defined does not exist.

Draw branch, check, plan, and stop.
Confirm the first job cannot apply.
Choose one strategy only if a deploy ticket exists.
Write the undo for that strategy.
Put secrets in the platform store, not the file.
Name the platform guide you will use next.
Leave production apply unbuilt.

Mistakes that outlive the command

CI/CD and GitOps 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.

A key committed because the sample needed to run.
The first green build deploying to production.
Apply with no manual protection.
Three strategies at once.
A strategy with no undo.
A robot applying every push.
Using a personal cloud key as the job identity.
Skipping the plan and calling the pipeline done.
Editing production to match a failed pipeline.
Three product files in one hour.

Decisions to write down before the window

One decision for CI/CD and GitOps: The picture has a stop before production. The first job cannot apply. Secrets are in the store. No key is in git. The job identity is not a person and not an owner. One strategy, or none yet. The undo is a sentence. One platform is next. The infrastructure file is a different guide. Production apply is not built. A second person sees the stop. And one pipeline shape is this window.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for CI/CD and GitOps. 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. CI/CD and GitOps 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.

Pipeline checks before a job is enabled

Confirm this before you call the change done: The picture is in the ticket. Plan and apply are separate. Apply is manual or absent. A search of the file found no key. The identity is a workload identity. The strategy undo is written, or there is no deploy yet. The branch you will use is named. Production is not the target of the first run. The platform guide is named. A second person can point at the stop. The repository is one you administer. No token is in the note. The hostname in the prompt matches the hostname in the ticket for CI/CD and GitOps. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for CI/CD and GitOps happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.