Machine Environments

Having separate environments for testing and production (or more) is useful when dealing with complex businesses that handle large amounts of data. This allows features to be tested in a quality server, before they are pushed to production, which lowers the risk of ruining data.

Because of this, we might have multiple machines running, each with their own environment. E.g: we may have two machines, one with the QUAL (quality) environment, and another with the PROD (production) environment. The goal is to use the CoB server with the QUAL environment to test preliminary features or changes, before pushing them to the production machine.

How cob-cli handles environments

Environment Declaration

All servers have at least one envionment. Environments are specified in the /environments/ folder. An environment is represented by a folder with the name of the environment, such as prod which has a file called server (with no extension!). This file contains the name of the server. This results in a tree such as:

In case of production, the server file often contains the name of the server as <server_name>. However, in case of a second environment, you will need to specify a second server (such as server_name-quality in terms of a 'quality' environment) - for every environment, there should be an external server, to which you have access, available at the endpoint <name_in_server_file>.cultofbits.com.

Environment Specific Files

Even if we have multiple machines, we will still use one COMMON GitLab repository. This may seem confusing, since we may want to use different files for each environment. In order to distinguish which files go where, cob-cli uses the following 'filename convention':

`<filename>.ENV__<envName>__.extension`.

Both the cob-cli testand cob-cli deploy assume this naming convention when copying files into a server. For example, imagine we have two versions of the same file, each with a different environment name file1.ENV__qual__.js and file1.ENV__prod__.js. If we want to deploy this file into production using cob-cli deploy -e PROD, cob-cli will identify ONLY the version of file1.js whose env name matches the env name passed using -e. Then, after identifying the file, it will convert its name back into the original file1.ENV__prod__.js ---> file1.js before copying it into the production server.

rsync Filter

Whenever we don't see the need for including certain server directories in an environment, we can always create a file named rsyncFilter.txt within the directory of that environment. On this text file we will need to state the names of the directories we want to excluded. Each name will be preceded by a hyphen, as shown below. These folders are not copied onto the server when a deploy or test is made to that environment.

- /vuepress/debug
- /vuepress/nginx/dist