# Assignment

Earlier today, the Nautilus DevOps team deployed a new release for an application. However, a customer has reported a bug related to this recent release. Consequently, the team aims to revert to the previous version.


There exists a deployment named nginx-deployment; initiate a rollback to the previous revision.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

# Solution

# Rollback — `nginx-deployment` to the previous revision

Revert the deployment to the revision that was live before the buggy release.

> **Why no heredoc `apply` here:** a rollback isn't a declarative manifest operation. It
> doesn't describe a desired end-state in YAML — it tells the Deployment controller to
> switch back to a **previously recorded ReplicaSet revision** stored in rollout history.
> That's an imperative rollout action, so `kubectl rollout undo` is the correct (and only
> idiomatic) tool. Re-applying an old manifest would work only if you happened to still
> have the exact prior YAML, and even then it's the wrong abstraction.

## Command

```bash
# Roll back to the immediately previous revision
kubectl rollout undo deployment/nginx-deployment

# Block until the rollback finishes and pods are Ready
kubectl rollout status deployment/nginx-deployment
```

## How it works

### Rollout history and revisions

Every change to a Deployment's pod template (image bump, env change, etc.) creates a new
**revision**, each backed by its own ReplicaSet. Kubernetes retains old ReplicaSets (up to
`spec.revisionHistoryLimit`, default 10) precisely so you can roll back. You can inspect
them:

```bash
kubectl rollout history deployment/nginx-deployment
```

### What `rollout undo` does

- With no `--to-revision` flag, it reverts to the **immediately previous** revision — the
  one running before the current (buggy) release. That's exactly this task.
- Mechanically, it scales the **previous ReplicaSet** back up and the **current** one down
  using the same `RollingUpdate` strategy — so the rollback itself is gradual and keeps the
  app serving, no full outage.
- The rollback is recorded as a **new** revision in history (revisions move forward even
  when the content is an older template), so you always have a clean audit trail.

### Targeting a specific revision (if needed)

If "previous" isn't the right target, pick an explicit revision from the history:

```bash
kubectl rollout undo deployment/nginx-deployment --to-revision=<N>
```

For this task the default (previous revision) is what's required, so no flag is needed.

## Verify

```bash
# Rollback completed, pods Ready
kubectl rollout status deployment/nginx-deployment

# Confirm the image/template reverted to the prior version
kubectl get deployment nginx-deployment \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

# History shows a new revision at the top reflecting the rollback
kubectl rollout history deployment/nginx-deployment
```

Expected — rollout reports success with all pods `Running`/`READY`, the container image
reverted to the previous release's tag, and a new revision entry recording the rollback.

> If the rollback stalls, `kubectl describe deployment nginx-deployment` and
> `kubectl get pods -l <selector>` show what's blocking (e.g. the old image also failing to
> pull).