Yes, this is a good practice. Good article.

I usually create a separate env file for each category of environment: e.g., a local test env (such as a local VM in my laptop), a Jenkins env, or a cloud env that mirrors the production network, although for the latter I would likely not be using Compose but instead would be using AWS CDK, Terraform, K8, etc. — but the idea of an env file still is powerful. I usually name the different env files with a convention such as env.local.source (because I source them), env.vm.source, env.jenkins.source, etc.

Also, be careful not to put credentials in the env file if the target env is shared. For a personal test env it is okay, but for anything that runs in Jenkins, the credential env variables should be set by reading them from a secrets store.