Two kinds of automation.
One reviewable change.

1. Prepare the Linux environment.

The server baseline is version-controlled and executed through Semaphore. Reusable tasks configure the intended operating-system state and supporting services. The monitoring selection includes Zabbix and Elastic Agent, so collection is part of the server’s preparation rather than an unrelated afterthought.

The Baseline project exposes the main baseline template. A separate tasks project exposes individual operations. This separation helps avoid applying a full baseline when the intended change is one narrowly scoped task.

2. Describe the application stack.

Compose records the containers, image references, mounts, networks and required runtime inputs. The service’s data and databases are documented alongside the stack, because recreating containers does not recover unique state. Credentials are supplied through protected runtime mechanisms.

A neutral structure is shown below. It is an explanatory example with a volume, not a complete recipe or an installed configuration from the lab.

services:
  notes:
    image: example-registry/notes:reviewed-release
    restart: unless-stopped
    volumes:
      - notes-data:/app/data
    environment:
      APP_MODE: production

volumes:
  notes-data:

The image reference is deliberately illustrative. A real stack also needs its network, secret, health and resource requirements decided for that application.

3. Work in a feature branch.

Changes are prepared in a feature branch, with a diff that explains the final intent. The main branch is reserved for integration through review. Existing application workflows can trigger on pushes to matching paths in non-main branches or through manual dispatch; their exact trigger configuration matters.

This means a push can itself be a deployment action. Review the workflow before publishing a branch, and do not assume that a later merge is the first moment the running environment can change.

4. Test before operational rollout.

Use the appropriate test environment for syntax and behavioural validation. Test the change that matters: repeatability for a baseline, application function for a stack and safe state preservation for a migration. A passing syntax check cannot establish all of those.

UAT is an engineering step in the process. The public flow does not claim that every workflow enforces an automatic UAT gate or automatically promotes a successful build to production.

5. Follow the real delivery sequence.

The reviewed Compose workflow pattern checks out source, prepares the runner and remote access, stops the relevant stack, copies configuration and recreates the Compose services. New workflows should follow the existing suitable pattern with the necessary target and path changes.

This is a concrete deployment sequence, not a claim of zero downtime, automatic rollback or an immutable release platform. Scope, failure handling and recovery depend on the specific workflow.

6. Verify more than job success.

1. Confirm the intended revision, image and runtime configuration reached the correct environment.
2. Check container state, restart behaviour and expected mounts.
3. Validate the real service URL, identity and an appropriate functional operation.
4. Confirm fresh monitoring samples and relevant logs.
5. Record the outcome, data/recovery implications and any explicit follow-up work.

For Ansible, repeat a converged configuration when idempotency is part of acceptance. For a new production service with a URL, Zabbix onboarding is required before treating operational onboarding as complete.

Rollback is service-specific.

A previous Compose definition or image may be sufficient for a configuration-only change. It may be insufficient after a database migration or a change to persistent data. Prepare the recovery path before the change, including compatibility between the old application and the current data.

Backups, a saved configuration and a tested rollback procedure are related controls; none should be silently substituted for another. Read the recovery model →