Migrations

One of the main advantages of using ClusterCS Development Environments is the time saved copying a website from Production to a development environment and back or between other environments.  

The Migration section configures all the automation that happens when we want to transfer environment contents to another.  

The elements that can be transferred between environments during migration can be any or all of the following: 

1. Files – option is enabled by default 

Migrating website files can be done with 2 methods: “GIT push” and simple file copy.  

If GIT support has been enabled for the domain, a GIT file transfer option is available. When this migration is performed, a “git commit” will be executed on the source environment and a “git push” will be made to the target environment branch. Post-receive hooks will trigger an automatic checkout of the target branch into its assigned root folder and the new version of the files will now be available there. 

Either with GIT support enabled or not, simple file transfer is available in 2 variants: Replace and Merge. The Replace option will first erase the contents of the target environment and then will copy the source environment files in the target root. The Merge option will only perform the copy of the source environment root to the target environment so all target files will remain there, and common files will be overwritten with the source environment version. 

2. Databases – option is enabled by default 

ClusterCS can migrate a source environment database with an associated user to a target environment database and user. 

There are 3 database migration options: “Auto”, “Custom” and “Custom with existing database”. 

“Auto” is the default option and lets ClusterCS create a database and associated user automatically in the target environment and copy the source database contents in the target database. 

“Custom” is mostly automated but gives the option to specify the new database name and user name that should be created in the target environment. Source database contents will be copied into the target database name that has been specified. 

“Custom with existing database” will allow the selection of an existing database and user in the target environment. This means that the target database and user have been previously created and they should be used for the migration. The source database will be copied in the selected target database. The copy process will replace tables in the target database that are present in the source database. 

It’s important to note that databases names and user names that reside in the same MySQL server system must be unique. Therefore, you will not be able to have an identical database or user names created between environments under a single MySQL server system. ClusterCS can manage clusters of servers from simple to complex architectures. In more complex setups where multiple MySQL server systems are available, database and user names can be identical between environments if each environment creates the database and user in separate MySQL systems. When multiple MySQL systems are available, ClusterCS provides the possibility to select the target MySQL server system under all 3 database migration options. 

When combining database migrations with Tracked Items, ClusterCS can automatically overwrite target configuration files defined in Tracked Files section with newly generated or selected database name, user and password. Please read more about this powerful automation “here” 

3. Rewrite tracked files – option is enabled by default 

The Tracked Items section helps define special migration variables and files that use those variables. When performing a migration, those files can be automatically overwritten with the defined tracked file version and by replacing the variables in the file with the correct value for the target environment.  

Let’s consider a very common example where a configuration file defines the database connection parameters. This file can be pasted as a tracked file in the Tracked Items section and the parameters can be replaced by the ClusterCS generated variable names for the database name, user name password, etc. When the migration is performed for tracked files, the variables will be reevaluated for the target environment, replaced in the tracked file contents and then the file will be overwritten on the specified tracked file path. 

When combining file, database and tracked file migration you have full automation that creates an independent copy of the source environment website in the target environment with its own database and configuration files.  

4. Migrate aliases – option is disabled by default 

A domain can have aliases that point to the same file contents. When creating a new environment, it will automatically inherit the main domain aliases. These aliases can be changed by the user in the new environment for various reasons and the change will be made only for that target environment. If this new domain alias list should be copied to the target environment during the migration, this option needs to be enabled.  

5. Update speed rules – option is enabled by default 

New environments inherit a copy of the main domain speed rules. In many occasions, the new environment is used to test new serving configurations for the domain by using the Speed section to enable or adjust caching configuration, web server configs, https, and www redirects etc. This allows an easy mechanism to test new ideas and when ready, the Migration automation can copy those new Speed rules to the Production environment or any other desired development environment when “Update speed rules” option is enabled. 

6. Update public path – option is enabled by default 

In general, websites use a “public_html” web root. The web root is the path where the server will look for the files when resolving the web request.  

Let’s understand how the web root relates to the environment root. The environment root is the folder that contains all the files for that specific environment. For example, the live website environment is in “/home/<user_name>/web/live/” and any other environment is under “/home/<user_name>/web/<env_name>/”. The web root is a path underneath the environment root which will be used to resolve the web request. If we take the common example of “public_html” and an example web request http://example.org/index.php for the Production website (where example.org should be considered the name of the domain where we are working with the development environments), we can have the following layout: 

Live environment root: /home/<user_name>/web/live/ 

Live environment web root: /home/<user_name>/web/live/public_html/ 

Php file index.php: /home/<user_name>/web/live/public_html/index.php 

If a different environment is opened with the special link provided in the ClusterCS interface under the Dev Env section, the used paths will be as follows: 

Environment root: /home/<user_name>/web/<env_name>/ 

Environment web root: /home/<user_name>/web/<env_name>/public_html/ 

Php file index.php: /home/<user_name>/web/<env_name>/public_html/index.php 

With the above example, we can see why the web root is specific to the environment. Although “public_html” is the most common web root path, many scripts default to other paths (ex: “public”). If such changes are required, the new environment can be migrated, and the target environment will be updated with this new web root path specified in the source environment. 

7. Update php version – option is enabled by default 

Php version is another environment specific configuration. If we want to test whether our website works with a newer version of php, we can create a new development environment for the purpose of this test, migrate our Production website on this new environment, change to the new php version and run all the necessary tests. Once we are sure everything works and that we have fixed any incompatibilities we can migrate back to the Production environment and automatically adjust to the new php version during the automated process.