In the Envirobly context, environ is just a shorter form of the word environment.
An Envirobly project can have multiple environs.
For many projects, you might want to deploy environs like production, staging or preview pull requests. You can test, experiment and run quality assurance, in easy to spin up and isolated environments.
Environs under the same project share the Docker build cache and images corresponding to the same commit. For example,
if you deploy commit 6eaa51c to staging environ and then deploy the same commit to production environ, the images that were already build
for staging for buildable services, will be reused.
# Let's assume you're currently in the "main" Git branch
git status # => On branch main
# Deploy without arguments, will deploy to, or create, environ named "main"
envirobly deploy
# The first argument of the `deploy` command, is the environ name.
# This deploys to, or creates, environ named "production":
envirobly deploy production
You can deploy from any branch to any environ.
The above examples all rely on .envirobly/defaults/project to deploy to the default project.
If you’d like to deploy to environs under a different project and/or account, you’ve got various options to do that:
# Deploy to a specific project by ID
envirobly deploy production --project-id 123
# Deploy to, or create, project and environ by name and specify a region
envirobly deploy production --project-name cool-project --region us-west-1
# Deploy to, or create project and environ by name, within a specific account by ID
envirobly deploy staging --project-name cool-project --account-id 456
These conventions allow you to implement various automated flows, if you choose to. For example you can configure
your CI (like GitHub actions) to run envirobly deploy when a pull request is opened, which will deploy an environ
to review the work in that Git branch. And/or you can run envirobly deploy production when a commit is made to your
main, master or other branch designated for that purpose.