Devops for Growth

Phing is a PHP project build tool based on Apache Ant. A build system helps you to perform a group of actions using a single command. If you’re wondering why PHP needs a build tool, consider a work flow where you write code and unit tests on your local machine, and if the tests pass you upload the code to staging/production server and make any changes to the production database. Without a build file, you’ll need to go through each step manually. If you are doing continuous integration, you’ll be doing the same steps over and over again. It’s too easy to accidentally omit something in the process and end up with serious problem in production. Phing helps overcome such issues by automating tasks like running unit tests, applying database changes, deploying application code, etc. In this article I’ll show you some of the basics of working with Phing.

Suppose you have a web application that is installed on many hosts. Each installation may have a custom configuration, and the application is still in active development. You need an easy way to deploy new features and bug fixes to all of hosts.

In his previous article Using Phing, the PHP Build Tool, Shameer gave you a basic understanding of Phing. You learned how to read and write a build file and what its basic components are: project, targets, tasks, andproperties.

In this article I show you how to use this knowledge to write a boilerplate build file, one that can be customized and reused in your real-world applications. We’ll use Phing’s Subversion tasks to manage the repository and the FileSync extension to syncronize your local installation with a remote server.

By now I’m sure you’ve seen first-hand how Composer can help manage dependencies; I’ve grown quite fond of it myself, using it for the downloadable code samples on GitHub for our articles. Readers can peruse through just the relevant source code on GitHub if they like, and a quick git clone and composer install can get them the code and all the dependencies necessary to play with the code locally. But what about taking it to the next level?

You’ve created an awesome library, and now you’re ready to open source it and share it with the world. Hopefully someone else can benefit from your work, and maybe you’ll even receive a bug report or patch to make the library even better. But none of that can happen unless people can find it… and the modern way is increasingly becoming through Composer and Packagist.

In this article I’ll show you what information is needed in your composer.json file and how to list your library on Packagist so others can easily find it.

In this article I will introduce you to another great project, Composer. Maybe you’ve experienced the pain of working on a PHP application which uses third-party libraries and then trying to keep them and their dependencies up to date. If so, Composer can soothe your pain.

Composer gets you the libraries you want at the versions you need. And if those libraries use other libraries, it can install those and manage them as well. Dependency management can be a hassle-free experience using Composer.

"Whenever you publish a RESTful service, it’s likely that someone, somewhere will complain that you have violated one or more principles of REST—and they’re probably right! REST is quite an academic set of principles which doesn’t always lend itself well to business applications. To avoid criticism, simply market your service as an HTTP web service instead."

Following Alexander Cogneau’s introduction to dependency management with Composer, you now know that Composer is a resolver for managing external project dependencies and versioning constraints. But is that all it does? In this article I’ll show you how Composer can also be used as a basic build automation tool.