This feature has long been a goal for OPTASY; it’s been more challenging than we expected. You see, automation is easy if all sites are built from the same base repository using the same folder structure and implementing the same base modules. Yet OPTASY supports fabulous client sites that, because they leverage the complexity and extensibility of Drupal they are creative sites., each unique, blending modules, custom code and content. A generic one-size-fits-all update process has never worked.
In the past, we have manually updated sites using local scripts and patches, but this method was never going to succeed in providing security updates within 24 to 48 hours of a security release.
Early on, we decided that well-built automation needs to:
Identify and provide security updates released on drupal.org in a timely manner.
Implement a clear path of deployment and testing which starts from and, after validating each environment (Dev; Staging, and Production), and then returns to retest production site code to ensure all updated components have been propagated across all environments.
Allow for testing independently of ongoing development by the customer.
Provide clear and consistent communication to all stakeholders about pending changes.
RA Automation has (mostly) arrived!
Finally, we are well on our way to achieving exactly those standards, providing automated security updates to RA subscriptions within 48 hours of a security release, to both the core and contributed modules. We expect to reach this goal in the first half of 2015, but the beta functionality is already updating RA subscriptions.
With the introduction of automated patch and update deployment, there are minor but meaningful changes going on with some of the features you are familiar with today.
RA Environment
In order to avoid interrupting ongoing client development, OPTASY provides a free RA environment. For OPTASY Cloud Enterprise (ACE) clients, the RA environment is on a completely separate server to ensure that RA deployment and testing does not overburden customers’ dedicated testing environments. The redundant server allows security updates to be deployed into client environments as soon as they are available and readied for client testing.
RA Preferences
Last year, client-facing RA preferences were made available in your RA administrative settings. Clients can control RA automation on a per-subscription level. We plan to continue to refine these to work best with the script and the unique needs of clients.
Using APIs
OPTASY RA has utilized the internal OPTASY Cloud API in order to take advantage of the tools built by our fabulous cloud team. The API allows automation to read RA Preferences as well as other centralized subscription data that is used to create human-readable tickets and monitor progress. Optasy RA also takes advantage of the Zendesk API, and has contributed improvements back to Zendesk.
Drush and LiveDev
Since automated updates use Drush, it takes advantage of the Cloud Live Development feature. All updates take place on the RA Environment first, then are switched to Live Development for the update and code commits that will be deployed for the particular customer.
While drush typically does all updates at once, we ensure that each module update is a discrete git or svn commit. This allows much more efficient troubleshooting down the line, as load order can impact how the whole instance works due to custom code. The additional staging step, in the RA Environment, allows OPTASY to revert a single module update. It also allows customer development teams to cherry-pick the updates that best fit into their ongoing development process.
Drush Backend
OPTASY has also contributed back to the Drupal community by sponsoring development in Drush, eliminating a problem that interfered with automated updating.
RA clients will know that enabling the Update module is essential in order to get security updates. Drush 6 requires this module to access module status information without which Support teams have no way of knowing the status of a site’s modules. Asking clients to enable the module so we could scan always took extra time, often delayed the process.
In Drush 7 the Update module unnecessary. The fabulous-to-work-with F.L. Jonathan Araña Cruz developed the code, while Samuel Mortenson tested on it OPTASY servers. The result is the ‘Drush Backend’ which has been committed to the current dev version of Drush 7.
This work has streamlined initial versions of our automation, removing a significant amount of code that worked around Update cache issues (pm-enable update, pm-refresh, truncate cache_update, etc.). We reduced the total number of pm-updatecode calls. This also means that enabling the update module is no longer a requirement for RA subscriptions.
Automation now and in the future
Currently, OPTASY automation requires manual initiation via a queuing system. The OPTASY RA team always initiates the queue when a core security update is released. Otherwise, we initiate a periodic scan. Based on the improvements described here, RA customers can look forward to the following:
Daily automated scanning which will create a new branch every two weeks, so as not to flood you with new updates.
The ability to approve and automatically initiate all stages in the update process. This means that, unless you need troubleshooting from our team first, you can apply a security update without any required intervention by OPTASY.
The ability to specify bug-fix updates that can be included in a security update, or done independently. This will be a feature of RA Premier only.
Support for patching via Drush make files.
Finally, since Automation is under active development, this is a great time to let us know what features and capabilities you would like! Please feel free to comment below, I look forward to hearing your thoughts.
Adrian Ababei / Feb 24'2015
This tutorial covers writing a "Hello World" test for Drupal 7 using the SimpleTest framework that comes with Drupal core. Knowing how to write tests is an important skill, and being able to do so can help to increase the quality of your code, and save you hours of time clicking around your site making sure things still work after making changes.
For example, we've got a feature on our site that allows anyone to embed a copy of any of our free videos into another site. It's a great feature, but to be honest, it's also one that we forget about. It's hidden beneath the "share" link on video pages, and it's not something that any of us do very often. Whenever we make changes to our video player we're diligent about testing them on our site, but often times forget to check the embed codes. Testing them is also a bit of a tedious process because you need to find a free video, find the embed code, copy it into an HTML file on another site, and then test it. As such, we tend to break it from time to time without realizing we've done so until much later.
After having done this a couple of times though, we added test coverage for it. So now, whenever we make changes to any part of the site, one of the things that happens before that change is made live is we subject a copy of the site with the changes applied to a barrage of automated tests. If we break that embed code again (which we have), we'll know about it before it becomes a problem on the live site.
This is just one of the many useful things you can do with automated tests. Keep reading to learn how to write your first test.
After completing this tutorial you should be able to:
Create a new PHP class that defines a test
Provide Drupal with meta-data about your test
Run your test to see if it works
Background
This tutorial assumes that you are familiar with PHP and basic OOP concepts, and that you've written a Drupal module before and know how to get Drupal to recognize your module and allow it to be enabled.
Hello World
Start by creating a simple helloworld module directory in sites/all/modules/custom/helloworld/
Add a helloworld.info file with the following contents:
name = Hello World
description = An example module to demonstrate using SimpleTest
core = 7.x
Add a helloworld.module file with the following contents:
<?php
/**
* @file
* Hello World demonstrates the use of SimpleTest for Drupal 7.
*/
/**
* Implements hook_menu().
*/
function helloworld_menu() {
$items = array();
$items['helloworld'] = array(
'title' => 'Hello World',
'access callback' => TRUE,
'page callback' => 'helloworld_hello_page',
'type' => MENU_NORMAL_ITEM,
'menu' => 'navigation',
);
return $items;
}
/**
* Page callback for /helloworld.
*/
function helloworld_hello_page() {
return t('Hello World. Welcome to Drupal.');
}
In the Administration menu, go to Modules (admin/modules).
Enable the Hello World module.
In the navigation menu navigate to Hello World (helloworld), where you should now see the text "Hello World: Welcome to Drupal." displayed on the page.
This is what we're going to write a test for. Ensuring that when our module is enabled, a user can navigate to the page /helloworld and see this text. Let's get started.
Extending DrupalWebTestCase
Any module can optionally contain one or more test cases, and those test cases can either all be in a single file, or spread out among many files. The convention is for files that contain tests to end with the .test extension. And if you've only got one, to name it MYMODULE.test.
Start by creating a new file: helloworld/tests/helloworld.test, we will add the code that makes up our test case to this file.
All functional tests in Drupal should extend the DrupalWebTestCase class which will provide the utility functions used to drive the test browser, helper functions for interacting with a Drupal application, and all the assertions we will use to perform our actual tests.
Add the following to your helloworld.test file:
<?php
/**
* @file
* Tests for the hello world module.
*/
class HelloworldTests extends DrupalWebTestCase {
}
Add a getInfo() method to your HelloworldTests class. This method returns an array that provides meta-data about our test that the SimpleTest module can use when displaying our test in the UI. This method is required in order for your test to work.
/**
* Metadata about our test case.
*/
public static function getInfo() {
return array(
// The human readable name of the test case.
'name' => 'Hello World',
// A short description of the tests this case performs.
'description' => 'Tests for the Hello World module.',
// The group that this case belongs too, used for grouping tests together
// in the UI.
'group' => 'Hello World Group',
);
}
Add a setUp() method to HelloworldTests. This method is called when the system is preparing the environment for running our tests. It allows us to perform any setup steps required. In this case, we need to ensure that our module is enable during setup so that the page we want to test is available. We can do this by calling the parent classes's setUp() method and passing it an array of modules we want enabled.
/**
* Perform any setup tasks for our test case.
*/
public function setUp() {
parent::setUp(array('helloworld'));
}
Add a test*() method to our class. Each test case can have one or more methods whose names are prefixed with the string test. Each of these methods will be automatically called by the SimpleTest test runner, and should contain the various assertions required in order to demonstrate that this test is passing. This example will use the DrupalWebTestCase::drupalGet() method in order to tell the internal browser to navigate to the URL /helloworld. And then use the DrupalWebTestCase::assertText() method to verify that the string, "Hello World ...", exists somewhere in the HTML output of the page the internal browser is currently looking at.
public function testHelloWorld() {
// Navigate to /helloworld.
$this->drupalGet('helloworld');
// Verify that the text "Hello World ...", exists on the page.
$this->assertText('Hello World. Welcome to Drupal.', 'The page content is present.');
}
Finally, we need to tell Drupal about our new test. Update your helloworld.info file and add the following line so that after clearing the cache the registry will contain a reference to our new HelloworldTests class.
files[] = tests/helloworld.test
Run your tests
Clear the cache so Drupal locates our new test(s). Navigate to Configuration > Performance (admin/config/development/performance) in the Toolbar, and then clicking the "Clear all caches" button.
Navigate to Modules (admin/modules) in the Toolbar. Enable the Testing module in the Core section.
Navigate to Configuration > Testing (admin/config/development/testing).
Select the checkbox for the "Hello World" test to run all tests in this group, or alternately tip the drop down open and choose the individual test case you want to run.
Click the "Run tests" button.
A new page will open and display a progress bar while your tests run.
Once completed, you will be directed to a page with a table that shows the results of your tests.
Summary
In this tutorial we've written a Hello World test in order to demonstrate some of the fundamental concepts necessary for writing tests for Drupal with SimpleTest. Including, defining our HelloworldTests class in a .test file and making sure Drupal can find it by adding it to our module's .info file. Then providing meta-data about our tests for the SimpleTest UI, and any setup instructions necessary so that the environment in which our tests run is appropriate for our test case. Finally, we wrote a test*() method that used the internal SimpleTest browser to navigate to a page and verify that a string of text is present on that page.
I encourage you to explore SimpleTest through the Testing module in Drupal, and the concept of automated testing further as it provides numerous sanity and time saving benefits. Enjoy.
Source: https://goo.gl/MGzNMi
Adrian Ababei / Feb 21'2015