When I set up the release path for this portal I had a fork in front of me, and which way I went decided whether one person could actually run the thing.
The conventional road was the portal. Open the pull request in a browser, come back later to merge it, click into the cloud console to change a setting, tick the box for whether it survives a deploy. Every one of those is a small manual act, and small manual acts are where a solo operator either spends all day or quietly makes mistakes. The honest alternative to doing it by hand is usually to hire someone whose job is doing it by hand. I did not want either, so I took the other road: if the cloud exposes an action as a command, the agent runs the command, and operating the infrastructure stops being a separate job done by a separate person in a separate tool.
The release step shows what that buys. When a change is ready, the workflow opens the pull request from the command line and sets it to auto-complete. That flag means the PR is not parked waiting for me to wander back and merge it. It completes itself the moment the CI pipeline passes its required checks. I am not the gate. The pipeline is, and the PR knows to wait for it. The human judgment, do I trust this change, already happened when I approved the plan and the gate ran. Re-asking it at merge time is just a click I would forget to make.
One guard makes that safe to leave unattended. Before opening a PR, the workflow lists the active pull requests on the branch and updates the existing one instead of opening a second. Without that check a re-run cheerfully stacks duplicate PRs against the same branch. I know because the first version did exactly that, and untangling duplicate auto-completing PRs is not how you want to spend a morning.
The configuration side is where the command line stops being a convenience and starts being a correctness tool, because the commands are explicit about a thing the console hides.
App Service settings have a property that quietly bites people: on a slot swap, does a setting travel with the code or stay pinned to the slot? In the console it is a checkbox most people never think about. On the command line it is a different flag, and writing the flag forces the decision to be conscious and leaves it in the record. That distinction is load-bearing here. The portal runs nightly jobs that write to the system of record, and there is a non-production slot used as a parking lot for stakeholder review. If those jobs ran on the parking-lot slot too, it would write real, duplicate records into the system of record. So the kill-switch settings that disable them are pinned to that slot with the slot-specific flag. They cannot ride a swap into production. Choosing the pinning flag over the traveling one is a one-line decision, and getting it wrong would have been a data-integrity incident on a contractor's books, not a cosmetic slip. The console would have let me get it wrong without ever showing me the choice.
The rough edges are worth naming, because they are where unattended automation usually breaks. PR descriptions cap at four thousand characters, so the workflow writes tight instead of dumping a wall of text. The CLI is not always on the path in a non-interactive shell, so the invocations prepend it. Dull problems, but the difference between a demo that works once and a workflow that runs every day without me.
The road I did not take was not really "click the buttons." It was "find a second person to click the buttons." Driving the cloud from the command line is how one engineer covers the work a team splits across a developer, a reviewer, and whoever owns the account, on a system that is actively replacing a company's rented software. That is the whole point. The point is not that an agent can type commands. It is that the same loop that wrote the code also releases it and pins the right settings to the right slot, with nobody else in the chain.
That is what forward-deployed actually looks like up close: I build the software and I run the cloud it lives in, embedded on the client's team. If your releases need a human in the loop for every merge and every setting, there is a better way to spend that person, and it starts at /services.