Tomas Votruba has a new post to his site sharing some of the ways you can get the most out of Travis-CI, the popular build service, for your PHP applications.

Travis CI is the most spread CI in checking open-source projects.

Do you want to know how to use it 3x faster? How to make Travis generate code for you? And how to make your tokens safe?

He breaks down his suggestions into a set of seven tips:

• Skip x-debug
• Deliver PR Checks Fast
• Use ENV vars
• Use Travis to do More Just Watching
• Rebuild your GitHub Pages Daily
• Stay Secure
• Make use of Composer Scripts

For each item in the list he includes an example of what's required, either a change in the Travis-CI configuration, code, or in the Composer configuration.

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 Laravel News site they've posted a tutorial showing you how to create multi-stage Docker builds for Laravel applications with a feature included in Docker 17.05.

Starting in Docker version 17.05 multi-stage builds are available to help you optimize Dockerfiles. Using multi-stage builds is a clean way to set up a Docker build pipeline that simplifies the requirements you need on your CI/build server to create a Docker image for your app.

If you’re not familiar with multi-stage builds, no worries! Let me summarize by saying that before multi-stage builds if you wanted to install composer dependencies and frontend dependencies during a docker build of your app, your Docker image would need to have the necessary dependencies such as Node.js installed and Composer PHP.

[...] By using multi-stage builds, you no longer need to install those dependencies or cram them all into your Dockerfile, thus bloating your final image size!

The tutorial then walks you through the multi-stage build approach using a new "demo" Laravel application as the base. In their example they show how to create the application, add it to a Git repository and set up the environment configurations. Next it includes the Dockerfiles required to create the different stages: installing Composer dependencies, installing Node dependencies and copying the application files and artifacts in to place.

Matt Sparks has posted the next tutorial in his "Building a PHP framework" series to his site today. In this latest article (part seven in the series) he focuses on building the container to handle dependencies.

Part 6 began our discussion of PHP containers. Today, I’ll be going into greater detail of the subject and, along with that, I’ll run down the work done so far on the Analyze container.

A huge debt of gratitude goes how to the folks behind the PHP League Container and others. I’ve learned a ton studying their code.

He then walks through the use of the container he created, Analyze/Container, to create and extract a Carbon instance. He then covers how the container is working behind the scenes to initialize the instance complete with dependencies (and optional arguments).

Matt Sparks has posted the latest tutorial in his "Building a PHP framework" series of posts. In this latest article he covers the use of test-driven development during the development of some of the first framework code.

In part 4 we laid the foundation for Analyze. Now it’s time to write the very first lines of code! [...] Essentially, test driven development is a process of writing tests before writing any code, then writing code that passes the tests. [...] If you’re new to TDD, this probably seems pretty weird. Stick with me.

He starts with a brief definition of what test-driven development (TDD) is and what tool he'll be using to create the tests. Next is a simple example of a test that creates a class instance (NumberAdder) and calls an add method on it. This fails because none of this exists yet, hence the "test first" part of TDD. He then goes back and creates the class and method and loads them so the test can use them.

On this site Matt Sparks has posted the first few parts of a series covering the creation of a custom framework. Why? Well, as he explains in part one of the series:

So with all of that being said, it begs the question: why on Earth would you want to do this?

The extremely short answer: I want to. The less short answer: A PHP framework encompasses many of the areas I want to learn more about.

The first four posts of the series are already on his site (with more to come):

• Part 1 – Why? Seriously, Why?
• Part 2 – What is a Web Framework?
• Part 3 – Time For Action
• Part 4 – The Foundation

Matt does a great job of laying out some of the fundamentals behind frameworks including structure, design patterns, and commonalities between frameworks. You can follow along with his progress on the project on the AnalyzePHP GitHub repositories.

The Three Devs and a Maybe podcast, with hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode with special guest Thijs Feryn talking about the build/provision/deploy pipeline "in the cloud".

In this weeks episode we are joined by Thijs Feryn to discuss his upcoming PHP UK conference talk. We start of the show highlighting what drew him to a Tech. evangelist role, bridging the gap between code/infrastructure and the ideas behind ‘Infrastructure as Code’. From here we move on to discuss system and infrastructure provisioning automation tools such Ansible and Terraform. This leads on to adding Packer into the mix, moving towards immutable infrastructure, testing these automation tools and how history has a way of repeating itself. Finally, we touch upon the philosophy behind DevOps, focusing on empathy and its core values CAMS.

You can listen to this latest episode either by using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

In a new post to his site Martin Hujer shows you that, with the help of the "script" ability in Composer, you may not need a build tool like Phing. The scripts functionality allows you to execute custom scripts as a part of the Composer workflow, enhancing the management functionality it already provides.

Phing is a great tool (I'm using it as well), but in this article, I want to show you that some projects may not need it. Composer contains a powerful feature called "Scripts", which can be used to create a simple build script.

In his example, he shows how to integrate a run of the PHP_CodeSniffer quality assurance tool as a part of your Composer configuration. This makes it possible to run a command like composer run-script phpcs and automatically run the checks. He then builds on this simple example and creates a more complex build script that still runs PHP_CodeSniffer but also executes PHPUnit tests. He post also shows how to run Composer in a command and how to document each command. There are also a few handy tips included around running Composer on Windows, listing the current scripts and executing custom callbacks to code.

For those Phar users out there Théo Fidry has written up a guide to help you create and deploy them securely with the help of a few tools and OpenSSL to sign the release to ensure integrity.

For those who are not familiar with it, PHAR (Php Archive) is analogous to the JAR file concept but for PHP. It allows you to package an application into a single file making it convenient to deploy or distribute.

[...] So what are PHARs useful for then? Well still the same thing: packaging applications. Although not many people may want to use this technique for web applications, it is still extremely useful for console applications.

The tutorial starts off by showing a few different methods for installing Phars and how to build them from your code. While they can be built manually, he suggests using the box project to help make it simpler. It also covers self-updating phars and shows how to update the box.json configuration to use a generated key to sign the release. Finally it covers a method for using Travis-CI to auto-build the phar and how to keep the OpenSSL key safe and out of the checked in code.

On the TopTal site they've posted a tutorial from author André Castelo showing you how to create a Laravel-based RESTful API with functionality that already exists in the framework.

With the rise of mobile development and JavaScript frameworks, using a RESTful API is the best option to build a single interface between your data and your client.

Laravel is a PHP framework developed with developer productivity in mind. [...] In this article, we’ll explore the ways you can build—and test—a robust API using Laravel with authentication. We’ll be using Laravel 5.4, and all of the code is available for reference on GitHub.

He starts off by talking about RESTful APIs, what actions the HTTP verbs represent and a note about consistency in URLs. He then starts in on the project setup, creating a new Laravel application and configuring the database for a Homestead environment. Next he creates the models and data seeders for articles and users for the API. Routes and controllers come next showing how to work with route model binding and response codes to correctly relay the status of the request back to the user. Following this he covers authentication on the API (using a token) and building out the endpoints for login, registration and logging out.

Finally he shows how to test the endpoints using some simple Laravel-enabled testing and PHPUnit. His tests check things like login error handling, missing data on registration and the correct flow on the logout process.