Welcome to the first part of my series on deployment pipelines. If you missed the intro, check out the video where I describe a typical pipeline here.
First step of a deployment pipeline, is usually a series of tests. After a commit is made, the code is checked out from the source code repository and tested. Those are usually code style tests and unit tests.
Code style checks
Code style checks should be based on code quality expected within the team. Following an industry-wide standard is obviously a good choice, and given the wide variety of tools available, this is usually a fairly easy thing to check.
For PHP applications, tools that are commonly used are PHP Mess Detector and PHP CodeSniffer. There’s a big choice of other tools that can be used. I’d highly recommend following PSR-2 coding style all the time.
Example usage of PHP CodeSniffer for a code present within src
phpcs --extensions=php --standard=PSR2 -s src/
Those tests usually take seconds to run and can provide immediate feedback to the developer. It should also be possible for the developer to run them locally on their own machine - ideally as a pre-commit/pre-push hook, which will stop the commit if the checks are not passed. This way, running the tests within your deployment pipeline becomes simply a formality.
Unit tests
Once we establish that the code “looks” correct, every project should have a series of unit tests written. Remember, the purpose of unit tests is to make sure that autonomous parts of the code work as expected. Those can be run within your CI application, as they do not (cannot!) require access to external resources (like database, APIs, etc.) - all of those should be mocked within the tests, since you’re testing whether the code acts correctly given the pre-defined conditions.
The most common choice for unit tests for PHP applications is PHPUnit. It can be easily extended and integrations with most popular frameworks are available.
Important thing to remember here: we are talking about unit tests, not functional/behavioural/UI tests. We’re testing functions, methods, objects - not how their interact with each other. Other types of tests are usually a part of automated acceptance phase (part 3) of a deployment pipeline, since they usually require external resources, like a database, to run.
Unit tests, just like code style tests, need to be available for the developer to run before the commit, since it’s the easiest way to establish that the changes made did not break any existing functionality.
Most common CI tools, like Jenkins, have plugins which can interpret the output of the unit test tools and code coverage reports and provide easy to understand and comprehensive reports and graphs.
This, in essence, is a first part of a basic deployment pipeline. Feel free to comment with any questions. Check back next week for details on second part of the pipeline - the build. I’ll be focusing on building an application within AWS using AMIs.
