Site Factory
Staging a Factory to a non-production environment
As part of maintaining your Site Factory platform, you will develop new features and functionality that you want to test against a representative sample of your websites. To test your feature branches before making them available to your website visitors, you should stage your factory, which copies your websites from your production environment to the non-production environment that you select. The staging process also sends the multisite management information that is required by Site Factory to those non-production environments.
The Factory staging process copies both the multisite management information and the selected websites from the production environment, optionally deleting everything previously in the non-production environment. After completing the copy process, Site Factory scrubs user account and configuration information from any staged websites.
To stage your Factory, you must complete the following steps in the overall process:
After copying your data, verifying it, and deploying code, review the instructions for signing in to a staged and scrubbed website.
The website copy process can take a long time to complete, so when copying websites to a non-production environment, you should not select all of your websites for testing. Instead, stage a representative sample of your production websites to ensure that the updated code functions correctly. To do so, complete the following steps after signing in to your Site Factory Management Console:
If your subscription (glossary term, activate to view definition) contains multiple non-production environments, select the non-production environment to which you want to stage websites.
field, start entering a site name, and then click the correct website from the displayed list.
After beginning the deployment, you should monitor the progress of the deployment to monitor for errors, and to determine when your staging environment is ready for use.
If your Site Factory Management Console displays task log warnings about the data synchronization process encountering an error, see Repairing user ID mismatches when staging a Factory.
To verify the status of a staging deployment:
After verifying that data copied successfully to your non-production environment, you should deploy new code to the non-production environment.
To deploy your release branch to the websites you staged to the non-production environment to ensure that there are not any errors or branch integration issues:
Site Factory begins the update process for the staged websites. If you encounter errors during the update, examine the At a glance section on the Site update status page. For more information about resolving update errors, see Resolving codebase update errors.
After you have successfully deployed the release branch on your non-production environment, you can test your updated, staged websites that contain your changes to the codebase.
If you need to deploy an updated release branch, use the previous steps for deployment and testing.
Site Factory starts the staging process by copying the selected websites and the Site Factory Management Console to the environment you selected. Although the staging process copies the files and databases associated with each selected website, it scrubs the websites of personal data, including the email addresses of user accounts, for all users without either the developer or release engineer roles.
As a result, to sign in to either a staged website or the Site Factory Management Console on the Dev or Test environment, you may not be able to use your usual email address. By default, the scrubbing script replaces your email address username with userXXXXX (where XXXXX is your user account number). You can either sign in using this scrubbed username, or you can follow the procedures described in Protecting accounts during staging or Protecting hosted website accounts during staging to keep your email address from being scrubbed.
For both a list of information scrubbed by default from staged websites and instructions for creating a separate scrub script to remove custom website information that you do not want to copy to staging, see Scrubbing sensitive data from staged sites.
Site Factorypost-staging-update hook scriptsSite Factory offers a post-staging-update hook to synchronize data structure changes and module changes from your production environment to your newly-staged non-production environment. If you have created any post-staging-update hooks, you should verify the hook script executed successfully on all newly-staged websites.
If your staging process completes quickly, and your task log includes a SynchronizationDirector message like the following example, re-stage your non-production environment after selecting the Wipe target environment checkbox:
The target Site Factory is not in a working condition and an incremental
staging was requested which is not allowed in this situation.If staging your non-production environment again doesn’t resolve the problem, contact Acquia Support.
After you complete testing on your staged websites, you can deploy your code changes to your production websites.
As part of maintaining your Site Factory platform, you will develop new features and functionality that you want to test against a representative sample of your websites. To test your feature branches before making them available to your website visitors, you should stage your factory, which copies your websites from your production environment to the non-production environment that you select. The staging process also sends the multisite management information that is required by Site Factory to those non-production environments.
The Factory staging process copies both the multisite management information and the selected websites from the production environment, optionally deleting everything previously in the non-production environment. After completing the copy process, Site Factory scrubs user account and configuration information from any staged websites.
To stage your Factory, you must complete the following steps in the overall process:
After copying your data, verifying it, and deploying code, review the instructions for signing in to a staged and scrubbed website.
The website copy process can take a long time to complete, so when copying websites to a non-production environment, you should not select all of your websites for testing. Instead, stage a representative sample of your production websites to ensure that the updated code functions correctly. To do so, complete the following steps after signing in to your Site Factory Management Console:
If your subscription (glossary term, activate to view definition) contains multiple non-production environments, select the non-production environment to which you want to stage websites.
Select one or more websites that you want to copy to your non-production environment. To do this, in the Choose sites to deploy field, start entering a site name, and then click the correct website from the displayed list.
If you select a primary or secondary website contained in a site collection, the copy process will stage all of the websites in the site collection.
Select one or more of the following checkboxes to customize your staging deployment:
Wipe management console and all stacks on the target environment checkbox: Delete all existing websites on all stacks in the non-production environment and replace them with new copies from the production environment.
Selecting this checkbox when staging a factory with multiple stacks will overwrite all data for all websites on all stacks. This data cannot be recovered.
(Optional) Choose whether to skip site files. Skipping files during staging reduces file storage and the staging operation time. Checking this box causes all files to be skipped during staging. To skip certain files, see Skipping certain files when staging a factory.
After beginning the deployment, you should monitor the progress of the deployment to monitor for errors, and to determine when your staging environment is ready for use.
If your Site Factory Management Console displays task log warnings about the data synchronization process encountering an error, see Repairing user ID mismatches when staging a Factory.
To verify the status of a staging deployment:
After verifying that data copied successfully to your non-production environment, you should deploy new code to the non-production environment.
To deploy your release branch to the websites you staged to the non-production environment to ensure that there are not any errors or branch integration issues:
Mon Feb 24 13:28:38 2014 (13:28:38 GMT on February 24, 2014)@1393248518 (13:28:38 GMT on February 24, 2014)Code only: Causes the update to set only the version control system (VCS) code path, which it does for all of the websites at the same time. This can reduce the time required to complete the process.
Select this option only if you meet both of the following conditions:
Code and databases, and rebuild registries: Causes the update to complete all of the actions from the Code and databases option, while also rebuilding the registries.
Site Factory begins the update process for the staged websites. If you encounter errors during the update, examine the At a glance section on the Site update status page. For more information about resolving update errors, see Resolving codebase update errors.
After you have successfully deployed the release branch on your non-production environment, you can test your updated, staged websites that contain your changes to the codebase.
If you need to deploy an updated release branch, use the previous steps for deployment and testing.
Site Factory starts the staging process by copying the selected websites and the Site Factory Management Console to the environment you selected. Although the staging process copies the files and databases associated with each selected website, it scrubs the websites of personal data, including the email addresses of user accounts, for all users without either the developer or release engineer roles.
As a result, to sign in to either a staged website or the Site Factory Management Console on the Dev or Test environment, you may not be able to use your usual email address. By default, the scrubbing script replaces your email address username with userXXXXX (where XXXXX is your user account number). You can either sign in using this scrubbed username, or you can follow the procedures described in Protecting accounts during staging or Protecting hosted website accounts during staging to keep your email address from being scrubbed.
For both a list of information scrubbed by default from staged websites and instructions for creating a separate scrub script to remove custom website information that you do not want to copy to staging, see Scrubbing sensitive data from staged sites.
Site Factory offers a post-staging-update hook to synchronize data structure changes and module changes from your production environment to your newly-staged non-production environment. If you have created any post-staging-update hooks, you should verify the hook script executed successfully on all newly-staged websites.
If your staging process completes quickly, and your task log includes a SynchronizationDirector message like the following example, re-stage your non-production environment after selecting the Wipe target environment checkbox:
The target Site Factory is not in a working condition and an incremental
staging was requested which is not allowed in this situation.If staging your non-production environment again doesn’t resolve the problem, contact Acquia Support.
After you complete testing on your staged websites, you can deploy your code changes to your production websites.
If you select a primary or secondary website contained in a site collection, the copy process will stage all of the websites in the site collection.
Select one or more of the following checkboxes to customize your staging deployment:
Wipe management console and all stacks on the target environment checkbox: Delete all existing websites on all stacks in the non-production environment and replace them with new copies from the production environment.
Selecting this checkbox when staging a factory with multiple stacks will overwrite all data for all websites on all stacks. This data cannot be recovered.
(Optional) Choose whether to skip site files. Skipping files during staging reduces file storage and the staging operation time. Checking this box causes all files to be skipped during staging. To skip certain files, see Skipping certain files when staging a factory.
Mon Feb 24 13:28:38 2014 (13:28:38 GMT on February 24, 2014)@1393248518 (13:28:38 GMT on February 24, 2014)Code only: Causes the update to set only the version control system (VCS) code path, which it does for all of the websites at the same time. This can reduce the time required to complete the process.
Select this option only if you meet both of the following conditions:
Code and databases, and rebuild registries: Causes the update to complete all of the actions from the Code and databases option, while also rebuilding the registries.
To use this option, you must add Registry Rebuild to the docroot/sites/all/drush folder in your code repository. If you have not added Registry Rebuild to this folder (even if you have added it to a folder in specific websites’ repositories), the code update will use the Code and databases option and add a warning to the logs.
Select this option if you have moved files around in your code repository since the last time you sent code to the environment (for example, moving an installed module from /sites/all/modules to /sites/all/modules/custom).
If this content did not answer your questions, try searching or contacting our support team for further assistance.
To use this option, you must add Registry Rebuild to the docroot/sites/all/drush folder in your code repository. If you have not added Registry Rebuild to this folder (even if you have added it to a folder in specific websites’ repositories), the code update will use the Code and databases option and add a warning to the logs.
Select this option if you have moved files around in your code repository since the last time you sent code to the environment (for example, moving an installed module from /sites/all/modules to /sites/all/modules/custom).
If this content did not answer your questions, try searching or contacting our support team for further assistance.