Environments

This section describes the official naming scheme which must be used in new projects and shuold be gradually rolled out to legacy ones, starting from the most recent ones.

IMPORTANT: the indications given in the Codebase section should be followed for all projects before they can be submitted for infrastructure provisioning and deployment.

Naming

Three server standard environments are envisioned:

• Nightly environment indicates a deployment which is only used internally (for development purposes and early-stage testing)
• Staging environment indicates an unofficiale deployment which is not used for the general public but is shared with the customer
• Production environment is the live deployment, which is used for serving the project

The naming scheme described in this section comes from the need of avoiding uncertainty about the meaning of the words used to refer to different things. In this respect, the following names should NOT be used to name server environments:

• Dev is problematic, because development is a local environment: when it’s used on a server, it cannot be specified properly in a codebase (or one ends up with horrors like development.rb or development.js for configuration of local development and dev.rb or dev.js for configuration of a server deployment which is only used internally.
• Test is also very bad because, in software, testing refers to unit testing, not to humans playing around on a server;

The Nightly environment replaces the so-called Dev environment (Dev is ONLY to be used for local machines), Staging keeps the meaning it always had.

Codebase

In general, different codebases might require slightly different actions, depending on the technology. For server deployments, it is always to be assumed that the application will NOT run in development mode.

IMPORTANT: features like stacktraces with interactive console (e.g. Rails) or access to browser inspector plugins (e.g. Vue) will NOT be available on a server deployment.

JS and PHP

For every application, the production environment needs to be configured so that it entirely relies on environment variables (which are set in the deployment and/or the build which happens in a CI/CD pipeline).

Ruby on Rails

For Rails projects, the credentials system should be used, with encrypted configurations for each environment. All config files should contain values for all environments.

TIP: watch out for all config/*.yml files and make extensive use of the default configuration.

# config/database.yml
default: &default
  adapter: postgresql
  encoding: unicode
  port: 5432
  pool: 5
  database: <%= Rails.application.credentials[Rails.env.to_sym][:database][:name] %>
  username: <%= Rails.application.credentials[Rails.env.to_sym][:database][:username] %>
  password: <%= Rails.application.credentials[Rails.env.to_sym][:database][:password] %>
  host:     <%= Rails.application.credentials[Rails.env.to_sym][:database][:host] %>

development:
  <<: *default

nightly:
  <<: *default

staging:
  <<: *default

production:
  <<: *default