This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » eZ Publish 5 Platform » Updating eZ Publish with composer...

Updating eZ Publish with composer without downtime

Updating eZ Publish with composer without downtime

Thursday 30 October 2014 12:56:26 pm - 7 replies

I'm wondering what is considered to be best practice for the new procedures of updating eZ Publish in production. According the the release notes, step 3 is running composer update, but this will/can cause the site to fail (PHP errors) until composer is done loading, which is of course not acceptable in a production environment.

My initial idea would be to do something like creating a separate directory with an identical composer.json file, running composer update, and then moving/symlinking the updated vendor directory into prod. Another alternative could be to duplicate the entire installation, running composer update, and then changing DocumentRoot to the newly created (and updated) copy.

What are others currently doing? What does eZ consider to be best practice?

Thursday 06 November 2014 1:40:54 pm


Is this infact a problem you have encountered, or is it a theroretical problem?

I would imagine that if the cache is configured correctly that should prevent the users getting a fatal error, as the cache is cleared after composer in finished?

Thursday 06 November 2014 5:04:09 pm



yes as Håvard mentions in most cases of crash of prod after composer update is because of classes or interfaces changing, causing either the cache of these to be invalid, or the signature of lazy services cache to be invalid.

So you can somewhat avoid the crash by adding something like the following as last step:

rm -f ezpublish/cache/prod/*.php

However it won't be atomic, site will be down during update, and I'm not sure composer applies updates in one operation either, it seems to apply them one package at a time.

This is why I mentioned on twitter that the best practice for composer updates is staging them like:

  • dev:
    • Composer update
    • Version changes (composer.lock and potential fixes needed for the update uncovered by tests)
  • When you want to roll out accumulated changes in prod:
    • git update/clone + composer install on staging
    • Switch staging to prod when verified

So basically handle them like other changes to your project basically.

Micro updates

We do have micro updates from time to time, so what we can try to do in the future is make sure you can apply such micro updates (typically small fixes for fatal errors detected or security issues) safly in prod.

Modified on Thursday 06 November 2014 5:12:19 pm by André R

Friday 07 November 2014 7:06:32 am

This is indeed an actual problem, and not a theoretical one (otherwise it wouldn't make much sense discussing it, now would it).

Also, this is not a matter of correctly configured cache, but rather how composer performs its update process. The problem can easily be reproduced by applying patches, which we do regularly for our clients.

André: Since you mention that you're not sure how Composer applies updates: What leads you to belive that a composer install will not produce the same problems as a composer update? AFAIK composer install will still have to do same file changes as composer update, just without re-building dependencies (and I don't belive the dependency resolving is causing the problem).

I'll be happy to spend a few minutues discussing this with you over the phone when you're available to best explain the problem as I see it.

Friday 07 November 2014 12:32:03 pm

I was not trying to insult your cache cofiguration-skills or anything blunk.gif Emoticon The reason i asked was because I have not considered this to be a problem, and have never encountered it. So if this is a problem for you, I think this is something we also have to consider in our deployment processes.

My point with the cache was that while composer is updating your files the visitors will hit the http-cache / varnish-cache layer so the updates to your files will not affect the end-users before the cache is cleared (at least in most cases).

I may be way off here, and in that case i apologize happy.gif Emoticon

Friday 07 November 2014 1:03:12 pm

Best practice for having no downtime

> What leads you to believe that a composer install will not 
It does not do it better, I was implying a staging approach where you, for instance on staging area on prod server:

A. (Semi-)Manually do a completely clean git checkout and afterwards just do a composer install to get it ready to run. 

B. Alternative is a ci system which does this, and if tests passes makes a build of some sort and pushes to staging area.

In both cases you'll most likely have to verify that it works manually (or you can automate use of BDD to verify this if project uses this for user acceptance), and then reconfigure server to point to new folder and do a graceful httpd reload of configuration.

This btw further implies having everything you need to run in staging/prod in git, so for instance custom symfony environment, or prod actually being configured for production servers, and dev env for local dev.
I know this is advance stuff, but I really believe such an approach should be considered best practice, as opposed to applying patches directly on running prod setup, which has always been fragile at best.

Simpler alternative for smaller sites

However for small setups, where a little bit of downtime is acceptable, an approach like this might work: pre-composer-update; swap in a static web page with no-cache headers saying the site in being updated, come back in some minutes. and as last step in post-composer-update clear prod cache (before asset dump btw) and swap normal index.php back in.

See example here for the cache clearing:

Modified on Friday 07 November 2014 1:08:27 pm by André R

Monday 10 November 2014 11:16:20 am

This btw further implies having everything you need to run in staging/prod 

Are you implying versioning vendor/? That would of course solve this specific problem, but is also what we're trying to avoid (and in my mind not a best pratice).

Thursday 13 November 2014 5:32:02 pm

Not versioning vendor, just composer.lock (so make sure your .gitignore does not disallow this).

However from staging to prod it should be moved as is, ideally either swap server or change apache/nginx to instead point to new directory.

In eZ Publish Cloud it was a bit like this, introducing changes on staging url and staging directory using prod database, when putting it live switching config so staging gets promoted to prod, and prod remains as a rollback option. 

Modified on Thursday 13 November 2014 5:33:25 pm by André R


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from