Our mission is to provide the user with the ideal hotel at the lowest rate. Our backend consists of several services written in different languages. To succeed at this goal we do complex tasks in our main application developed in PHP. While doing this we need to keep the website as fast as possible.

We started to look for some tool that could help us identify performance issues in our code base. We evaluated Blackfire and decided that it was a good fit for our use case.

The article starts by answering the question of "why Blackfire?" and continues on, showing how they integrated it with their workflow. They use the SaltStack tooling to set up servers and configure them so it was just a matter of integrating the Blackfire agent and probe extension via that. They include an overall diagram of how it fits into the architecture and how they worked around the lack of Bitbucket server support. The post finishes with some examples of performance metrics from before and after the optimizations from their results stored in InfluxDB.

On his site James Wade has posted the first part of a tutorial showing you how to get your PHP application set up for continuous integration with Jenkins and Docker. In this part of the series he focuses on the setup of the technology involved, linking to every tool you'll need.

I’ve been developing in PHP now for longer than I haven’t. Going from using PHP as a hammer to a nail, using it to allow forms to send emails, to operating popular open source projects, to leading a team of developers in a business enterprise. One key advice I learned from running an open source project on the SourceForge platform was “release early, release often”.

This is a mantra that I’ve always tried to stick to and its always brought me good results. As I get into more and more complex projects, both in code structure and politically, I find myself turning to tools to solve problems. One of those tools is Continuous Integration.

He talks about coding styles and IDE automation that can help make you code better and cleaner but points out that there's more to be done than just that. He briefly covers the idea behind continuous integration and why he chose Jenkins for his environment. He then gets into the setup process, showing how to get tools like PHPUnit, phploc, phpmd and phpcpd installed. He includes the dockerfile to set up this environment and the bash script that handles the setup process. He finishes the post with a brief look at the automation that happens thanks to the Jenkinsfile configuration and what's coming in part two of the series.

As you write your PHP code, you'll need to verify that everything is working as expected and that the code follows all style and formatting requirements. In this list from the SitePoint PHP blog they give you a list of eight tools you can use to ensure all of these criteria are met.

For shipping quality code, we must have testing in mind while coding (if not doing TDD). However, with the wide range of PHP testing tools out there, it’s hard to make a choice! Exploring PHP is a fun adventure (premium course on that here!) but it’s hard to assemble a toolbelt that’s not too heavy to wear to work!

This popular article will highlight the most popular testing tools and has been updated to reflect the state of QA tools in 2017.

Included in their list are tools like:

PHPUnit

Cucumber

Selenium

Kahlan

php_testability

The post ends with a brief look at continuous integration and how they can help execute these tools automatically when code changes or before production builds are deployed, taking most of the burden off of developers to remember.

In a post to his site Rob Allen shares a basic setup for using Circle CI with a PHP project for continuous integration. Circle CI provides the resources to build your project and perform tasks such as run unit tests or even deploy the resulting code to the production environment.

For a new client project, I've decided to use CircleCI to run my tests every time I push to GitHub. This turned out to be quite easy; this is how I did it.

He shares the contents of his .circleci/config.yml configuration file creating a Docker environment each time the build is executed, installing the required software, executing Composer install and running PHPCS and PHPUnit tests. He shares an example of the output from a build and how he hooked in Slack to receive notifications when the builds were complete (and pass/fail status).

On the SitePoint PHP blog there's a new post that gives you a crash course in using Semaphore, a "continuous delivery pipeline" service, and how to use it to deploy your PHP applications.

Understanding continuous delivery, a now already long-standing buzzword, is not a problem, but implementing it in the right way has been a challenge for quite a few of us, and one we’ll discuss in this post.

[...] In this article, we will cover the process of deploying a Laravel application on a Digital Ocean server through a continuous delivery pipeline using Semaphore. The source code for the application is present on Github.

They walk you through each step of the way (complete with screenshots) to:

Create a Semaphore account, linking it to GitHub

Creating a new Project

Setting up the plan for the deployment

Performing the first build

Parallelizing the builds

With the project all set up the tutorial then starts on the continuous deployment changes, adding in a "Deployment" step and making a first push.

On the SitePoint PHP blog there's a tutorial posted helping you get started with Sismo, a simple component that can help you with the continuous testing of your PHP applications. Sismo is a project from SensioLabs, the same group behind Symfony and Twig (and several other popular tools).

The PHP community started to adopt the testing culture relatively recently. Despite there being some debates on how to achieve this, nobody can argue the importance of having your code fully covered by tests. In this article, we’re going to explore a tool that will help you in a major part of the testing culture called continuous testing.

Sismo is a small component which you can easily integrate with your projects to make the process of continuous testing easier. Sismo's main focus is to run your tests and send you status notifications.

They help you get the tool installed (either from GitHub or directly) and configure your project with a simple PHP file. They also include instructions on how to execute the tests for the project and an example of the resulting output. The tutorial then shows how to set up a project using the remote repository handling, setting up notifiers for failures, storing the build information and using it in a git hook.

The continuous delivery approach aims at making the process of continuously deploying code to production error-free, or at least less error-prone, using automated tasks, tests, builds and deployments. Minimize risk and downtime, maximize quality and value. That’s the motto.

However, this process is not always straightforward, to say the least. Often enough, the continuous delivery tools chosen for implementing continuous integration and deployment are hard to figure out and use, and are usually time consuming and expensive. The bigger the application, the bigger the challenge. This article introduces an interesting new approach to dealing with this challenge by demonstrating a continuous delivery process using continuousphp and Zend Server.

They briefly walk you through some of the prerequisites including an installation of Zend Server already set up and waiting. He also provides a skeleton application you can use if you just want to test it out first. From there he goes through the steps in the process:

Setting up your repository (on ContinuousPHP)

Creating a new deployment pipeline

Configuring build and test settings

Packaging and deploying your app

All along the way he's included screenshots of the ContinuousPHP interface so you can be sure you're still on the right track. He ends the post with a few extra "goodies" linking directly to the ContinuousPHP and Zend server documentation among other useful links.

On the Dutch Web Alliance site today Stefan Koopmanschap makes a recommendation about something that can help make you a better developer and grow in your knowledge: continuous learning.

Education. In a fast-changing environment such as the web industry, education is the single most important thing to survive. [...] We need to stay up-to-date on those subjects to ensure we keep doing the right things in the right ways. It is impossible to keep your knowledge on everything up-to-date and still have enough time to work, so we need to make choices on which topics to focus on and how to learn. In this article I’ll go into some strategies and some ways to keep the knowledge of you and your team current.

He covers lots of good topics, including a brief summary of each point as he goes (including deciding if you want to be a generalist or specialist). He goes through several places to gain this kind of knowledge including:

Knowledge sessions

Trainings

Code kata

Code reviews

Mentoring

...and these are just some of the places. He also points out the value of learning something on your own every day, trying out something outside of your usual solutions and remembering that "no two challenges are the same".

In this post to his siteMarc Morera talks about Composer dependencies and an issue that can come up with two things: having a large number of dependencies and minimum PHP version requirements (and when they change).

Any final project needs a lot of dependencies, and even if your composer.json file is small, you may need a dependency with a lot of dependencies. [...] Computing the real dependencies in my environment seems a great solution, right? I run composer update in my computer, I update the composer.lock version in the repository, and then I only need to do composer install. What I reduce here is the computing time of all recursive dependencies from 20+ minutes to less than 5 minutes. [...] Why this is a bad solution?

He explains that some projects will change the PHP version requirement in a minor version, potentially causing your build to break on other versions without you changing anything. He points out that there's "no good solution" he sees but does recommend good upkeep of your composer.json as a composer update is the best course of action. He also makes recommendations to the library developers about keeping requirements scope as wide as possible and only defining specifics when the project is finalized.

Debugging Behat scenarios while using Mink to simulate the user is not always an easy job. Especially, if they are run on Continuous Integration server. That is why I came up with an idea to make it easier. During repairing our javascript test suite on Sylius everything went as bad as it could go. There were many errors that happened on Travis, but I was not able to reproduce them locally. [...] MinkDebugExtension was written to speed up that boring and tiring part of debugging on CI server. It consists of two parts: Behat extension and useful scripts.

The extension fires after failed steps and makes a log of the issue with content needed to recreate the issue (including possible screenshots). He also describes the scripts that come with it to help you browse through the results, uploading the resulting logs and screenshots to a place for public consumption.