On the Delicious Brains site they've continued their series covering the deployment of WordPress applications with part four of the series. In this latest tutorial they walk you through the process to set up automated deployments of your WordPress site. In this case, they focus on the use of either the Buddy or DeployBot tools to help automate the process (rather than a roll-your-own solution).

In my last article, we looked at different methods of deploying a WordPress site using Git. We also looked at using an external CI service (such as Travis) to automatically trigger a deployment on your remote git repo.

In this article, we’re going to build on what we have looked at previously and consider some alternative hosted services that can help us with automated deployments for our WordPress site. There are many hosted services that we could use to deploy our WordPress site but we’re just going to look at a few of the bigger ones: Buddy and DeployBot. Unlike Travis, these services are dedicated to automated deployments and offer a lot more functionality and flexibility.

They start off by listing out some of the prerequisites you'll need for your environment including a WordPress site in a Git repository and a working install of Composer. They then walk you through the process to set up the automation in a similar way on each platform:

• Signing up for Buddy and adding a new project
• Setting up a new pipeline
• Configuring the tasks to run
• Transferring files
• Connecting it to the production environment

Once all of that it set up, you're ready to run the pipeline and test it out. Screenshots are included for each step of the way to make sure you're in the right place and are getting the settings correct.

On the AWS Developer blog they've posted about a new update in their PHP SDK functionality: a "changelog builder" that helps with automated changelog generation.

Starting with version 3.22.10 of the AWS SDK for PHP, released February 23, 2017, the Changelog Builder automatically processes all changelog entries. Each pull request is required to have a changelog JSON blob as part of the request. The system also calculates the next version for the SDK based on the type of the changes that are defined in the given changelog JSON blob.

The update simplifies the process of adding release notes to the CHANGELOG.md file for each pull request. Each merged pull request that was part of the release results in a new entry to the CHANGELOG.md file. The entry describes the change and provides the TAG number and release date.

This changelog is generated from a required JSON document for each pull request that provides information about the type of change, category and a brief description. They explain each of these items to give a little more context as to what they should contain along with a few examples.

This is something that could definitely help to improve other libraries as well, gathering the required change information from the contributor rather than having a project administrator have to sift through the PR to locate all changes.

On the Delicious Brains site Ian has written up a lengthy post sharing how they automate their acceptance testing for their PHP applications.

Have you ever had the joy of carrying out acceptance tests? For our team at Delicious Brains, testing our releases, in the past, has been one of the most dreaded tasks on the to-do list. We hold our plugins to a high quality standard so it’s a must but manual tests are brain-numbingly tedious and can take hours of expensive developer time.

Recently, we decided it was high-time to fix that. [...] Read on for more about how the automation of testing our plugins ahead of release is shaping up – including how we manually tested in the past and a look at some of the automated acceptance tests we’ve already implemented.

He starts by defining what acceptance testing is and how they're different from other types of testing. He then shows the manual method they were using to run their tests previously and what prompted the move towards automation. He talks about the tools that they use for their automated testing including Codeception and Docker. Configurations and scripts are included that make the automation work and some of the issues they came across during the move from manual to automated processes.

On the SitePoint.com site's "Web" category they're posted a tutorial showing off an interesting piece of software that helps make automated installs of CMS/frameworks easy: a simple bash script tool called Please.

If you’re a web developer, possibly one of your most boring and repetitive tasks is the configuration of the basic setup for every new project. Configuring your my-project.dev domain, creating the database, installing WordPress (or any other CMS/Framework) for the thousandth time: you already know how to do it. What if you could automate all of that?

Well, actually, you can. Please is a simple bash script that helps to automate the installations of many CMSs and Frameworks by configuring them automatically into your Vagrant box, adding a development domain name into your host file, and even a database if needed.

They start off by helping you get a Vagrant box up and running to use for the Please handling. You then clone the Please repository locally and can use the command line tool to set up the process for multiple CMS/framework types including WordPress, Laravel and React. There's also a section covering the creation of your own environment if you need something more custom. Please is currently in beta at the time of this post so be aware that there may still be issues that need resolving before it becomes stable.

The Full Stack Radio podcast has posted their latest episode interviewing Jason McCreary about the Laravel Shift service - a tool that helps you upgrade your Laravel applications more automatically and keep them up to date. It's a commercial service, though, and not an open source tool but there is a demo pull request you can see to get an idea of how it all works.

In this episode, Adam talks to Jason McCreary about building Shift, a tool that automates upgrading your application between framework versions.

Other topics mentioned in the episode also include PocketBracket, Laravel Cashier and the abstract syntax tree functionality (added to PHP in PHP 7.0). You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. Be sure to subscribe to their feed if you enjoy the show and want to catch future episodes as they're released.

Piotr Pasich has posted the second part of his series showing you how to set up an automated deployment process for an environment that includes an Elastic Beanstalk instance. In this part of the series be builds on the process created in part one and shows the setup and configuration of the Beanstalk instance.

In the previous part we set up a dedicated Symfony application on Docker virtual containers and prepared environments that may be transferred between developers during project cycle. The next step is to prepare the application for pushing into the cloud. There are many options available on the market – Heroku, DigitalOcean and, my favorite, AWS Elastic Beanstalk.

He walks you through the Amazon side of things first, getting the Beanstalk instance set up through the AWS control panel, selected from the AWS list of services. He goes through the options you'll need to configure to get the instance all set up and running including the resources to allocate and instance type (t1.medium is recommended). He then helps set up some of the necessary environment variables for configuration information and a bit of a hack to Symfony that lets you override local parameters with ones coming from the environment. Finally he configures the Beanstalk application and setting it up for automated deployment.

The SitePoint PHP blog has a tutorial posted talking about the automated testing of Drupal 8 modules, the components of the popular PHP-based content management system. In it author Daniel Sipos shows how to create a few tests for some functionality created in previous articles.

In this article we are going to look at automated testing in Drupal 8. More specifically, we are going to write a few integration tests for some of the business logic we wrote in the previous Sitepoint articles on Drupal 8 module development. [...] But before doing that, we will talk a bit about what kinds of tests we can write in Drupal 8 and how they actually work.

He makes use of the SimpleTest unit testing tool for PHP (versus something like PHPUnit) as it has become a standard for Drupal's own testing. He talks briefly about what SimpleTest is, how it integrates with Drupal and what kinds of tests already exist. He then gets into testing his own functionality - checking route information, that the page exists, the contents of the resulting page and the addition of a custom block plugin. He shows how to create these simple tests, extending the WebTestBase class, and checking each item on the list. He also includes an example of the resulting output of the successful testing, including time to execute and the detailed results of each test.

In a new post to the Engine Yard blog Nils Adermann provides an overview of using Composer with continuous integration, its role in the overall process and some good practices to follow in its use.

Continous Integration (CI) is the practice of continuously (and automatically) testing every change a developer makes. So automated tests become an integral part of the development process providing direct feedback on changes made. [...] Davey Shafik's article on Composer's Lock File explains the typical usage of composer install and update. The key takeaway is that developers should run composer update manually to explicitly update individual dependencies while composer install should be used in automated processes. This principle includes automated test environments.

He points out that using the lock file method reproduces the vendor directory exactly as it is in production and what it means for failures in your automated tests. He also talks about methods to improve the build performance to reduce time spent during the generation of the environment, including the use of the Composer cache data. He includes a few flags you can pass to Composer to reduce not only the libraries it installs but also how it fetches their contents.

The Squizlabs blog has an announcement about the release of the latest major version of the popular PHP_CodeSniffer tool for PHP - CodeSniffer v2.0. Among the updates in this latest release is a major one - the automated fixing of issues the tool finds.

Nineteen months ago, I started work on a project to allow PHP_CodeSniffer to fix the problems that it finds. Doing this required a lot of changes to the core classes, a lot of iteration and refactoring of the fixing and testing code, and an enormous amount of time and testing across many PHP projects to ensure I am confident enough to release something that actually modifies code. I could keep writing unit tests forever, but I've finally got to a point where I am happy to release this first version of the PHP Code Beautifier and Fixer (PHPCBF), for when you just can't be bothered fixing coding standard errors yourself.

The fixes are made possible through the newly introduced "PHP Code Beautifier and Fixer" (PHPCBF) tool. When the CodeSniffer tool is run against your code the PHPCBF kicks in too and tells you which of the issues can be automatically fixed. Additionally, you can now add custom code to your custom sniffer rules to enable this auto-fix functionality yourself. He also includes a list of the other updates in the release including:

• a new information report to show you how your code is written rather than if it conforms to a standard
• the ability to set command line arguments in ruleset.xml files
• the ability to create your own custom reporting classes and use them with PHP_CodeSniffer
• support for running on HHVM

You can find out more information about this release in the PEAR or GitHub changelogs.

On the PHPro.org Kevin Waterson has posted a guide to automated testing with Selenium2 and PHPUnit to create functional tests to check the resulting output of your application.

Selenium2 is a software testing framework for web applications. This tutorial focuses on automating browser testing using Selenium2.

The tutorial walks you through everything you'll need to get started testing with these tools, end-to-end:

• Selenium installation
• Writing a first test
• Setting up the Selenium environment
• Testing with multiple browsers
• Assertion types (and examples)
• Testing form actions and results