Composer for the Enterprise

For the second major version of TYPO3 Flow we integrated Composer, the upcoming de-facto standard for package management in PHP. I've become a big fan of its dependency management capabilities and especially the ability to pull almost any package from into my Flow applications. But enterprise projects need a little more than what comes with the starter kit.

Needs of Big Projects

While the average Joe Developer (me included) loves the ability to get started with a simple curl -sS | php and install all necessary dependencies of an application by executing composer update, this frequently causes nightmares in operations of bigger companies. In some environments and with certain security standards, you just want to have as much control as possible over what ends up on your production servers.

What we end up doing in these projects is to manually create a local fork of every single package involved and pull in new changes in defined iterations. For the application's composer manifest, we disable packagist lookups and only use our own Satis-generated repository.

But it is tedious to do this manually and especially in projects with dozens of developers and more than 50 packages involved, it can be hard to keep track of all dependencies and if they (still) make sense.

Composer Enterprise UI

With more and more big companies using composer, this just has to become a common requirement. Wouldn't it be nice to have a "Composer Enterprise UI" which you can install locally and let it display all packages and licenses you currently use in your projects? See at one glance which forked repositories are clean and which ones contain hotfixes?

Given at how much time IT departments spend on setting up and maintaining a custom structure, this should definitely be something a developer or shop could earn some money aside.

Talking about Composer over a beer with Jordi Boggiano

Signed Composer Packages

One topic which has been discussed in the past already is the demand for signed composer packages. From my experience what disturbs operations most (and what they get as their first impression about Composer) is the one-liner to let Composer install itself. What they ask for (and I think, rightly so) is a way to at least be sure that a given package is exactly in the state a certain developer released it. For this target group, pre-packaged (RPM, dpkg, ...), signed versions of Composer and signed composer packages would be a big relief and enabler.

How do you deploy Composer in enterprise projects? Which other ways can you imagine for getting more control over what gets installed?

Leave a reply