Add Warden enivonment service and configuration versioning

[hardyjohnson]

Environment versioning

In order to more accurately and effectively support the modeling of an application's services and their configurations,
an "environment" within Warden, we should add a versioning methodology to each supported environment.

Adding an environment versioning constraint will allow us to support accurate representation of the necessary services and configuration necessary to run a particular application and support it over time.

Current issues with the pre-built environments today:

• It is difficult to tell what version of an application works with each pre-built environment included within wardenenv/warden.
• No support for environment upgrades based on an application version e.g. upgrade current installation from Magento2 2.4.5 to 2.4.7 service stack.

Proposed solution:

• Add a convention for environment service versioning
  • ./environments/WARDEN_ENV_TYPE/{WARDEN_ENV_VERSION:-DEFAULT} - this path would contain the .init.env, base.yml and docker compose environment partials for a particular application version.
• Add an application version variable to the .env when using env-init to represent the supported application's modelled service and configuration version.
  • WARDEN_ENV_TYPE=magento2
  • WARDEN_ENV_VERSION=2.4.7
• Update the env-init and env commands to work with these changes, allow for application version to be passed in env-init.
• Update documentation explaining application version usage.

[hardyjohnson]

As environments and versions are continually evolving, moving environments out of the main warden tool repository and into some form of application service configuration library / repository for on demand download might be one option to look at in the future.

[bap14]

I'd support this for env-init, if we have historical info about required versions of applications for all platforms. I have concerns about the warden env command respecting it. What does that really mean? Does warden env then just ignore any changes in the .env file to service versions and just use the actual service versions needed by the new WARDEN_ENV_VERSION?

I think a better solution would be:

• Update warden env-init to support an optional flag of version, which will use that version if possible
• Leave warden env alone
• Add a new warden env-update which takes a version flag and will update the .env file to use the new versions

[navarr]

I would consider .env to be an override at that point. If there's no version, it builds as normal (bc), if there is a version it defaults services for that version, and then any services declared in the .env override.

I also really love the idea of the versions being fetchable so that warden doesn't have to be kept up to date in brew to get the service versions

[bap14]

@navarr I could get behind that.

[hardyjohnson]

@bap14

• As per this idea, the current environment configs would become the default if no version value was given.
• The env and sync cmd files must be refactored or touched here as the mutagen and sync code pulls files from the environments path which will change. No API level change to the env command is in this proposal. Note that is what was meant by the need to update the env command to work with these changes.
• A warden env-update command is a good idea 👍🏽

[hardyjohnson]

I will open a proposed PR later today which may help alleviate any concerns here, this is at heart a fairly simple proposal to help more accurately model application environments going forward.

As we would keep the current configs as the defaults I see little downside to this as a first step to more accurate systems modeling.

Magento 2 has well documented version constraints going back some versions at this point. I am sure we can model the most recent fairly easily. I will take a look at adding support for all the currently included environment types, but may look for some help for a couple of them.