Implementing Configuration Management on Site Factory: Part 3
- Last updated
- 1 minute read
Goal
Learn about configuration management and the end-to-end deployment workflow that enables success with Site Factory!
Overview
This is the final segment of a three-part guide covering on how to create a Drupal 10 codebase for Acquia Cloud Site Factory (ACSF). With this end-to-end approach, you can quickly install new Drupal sites or update existing sites so they will inherit the managed configuration in your codebase. We will be working with Acquia's Cloud IDE to simplify the development and deployment process.
This guide has been divided into three parts:
- Set up Cloud IDE, Install Drupal 10, and Prepare your Codebase for Site Factory
- Create a Custom Profile and test New Site Creation with Site Factory
- Implementing Configuration Management and Proving out the Site Factory Deployment Workflow
I hope this last phase will help you gain a deeper understanding of the process and feel more confident in your ability to successfully deploy your code changes to ACSF.
-
Making changes to your Codebase: Config Ignore minimal configuration
In order to have configuration differences between your ACSF sites, you will need to list inside the Config Ignore module the configuration files that you wish to be different between your sites.
For example, If you want to have different site names and different blocks added to the Block Layout admin page of each site, you should add the following configurations names to your Config Ignore module:
- system.site
- block.block.* (will ignore all config entities that starts with block.block)
In your Cloud IDE site, go to the Config Ignore admin page ( /admin/config/development/configuration/ignore) and add the following:
ImageSave your changes.
Export the configuration changes
After you make changes to your codebase, it’s a good idea to check for Database updates:
Export the new Drupal configuration:
Deploy your codebase changes to ACSF
First, you need to push your new codebase changes to your repository:
Deploy your codebase to ACSF:
I named this new deployed code: 1.0.1-d10acsf
Go to the ACSF Console UI of one of your lower environments and navigate to Administration -> Update code:
ImageIn the Site Update page, use the dropdown to select your new codebase (1.0.1-d10acsf):
ImageClick the Update button and wait until the update process finishes:
ImageCheck for configuration differences: Create your second ACSF site
It’s recommended that you always create a new site to test that your codebase is working fine, and that it doesn’t create configuration differences.
Create a new ACSF site using your new codebase. Go to Sites and select your group:
ImageClick the “Create a new Site” button:
Give a name to your new site (Example: site2), and click the “Create Site” button:
ImageImageCreate a new Drush alias for your new ACSF site
Go back to your Cloud IDE and create a new Drush alias for your new ACSF site using the aliases.sh bash script. Execute the aliasgenerator.sh bash script and follow the instructions:
Check that your new site doesn’t have configuration differences:
Testing your new codebase: Change the site name of your second site
Login to your new ACSF site using drush uli:
Go to the “Basic site settings” admin page (/admin/config/system/site-information) and change the name of your new site:
ImageSave your changes.
Check that this new change in your second site didn’t create a configuration difference:
-
Making changes to your Codebase: Install a new module
I will install the Shield module to demonstrate the process of adding a new module to your codebase.
Install the new module with Composer
Go to your Cloud IDE instance and execute the following composer command to install the Shield module:
Enable the Shield module:
Go to the Shield module configuration page to make sure the module was installed and enabled successfully (/admin/config/system/shield):
ImageAdd the Shield module to the Config Ignore module
If you wish to have the ability to use different Shield credentials per site, you will need to add the Shield configuration file to the Config Ignore module.
Open a new Terminal window in your Cloud IDE instance and execute “drush cex” to find out the filename of the Shield configuration file. Respond NO to the prompt as we don’t want to export the configuration changes at this moment:
Go to the Config Ignore admin page of your Cloud IDE site and add “shield.settings” to the end of the list (/admin/config/development/configuration/ignore):
ImageExport your new Drupal configuration
After installing a new module, it’s always recommended to see if there are pending database changes:
Run the following BLT command each time there is a core update or if a new module was installed:
Export the new Drupal configuration:
Add your new module to your profile’s .info.yml file
Every time you add a new module to your codebase, you will need to add it to your profile’s .info.yml file.
Open your profile’s .info.yml file (/home/ide/project/docroot/profiles/custom/tamprofile/acsfprofile.info.yml) and under the “install” section, add the new installed module (shield):Save your changes.
Deploy your new codebase changes to ACSF
First, you need to push your new codebase changes to your repository:
Deploy your codebase to ACSF:
I named this new deployed code: 1.0.2-d10acsf
Go to the ACSF Console UI of one of your lower environments and go to Administration -> Update code:
ImageIn the Site Update page, use the dropdown to select your new codebase (1.0.2-d10acsf):
ImageClick the Update button and wait until the update process finishes:
ImageCheck the changes in your existing ACSF sites
After you pushed your new codebase to the test environment and updated all the existing sites in there, you should always check that the changes were applied successfully to your sites.
Go to the Config Ignore module admin page of one of your ACSF sites to check if it has the new “shield.settings” on the list:
ImageEnable the Shield module and check for Configuration Differences
Let’s activate and configure the Shield module on one of your ACSF sites. Go to the Shield module admin page ( /admin/config/system/shield), check the “Enable Shield” checkbox and assign a user and password under the Credentials section. Click the “Save configuration” button to save the changes:
ImageYou should get the Shield “Sign In” prompt right after you hit the “Save configuration” button:
ImageEnter your Shield credentials to test everything is working fine.
Check for configuration differences
Now that one of your sites has the Shield module activated, you should check if there are any configuration differences. Go to your Cloud IDE terminal and execute “drush cex” against your ACSF site that has the Shield module activated:
We don’t have any configuration differences. That means we configured the Config Ignore module correctly to ignore any configuration changes of the Shield module across your ACSF sites.
Create a new ACSF site to test your new codebase
It’s recommended that you always create a new site to test that your codebase is working fine and that it doesn’t create configuration differences.
Create a new ACSF site using your new codebase. Go to Sites and select your group:
ImageClick the “Create a new Site” button. Give a name to your new site (Example: site3), and click the “Create Site” button:
ImageImageCreate a new Drush alias for your new ACSF site
Go back to your Cloud IDE and create a new Drush alias for your new ACSF site using the aliasgenerator.sh bash script. Execute the aliasgenerator.sh bash script and follow the instructions:
Check that your new site doesn’t have configuration differences:
If you see the above message stating that there are no configuration changes in your newly installed ACSF site, that means you configured your codebase correctly.
-
Pushing your changes to prod
After you have tested your new codebase changes in your lower environments (test or dev) and created a new test site to make sure your codebase doesn’t generate any configuration differences, you should be ready to update the code in your prod environment.
The prod environment is where you have all your live sites, that’s why it’s so important to test your new codebase changes thoroughly before you push a new codebase to your prod environment.
Login to the ACSF Console UI of your prod environment and go to Administration -> Update code:
ImageIn the Site Update page, use the dropdown to select your new codebase (1.0.2-d10acsf):
ImageClick the Update button and wait until the update process finishes:
ImageCheck the changes in your existing ACSF sites
After you pushed your new codebase to the test environment and updated all the existing sites in there, you should always check that the changes were applied successfully to your sites.
-
Restart your Cloud IDE workspace using your repository
In this last section, I will explain how to restart your Cloud IDE development workspace using your repository with all your latest codebase changes.
Reset your workspace
Go to your Cloud IDE instance, open the Get Started page (Help -> Get Started), and click the “Reset workspace” button:
ImageYou can also execute the following command to restart your Cloud IDE workspace:
Respond “y” to the prompt to execute the reset-workspace.py script:
ImageClone your repository
In your Cloud IDE, open a new terminal window and make sure you are inside the project folder:
Clone your repository down using the following git command syntax:
Make sure to add the final period “.” so you clone your repository inside the project folder. Example:
ImageExecute "composer install" to generate the vendor folder with all the necessary dependencies:
Install a new site with BLT
Now you should be able to install a new site using the existing configuration on disk:
ImageYou should have no configuration differences between the new site’s database and the existing configuration on disk:
Try to access your new Cloud IDE with “drush uli”:
If you get the following error message, it’s probably because you are missing the .htaccess file from the docroot folder:
ImageLook inside your docroot folder:
Open the .gitignore file located inside the docroot folder, you should see that the .htaccess file is listed to be ignored:
ImageRemove the docroot/.gitignore file:
Copy the htaccess file that’s located inside the project/docroot/core/assets/scaffold/files/ folder to the docroot folder as .htaccess:
Go back to the project folder and clear Drupal’s cache:
Try to access your new Cloud IDE with “drush uli”:
With the new .htaccess file you should be able to access the site without errors:
ImageCopy a site from ACSF to Cloud IDE with BLT
Edit your blt/blt.yml file and modify the value of the drush -> aliases -> remote key with the ACSF website that you wish to copy down to your Cloud IDE, for this tutorial, I will use the site2.01test site:
Save your changes.
Copy the database from the remote site stipulated in your blt/blt.yml file with the following BLT command:
If you want to pull down the assets, execute the following drush command:
https://docs.acquia.com/cloud-platform/manage/files/transfer-files/rsync/
“site2” is the alias of an existing site and “.01test” is the environment where that site lives.
Clear the cache of your new cloned site:
Open your local Cloud IDE website to see your new cloned site. On the Menu, navigate to “Manage Drupal Application” -> “Open Drupal Application”:
ImageBecause we cloned the “site2” site, we should see the Shield module username and password prompt as we previously activated and configured the Shield module on the “site2” ACSF site:
ImageIn my case, my shield credentials for site2 is admin and pass123:
ImageAccess your new cloned site with “drush uli”:
Make sure everything looks fine. It’s always a good idea to check for configuration differences:
Push your new codebase changes to your repository which includes the new .htaccess file in your docroot folder. The next time you restart your Cloud IDE workspace using your repository it shouldn't fail due to the missing .htaccess file.
First, execute the following BLT command to download and extract the updated Acquia Cloud Site Factory Connector:
Commit and push your codebase changes to your repository:
Congratulations on successfully completing this three-step guide! First, we navigated through the process of creating a new Drupal 10 codebase that is configured for ACSF. Then, we created a custom Drupal installation profile. And in this last phase, we went through a detailed explanation of configuration management and deployment workflow on Site Factory. I sincerely hope you found this guide helpful.