On the "Oh Dear!" blog they've written up a post sharing the Gitlab continuous integration pipeline they use for the deployment of the application. While, in their case, it's a Laravel-based application, the basics of it could be used for just about any PHP application with slight modifications.

We've been fairly public about the amount of testing we have for Oh Dear!. Freek has been showing bits and pieces on his Twitter to show the extent of that effort.

Having a huge test suite is nice, but integrating it into your development workflow is even better.

That's why we're releasing our Gitlab CI pipeline that is optimized for Laravel applications. It contains all the elements you'd expect: building (composer, yarn & webpack), database seeding, PHPUnit & copy/paste (mess) detectors & some basic security auditing of our 3rd party dependencies.

The post starts with an overview of their pipeline flow (including a graphic) showing the different stages and the steps involved in each. It then moves on to the setup of Gitlab's CI functionality using a local Gitlab runner to run the pipeline. It covers some of the issues around CPU load using Docker. Next it shares the configurations for the different stages in the flow and decisions they had to make around building assets, dependencies and caching.

Marcel Pociot has a recent post to his site showing how you can set up builds on the Travis-CI service for your Laravel Nova packages. Laravel Nova is the recently released product from the Laravel creators that provides an administrative dashboard.

Today Laravel announced that Laravel Nova can now be installed via composer. This works by providing your nova.laravel.com username and password as credentials for composer, as well as adding a custom Laravel Nova composer repository to your composer.json file.

[...] This is great news, as this does not only simplify updating Laravel Nova, but it also allows Nova tools/package developers to add continuous integration to their projects! But there is still a problem: we do not want to provide our Laravel Nova credentials in our open source repository. But how can we solve this?

Marcel then walks you through the process of using Travis-CI's encrypted environment variables to protect your credentials. He shows how to install the travis Ruby gem to get the travis command line tool, encrypt the values and update your Travis-CI configuration (.travis.yaml) to pull those into the build.

On the Trivago Tech blog they've shared some of their experience in continuous performance improvements in PHP applications and how the Blackfire.io service helped them get their best performance.

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 SitePoint PHP blog has posted a tutorial from author Daniel Berman showing you how to combine the ContinuousPHP service with Zend Server to create a continuous deployment system for your PHP applications.

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".