Best Practices on Container Environments

Many JENTIS users find that one container alone is insufficient to enable a full dev/stage/production process.

Generally, a container has an environment setting that is either "live" or "stage". However, there are situations where this setting alone can not be used. Also, for migration and release processes, we must discuss some best practice concepts.

Regular Use of Environments

In the easiest scenario, you have one website and domain. The stage environment of your frontend website lives on this same domain, i.e., "http://stage.mywebsite.com ," while the production environment is found on "http://www.mywebsite.com ”.

In this case, we recommend one single JENTIS container for this website. In this container, you can use two slightly different JS code snippets to embed the right environment: JENTIS Code Snippet

Above the code snippet in the left corner, you can select the environment: live or stage. This will generate two different code snippets for each.

This is the best practice for one domain. You must not migrate (copy paste) any setting from one place to the other, just release to the right environment in the Versions and Preview.

Advanced Use of Environments

In some cases, a single container can not work for a website. In that case, it is or may be mandatory to create a container for each environment.

Multiple containers have references to the environment in the names "my website PROD" and "my website STAGE", and both containers have their own DNS A Record and JENTIS Code Snippet.

With this setup, you can work similarly to the regular environment, with only slight differences in publishing and migration.

Migration on Multi Container Environment

Now, with multiple containers, JENTIS scales as it does with regular environments. There is just one setting for the elements that are local to containers. As you might remember from our introduction article to containers, the following elements are on a per-container basis: tools, tags, custom code, and CMP connections.

To move a setting, you must select the container you want to use in a certain environment:

With this configuration, you can control what is executed on which container (that represents a certain environment). This must be set for each local element:

• Tools (and hence all tags associated with this tool)

• Codes

• JENTIS CMP Connectors

When a setting is ready for an environment, the regular process of releasing that container version is again performed. You must select both environments when publishing, as this container-environment setting is not used in this scenario.