Right now rollbacks were only tested on new projects.
DIfferent project versions should be kept on the server to allow rollbacks on existing projects.

Current folder structure:

• <STACKHEAD_ROOT>/projects/<PROJECT_NAME> (<PROJECT_ROOT>)
  • Caddyfile
  • docker-compose.yaml
  • runtime/container
    • data
    • hooks

Envisioned folder structure:

• <STACKHEAD_ROOT>/projects/<PROJECT_NAME> (<PROJECT_ROOT>)
  • deployments
    • current (Symlink to current version, e.g. v3) – probably no need to be referenced by StackHead, but nice to see the current version. The current version could also be written to a version file e.g. <PROJECT_ROOT>/CURRENT_VERSION
    • v1
      • Caddyfile
      • docker-compose.yaml
      • container
        • hooks
      • resources.json – Serialized list of resources created during the deploymend. Can be used by destroy to remove the project
    • v2
    • ...
    • vn
  • backups – contains folders named by backup timestamp. For backups of container data folders
  • data
    • container – container data. Versioning of is probably not needed, as we could create a backup before each deployment and restore that during rollback

Questions:

• Should version number also be added into container names, so the new version can be created before shutting down the old containers (zero downtime deployment)?
• How to deal with backups of running applications??? Especially databases may lose data -> research needed