The Master Zend Framework series has posted the third part in their series covering deployment and development setups with Docker. In this latest articleMatthew Setter builds on the knowledge from the first and second parts of the series and shows how to deploy your environment to production.

In my search to learn how to use Docker as a complete solution to develop with, I've found a range of tutorials which discuss or walk through some part of the process.

Sadly, no one tutorial contains all the steps necessary to step you through containerizing an (existing) application through to deploying said application in a production environment. Given that, my aim in writing this tutorial is to show you how to do this.

The challenge in doing so, unfortunately, is that there's a lot to learn and absorb. [...] So this is going to be a lengthy post. But I've aimed to provide the most direct path to your first production deployment, as well as to structure it so that it's easy to work through or navigate to the specific part you need.

He starts off with a few prerequisites you'll need to complete the process - a DigitalOcean account, a Docker Hub account, Docker installed and working and a project to deploy. The rest of the post is broken down into a few sections to make it a bit more consumable:

Create & Build the Container

Store the Image in an Accessible Registry

Build a Deployment Configuration

Make the Deployment

For each step in the process all of the code, configurations an commands you'll need are included. In some places screenshots are also included to help you ensure you're on the right path.

On the Toptal.com site there's a new post from author Timofey Nevolin sharing hist list of Eight Rules for Effective Software Production to follow to help keep your development process flowing well based on some of his own experience.

During the course of my career, I’ve participated in multiple real life software projects and observed how things are done on all levels: decision making, practices adoption, team building, recruiting, skill distribution, etc. Obviously, different approaches yielded different results. Being an improvement-oriented type of person, I noticed and collected the most effective practices and best practical tricks to help me up in my work.

Learning from observation is a hard and lengthy way to do it. I would be extremely happy to pick this knowledge earlier from books instead. Unfortunately, I found none on the topic. So I decided to share my experience with other seekers of this kind of knowledge. Hopefully, it’ll save them few years of personal research.

His list of eight, targeted mainly at those needing a productivity boost, includes rules such as:

Understand the IT Mentality

Stop Wasting Time on Formal Time Estimation

Understand the Cost of Switching Tasks and Juggling Priorities

Use Architecture Reviews as a Way to Improve System Design

He finishes with one of the more important rules to follow: valuing those on the team and respecting them for what they bring to the table.

The TutsPlus.com site continues their "Build Your Startup with PHP" series of tutorials with the latest part of the series. In this most recent article they move into the hosting world and offer some tips and setup options for your production hosting.

In this tutorial, I'll explore choosing an ideal hosting platform for Meeting Planner and the initial configuration of our server. I'll be guiding you through the process as I migrate the pre-launch website to a better production environment for our upcoming alpha launch.

[...] As a reminder, all of the code for Meeting Planner is written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out our parallel series Programming With Yii2.

They start by looking at how to choose the right hosting company for your application and abilities. For their particular needs, they opted for managed hosting (like Rackspace or Digital Ocean). For the remainder of the tutorial, they show the setup with Digital Ocean and a simple "droplet" (virtual machine instance). They walk you through the setup of the droplet, the server configuration for hosting the application and packages to install. Then they check out and set up the code for the "Meeting Planner" application and, finally, update the DNS to point to the new server.

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

The problem here is that you almost cannot guarantee that you can replicate the production environment down to a single detail, it might have a slightly different underlying system, a slightly different network setup, even a different updates applied might mean it works for you, but not on production.

He starts the post by talking about the testing support already built into Symfony and the different parts tested by unit versus functional tests. He gets into some actual (functional) test examples, showing how to evaluate the response from an API request and where the major part of the overhead is - the database interaction. He takes the next step and looks at how to avoid "impure" functional testing and only then starts talking about switching between database types (SQLite vs MySQL) for better performance measurements. Finally, he gets to the topic of the article, running tests in production, and includes a "gotcha" to look out for (hint: don't hard-code IDs).

We discuss an idea for a web app and identify ways to turn it into a real-life product on the web.

We start with describing the domain and the problems the app should solve. Then we identify the personas that will interact with the app. We discuss the features features the app should have to fix the problems and we sort all the features by priority. Finally we talk about timeline, deliverables and next steps. The app we discuss will be launched to production by the next airing of this multi-part series of taking an idea to code.

Derick Rethans has posted another in his series covering the latest release of the Xdebug debugging tool for PHP, version 2.3. In this new articleDerick introduces the "shared secret" handling, a custom string that for the "XDEBUG_PROFILE" that can trigger the the profiler to start.

Xdebug's profiling and trace file capabilities can both be triggered by a cookie, GET or POST variable, as long as you have enabled xdebug.profiler_enable_trigger and/or xdebug.trace_enable_trigger. With these triggers enabled, basically anybody could initiate a profile run, or trace file, by simply sending the XDEBUG_PROFILE or XDEBUG_TRACE cookies with an HTTP request. Although you should not really run Xdebug in production, you can see that this is not an optimal solution. Xdebug 2.3 adds supports for shared secrets for the trace file and profiler triggers through the xdebug.trace_enable_trigger_value and xdebug.profiler_enable_trigger_value.

The SitePoint PHP blog has a new post from editor Bruno Skvorc with a list of eight Heroku add-ons for PHP applications. These add-ons (they call them "dynos") he lists help with things like logging, monitoring, working with CDNs and adding deploy hooks.

Heroku uses “dynos” as units of computing power which spin up your slugs. Dynos are lightweight, isolated containers for your apps which can execute any process type and can run and scale independently. There are two types of dyno – a web dyno, which handles web requests letting you serve more users as you increase your web dyno power, and worker dynos, which handle everything else like running your code and processing background tasks.

Bruno walks you through getting a sample Laravel-based application up and running on Heroku's PHP functionality and provides a list of add-ons from the Marketplace to get you started. His list includes:

If you've been around the PHP community for any length of time, there's a pretty good chance you've seen the language's "mascot" floating around - the elePHPant. This mascot has even been made into a stuffed toy in various colors - blue, red, yellow and now thanks to [php]architect, orange.

Ready to add, or start, your collection of elePHPants? We started a KickStarter campaign to produce a run of Orange elephants. [...] There’s much more information over at our Kickstarter project. The campaign is set to a short timeframe and ends on February 3rd as we need to get our production order placed as soon as possible. So get over there and claim your orange elePHPant before time runs out!

The Kickstarter campaign, originally fully funded at $1,000 USD has now reached an amazing $16,000+ USD. There are still plenty of spots left open if you want to pledge and get in on this purchase. Options range from a simple $1 USD for support all the way out to a $250 USD option that gets you a "zoo" (ten small elePHPants and one large elePHPant).