<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
The Migration section configures all the automation that happens when we want to transfer environment contents to another. <\/p>\n\n\n\n
The elements that can be transferred between environments during migration can be any or all of the following: <\/p>\n\n\n\n
Migrating website files can be done with 2 methods: \u201cGIT push\u201d and simple file copy. <\/p>\n\n\n\n
If GIT support has been enabled for the domain, a GIT file transfer option is available. When this migration is performed, a \u201cgit commit\u201d will be executed on the source environment and a \u201cgit push\u201d 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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
ClusterCS can migrate a source environment database with an associated user to a target environment database and user. <\/p>\n\n\n\n
There are 3 database migration options: \u201cAuto\u201d, \u201cCustom\u201d and \u201cCustom with existing database\u201d. <\/p>\n\n\n\n
\u201cAuto\u201d 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. <\/p>\n\n\n\n
\u201cCustom\u201d 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. <\/p>\n\n\n\n
\u201cCustom with existing database\u201d 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. <\/p>\n\n\n\n
It\u2019s 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. <\/p>\n\n\n\n
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 \u201chere\u201d <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Let\u2019s 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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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 \u201cUpdate speed rules\u201d option is enabled. <\/p>\n\n\n\n
In general, websites use a \u201cpublic_html\u201d web root. The web root is the path where the server will look for the files when resolving the web request. <\/p>\n\n\n\n