Environment Promotion

Isolated environments compartmentalized for different purposes is one of the industry practices in product development. The development environment constantly changes; and developers keep constantly uploading artifacts to the environment till such time development is complete, and then the current snapshot is copied to the QA environment for testing. The QA environment does not change, and all the fixes are applied to the development environment. Once testing is complete, the final development snapshot is copied onto the staging environment; that is the current version of the production release. The repository allows you to implement this approach using the cloud. You do not need third-party local version control tools or repositories. You also do not have to integrate your artifacts to Edifecs products.

Consider the following approach when you use the Smart Trading Cloud Repository in project/product development. Before you begin development, an administrator creates a separate folder for a project in the Workspace directory. In the project folder, the administrator creates separate sub-folders for development, quality assurance, and production environments.

Example

repository:/workspace/ProjectA/Dev - for the development environment where developers commit and store artifacts.

repository:/workspace/ProjectA/QA - for the QA environment which is a copy of the Dev sub-folder ready for testing.

repository:/workspace/ProjectA/Prod - for the production environment which is a copy of the QA sub-folder ready for deployment.

Use the {EnvironmentRoot} environment variable in XEServer to use the same paths to access artifacts located at the Dev, QA, and Prod sub-folders. If all three sub-folders contain the Guidelines/101.ecs file, all users should use the {EnvironmentRoot}/Guidelines/101.ecs path, but set up a variable for the corresponding environment.

For example,

  • the development team uses the following variable: EnvironmentRoot:= “repository:/workspace/ProjectA/Dev”;
  • the QA team uses the following variable: EnvironmentRoot:= “repository:/workspace/ProjectA/QA”;
  • a user responsible for deployment uses the following variable: EnvironmentRoot:= “repository:/workspace/ProjectA/Prod”.

With this setup, all contributors are able to work with the same XEServer profiles, even though the paths to repository resources are resolved differently for each of them.

Only an administrator can manage these sub-folders and can provide the following permissions:

  • The Dev sub-folder - full access for developers, read-only access for QA engineers
  • The QA sub-folder - full access for QA engineers

The suggested process is as follows:

  • The development team works in the Dev sub-folder and uploads artifacts there until the project is ready for testing.
  • The QA team copies all the content of the Dev sub-folder to the QA sub-folder and tests the product for bugs.
  • If the QA team finds a bug, the development team fixes it and the QA team copies all the content of the Dev sub-folder to the QA sub-folder again. This process is repeated until no bugs are found and the project is ready for deployment.
  • An administrator copies all the content of the QA sub-folder to the Prod sub-folder and runs production using this sub-folder. To prevent production artifacts from being accidentally affected by other users, the administrator does not provide access to the Prod sub-folder to any user. Once the development and testing are complete, the administrator performs the deployment.

Note To preserve the inviolability of the production environment, we recommend that you create a new user account with read-only access to the production environment and no access to all other environments. XEServer accesses the repository under this user (not under an administrator account) from the production environment and is not able to accidentally access resources from a non-production environment.

We recommend that you create separate folders for each project version you work on. This allows you to maintain multiple versions of the same project development. We also recommend that you create a separate folder for hotfixes that contain only those files that affect the current hotfix.

Example

…/ProjectA/1.0/

QA/

Dev/

Prod/

HF1/

HF2/

…/ProjectA/2.0/

QA/

Dev/

Prod/

…