Acquia Cloud provides a Drupal hosting 'platform as a service'. The following are some small changes that made a big difference over the course of moving the University of Technology, Sydney project to the Acquia Cloud.

Repositories

The Acquia network provides it’s own repository that comes in SVN and GIT flavours. While this allows of Acquia to be able to use it's automation this means that we lose our awesome github tools. So how did we get around this?

Enter Jenkins...

With Jenkins we were able to facilitate the following flow that resulted in us keeping our github repository and all the tools that come with it.

Github, Jenkins, Acquia flow diagram

So how do you configure something like this? I am going to show you.

Jenkins settings

To achieve this the following jenkins modules are required:

  • Git plugin
  • Github api plugin
  • Github plugin

As above we have performed the following after selecting a new build:

  1. Fill out an accurate description of the build task.
  2. Select GIT as our SCM and fill out the repository URL.
  3. Select “Build when changes pushed to Github”
  4. Add a build task (shell script).
  5. Provide the following custom script to the “Execute shell” build step:
# Push code base up to Acquia.
git checkout master
git pull origin master
git push acquia master --force

Note: You might be looking at this snippet and going “How does Nick add the Acquia remote for the push?” To achieve this I had to add it into the workspace (the local copy of the repo that we are working in) only once as the workspace never gets deleted. It only gets the latest code base pulled down. For this project it is:

/var/lib/jenkins/jobs/acquia-sync-releases-project/workspace

Acquia Search

Acquia provides a service to customers called “Acquia search” which essentially is a solr core that can be customised to a set of Acquia approved configurations (apachesol, search_api_solr etc).

For this project we chose to use search_api_solr during the early build phase which meant that we needed to use the search_api_acquia module to connect to the Acquia search core. Once moving to the Acquia cloud we requested an additional 2 cores which resulted in a core per environment (Dev, Test and Prod). We now had 2 types of environments:

  1. PreviousNext hosts (Local development environments with standard solr cores) requiring search_api module.
  2. Acquia hosts that required search_api_acquia module.

To overcome this obstacle we took advantage of the search_api_solr_overrides module which (in conjunction with Acquia providing environment variables) allowed us to specify each Acquia environment to use the search_api_acquia class and PreviousNext local development environments to use the search_api_solr class.

Here is a snippet that takes advantage of the power of search_api_solr_overrides:

  /**
   * Set overrides based on Acquia environment.
   */

  list($ah_site_name, $ah_site_group, $ah_site_stage, $secret) = ah_site_info();
  if (!empty($ah_site_stage)) {
    
    // Override the DEVELOPMENT environment.
    if ($ah_site_stage == 'dev') {
      $conf["acquia_identifier"] = "XXXX-XXXX";
      $conf["acquia_key"] = "XXXXXXXXXXXXXXXX";
      $conf['search_api_solr_overrides'] = array(
        'uts_solr' => array(
    	  'name' => 'UTS Acquia Development (Overridden)',
    	  'description' => 'Solr environment hosted via Acquia',
    	  'class' => 'acquia_search_service',
    	  'options' => array(
      	    'host' => 'search.acquia.com',
      	    'port' => '80',
            'path' => '/solr/XXXX-XXXX',
            'edismax' => 1,
            'modify_acquia_connection' => 1,
            'http_user' => '',
            'http_pass' => '',
            'excerpt' => 0,
            'retrieve_data' => 0,
            'highlight_data' => 0,
          ),
        ),
      );
    }

    // Override the STAGING environment.
    if ($ah_site_stage == 'test') {
      $conf["acquia_identifier"] = "XXXX-XXXX";
      $conf["acquia_key"] = "XXXXXXXXXXXXXXXX";
      $conf['search_api_solr_overrides'] = array(
        'uts_solr' => array(
          'name' => 'UTS Acquia Staging (Overridden)',
          'description' => 'Solr environment hosted via Acquia',
          'class' => 'acquia_search_service',
          'options' => array(
            'host' => 'search.acquia.com',
            'port' => '80',
            'path' => '/solr/XXXX-XXXX',
            'edismax' => 1,
            'modify_acquia_connection' => 1,
            'http_user' => '',
            'http_pass' => '',
            'excerpt' => 0,
            'retrieve_data' => 0,
            'highlight_data' => 0,
          ),
        ),
      );
    }

    // Override the PRODUCTION environment.
    if ($ah_site_stage == 'prod') {
      $conf["acquia_identifier"] = "XXXX-XXXX";
      $conf["acquia_key"] = "XXXXXXXXXXXXXXXX";
      $conf['search_api_solr_overrides'] = array(
        'uts_solr' => array(
          'name' => 'UTS Acquia Production (Overridden)',
          'description' => 'Solr environment hosted via Acquia',
          'class' => 'acquia_search_service',
          'options' => array(
            'host' => 'search.acquia.com',
            'port' => '80',
            'path' => '/solr/XXXX-XXXX',
            'edismax' => 1,
            'modify_acquia_connection' => 1,
            'http_user' => '',
            'http_pass' => '',
            'excerpt' => 0,
            'retrieve_data' => 0,
            'highlight_data' => 0,
          ),
        ),
      );
    }
  }

Note: The core that we used was given the machine name “uts_solr” and we are ensuring that we use the "acquia_search_service" class. Local development environments updated there override accordingly eg. search class "search_api_solr".

Rewrites

As a part of “Go live” we were required to include redirects in the .htaccess. However we only wanted these redirects to occur on the production environment as it would get in the way of local development. Acquia’s apache variables to the rescue!

Acquia provides the following environment centric apache variable:

  Variable: ENV:AH_SITE_ENVIRONMENT
  Value: (dev|test|prod)

Using this variable we were able to write rules like the following example:

  # Redirect http://example.com/foo to "http://example.com/bar"
  RewriteCond %{ENV:AH_SITE_ENVIRONMENT} ^prod$
  RewriteCond %{HTTP_HOST} example\.com [NC]
  RewriteCond %{REQUEST_URI} ^/foo$
  RewriteRule ^.*$ http://example.com/bar [R=permanent,L]

Conclusion

So these were the small changes that ended up making this project’s deployment to Acquia’s environment very successful.

Are there any small changes that you used to make a better experience? Let me know in the comments.

Comments

vesaucodon's picture
vesaucodon

Once moving to the Acquia environment we requested an additional 2 cores which resulted in a core per environment

CodeMonkey's picture
CodeMonkey

Really interesting article, that's exactly what I am doing now. However, in your article, you didn't mention the "subtree", do you mind to explain how to manage the folder mis-match issue when you push to acquia?

From What I found so far, without using subtree, it will push your github repo to acquia repo root level and acquia would not publish.

Post a comment

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.