Code deployments in Site Factory are performed consecutively, instead of concurrently, to minimize the amount of time any single website on your platform is is unavailable to your website visitors. Site Factory manages the deployment process for you, ensuring your code deploys to all your websites as efficiently as possible without intervention by your team. You can track the progress of the process to determine the status of the process.
To protect your websites from inconsistencies being introduced over the course of a deployment, certain website functions are disabled at the beginning of a deployment. These functions are re-enabled only after the entire platform has been safely updated.
During a code deployment, if you discover an error in your updated code, you can pause the deployment while you upload a new revision of the code to provide a hotfix. For more information, see Hotfixing an Site Factory deployment.
At the beginning of the deployment process, all of your websites are hosted from your production environment. Before initiating code changes to your platform, Site Factory performs the following administrative tasks to both prepare your platform and protect against overlapping changes:
Wait for all tasks that are blocking the update to complete.
After Site Factory completes these steps, your websites remain hosted by your production environment, but your environments are protected from changes that could introduce data inconsistencies between environments.
Step 2: Transferring domains to a secondary environment
After the websites on your platform are protected from any changes that could occur during the deployment, Site Factory will perform the following tasks:
Confirm that the deployment does not contain a major version upgrade to Drupal, and that the acsf-init command has been executed to prepare websites for the platform.
Ensure the code deployed on the update environment matches what is currently deployed on the production environment.
Repoint all domain names in use on the production environment to the update environment, freeing up the production environment to be updated while not taking production traffic.
During this step, Site Factory keeps your websites online by shifting your visitor traffic to the update environment, which remains on the previous version control tag. During the time when visitor traffic is temporarily shifted to the update environment, Site Factory updates the now-idle production environment.
Step 3: Updating the production environment while temporarily idle
After Site Factory transfers the domain names for your websites to the update environment, visitor traffic is routed to the update environment, leaving your production environment idle. During the time your normal production environment receives no traffic, Site Factory deploys your new version control tag to it and clears caches.
During this step, your domains remain in your update environment and use the previous version control tag.
Next, Site Factory begins the process of updating individual websites.
Step 4: Updating and redeploying individual websites
At this step of the deployment, your website traffic is served from your update environment, which remains on your previous version control tag. Your production environment has been updated to your new version control tag, but is not yet receiving traffic.
Place the website into maintenance mode, taking it offline.
Perform any needed database updates to the copy of the website on the production environment. For information about modifying these updates with a hook script, see Overriding the Drush updatedb command.
Disable maintenance mode for the website, which returns the website to online status.
Rebuild the website’s caches to improve performance.
Note
By default, Site Factory clears Drupal caches using the following commands:
After an individual website completes these update steps, the domain names are reattached to the production environment, which contains the new version control tag. All other websites on your Site Factory platform remain in the update environment until they complete the procedures described in this step.
As websites on your platform proceed through this step, they are shifted from your update environment back to your production environment, until all websites are once again live in your production environment. Your update environment, now empty of websites, remains on the old version control tag.
Finally, Site Factory will perform platform cleanup tasks.
Step 5: Cleaning up after updates
After the individual websites have been updated on your production environment, Site Factory will perform the following cleanup tasks for the platform:
Deploy the new version control tag to the now-empty update environment ensuring it matches your production environment.
The code deployment process should be complete. If you receive any update error messages on the Site update status page during the deployment, see Resolving codebase update errors for assistance in resolving the errors.
Important
After you update a site in Site Factory, requests are served from the old codebase for a temporary period of 1 to 3 minutes. This happens because Site Factory does not wait for the deployment completion confirmation before it switches the domains back to production. To prevent this, you must use a feature of Site Factory that necessitates the deployment completion confirmation. Note that this feature slows down the deployment process because of the wait time in realigning all domains with the updated environment. To get this feature enabled, contact Acquia Support.
Tracking the progress of a deployment
You can track the status of the deployment on the At a glance section on the Site update status page. To view this page, complete the following steps:
Sign in to the Site Factory environment that you are updating using an account with either the release engineer or developer role.
In the admin menu, click Administration, and then click the Site update status link.
Note
To confirm your platform version number, or to determine if maintenance has completed for your subscription, see Determining your platform version.
Deploying code in Site Factory
Code deployments in Site Factory are performed consecutively, instead of concurrently, to minimize the amount of time any single website on your platform is is unavailable to your website visitors. Site Factory manages the deployment process for you, ensuring your code deploys to all your websites as efficiently as possible without intervention by your team. You can track the progress of the process to determine the status of the process.
To protect your websites from inconsistencies being introduced over the course of a deployment, certain website functions are disabled at the beginning of a deployment. These functions are re-enabled only after the entire platform has been safely updated.
During a code deployment, if you discover an error in your updated code, you can pause the deployment while you upload a new revision of the code to provide a hotfix. For more information, see Hotfixing an Site Factory deployment.
At the beginning of the deployment process, all of your websites are hosted from your production environment. Before initiating code changes to your platform, Site Factory performs the following administrative tasks to both prepare your platform and protect against overlapping changes:
Wait for all tasks that are blocking the update to complete.
After Site Factory completes these steps, your websites remain hosted by your production environment, but your environments are protected from changes that could introduce data inconsistencies between environments.
Step 2: Transferring domains to a secondary environment
After the websites on your platform are protected from any changes that could occur during the deployment, Site Factory will perform the following tasks:
Confirm that the deployment does not contain a major version upgrade to Drupal, and that the acsf-init command has been executed to prepare websites for the platform.
Ensure the code deployed on the update environment matches what is currently deployed on the production environment.
Repoint all domain names in use on the production environment to the update environment, freeing up the production environment to be updated while not taking production traffic.
During this step, Site Factory keeps your websites online by shifting your visitor traffic to the update environment, which remains on the previous version control tag. During the time when visitor traffic is temporarily shifted to the update environment, Site Factory updates the now-idle production environment.
Step 3: Updating the production environment while temporarily idle
After Site Factory transfers the domain names for your websites to the update environment, visitor traffic is routed to the update environment, leaving your production environment idle. During the time your normal production environment receives no traffic, Site Factory deploys your new version control tag to it and clears caches.
During this step, your domains remain in your update environment and use the previous version control tag.
Next, Site Factory begins the process of updating individual websites.
Step 4: Updating and redeploying individual websites
At this step of the deployment, your website traffic is served from your update environment, which remains on your previous version control tag. Your production environment has been updated to your new version control tag, but is not yet receiving traffic.
Place the website into maintenance mode, taking it offline.
Perform any needed database updates to the copy of the website on the production environment. For information about modifying these updates with a hook script, see Overriding the Drush updatedb command.
Disable maintenance mode for the website, which returns the website to online status.
Rebuild the website’s caches to improve performance.
Note
By default, Site Factory clears Drupal caches using the following commands:
After an individual website completes these update steps, the domain names are reattached to the production environment, which contains the new version control tag. All other websites on your Site Factory platform remain in the update environment until they complete the procedures described in this step.
As websites on your platform proceed through this step, they are shifted from your update environment back to your production environment, until all websites are once again live in your production environment. Your update environment, now empty of websites, remains on the old version control tag.
Finally, Site Factory will perform platform cleanup tasks.
Step 5: Cleaning up after updates
After the individual websites have been updated on your production environment, Site Factory will perform the following cleanup tasks for the platform:
Deploy the new version control tag to the now-empty update environment ensuring it matches your production environment.
The code deployment process should be complete. If you receive any update error messages on the Site update status page during the deployment, see Resolving codebase update errors for assistance in resolving the errors.
Important
After you update a site in Site Factory, requests are served from the old codebase for a temporary period of 1 to 3 minutes. This happens because Site Factory does not wait for the deployment completion confirmation before it switches the domains back to production. To prevent this, you must use a feature of Site Factory that necessitates the deployment completion confirmation. Note that this feature slows down the deployment process because of the wait time in realigning all domains with the updated environment. To get this feature enabled, contact Acquia Support.
Tracking the progress of a deployment
You can track the status of the deployment on the At a glance section on the Site update status page. To view this page, complete the following steps:
Sign in to the Site Factory environment that you are updating using an account with either the release engineer or developer role.
In the admin menu, click Administration, and then click the Site update status link.
Note
To confirm your platform version number, or to determine if maintenance has completed for your subscription, see Determining your platform version.
drushcr
For Drupal 7 sites: drushccall
The above commands clear only Drupal caches and not any other types of caches. To clear other types of caches, such as Varnish or CDNs, you must develop your own custom solutions.
Repoint all domain names for the website from the update environment to the production environment.
Confirm that the domains respond to requests.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
drushcr
For Drupal 7 sites: drushccall
The above commands clear only Drupal caches and not any other types of caches. To clear other types of caches, such as Varnish or CDNs, you must develop your own custom solutions.
Repoint all domain names for the website from the update environment to the production environment.
Confirm that the domains respond to requests.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Site Factory