Managing Magento/Composer/Deployment

Question

So, I'm enjoying using the hackathon Magento Composer installer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using DeployHQ, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.

My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.

When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).

So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?

Any answers would be greatly appreciated.

Answer 1

I have set up a structure at our agency that allows us to use Composer to deploy all our Magento sites. This might be a bit of overkill for the question you asked but here's a basic overview of the structure anyway:

Repository structure

Below is the folder structure of the 'parent' repository. It contains the composer JSON and lock files and other configuration required for deployment.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• All client-specific customisations are stored in a separate "customisations" module that gets installed using Composer
• The Magento core is included as a Git submodule (code/magento)
• A custom index.php and other folders like media and errors sit inside a public folder outside of the Magento root
• Environment specific files (local.xml, robots.txt, etc) get symlinked into the Magento root during the deployment process
• The vendor folder is excluded from Git, but the composer.lock file is included.

Deployment

• We deploy using Capsitrano which allows for multiple app servers and environments (staging/production)
• Capistrano builds the entire codebase on the server in a new folder, and then swaps the webroot symlink at the very end meaning there is no downtime for your website.
• Capistrano runs composer install during the build and deploys all modules into the Magento submodule.

This is still not a continuous integration setup but I find it works well for Magento sites. Feel free to send me a message if you'd like some more advice that's specific to your setup.

Answer 2

Another method is to use the magento hackathons copy deploy strategy, which kinda looks like this in your composer.json file:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

Using above method copies the installed files from vendor to the actual installation, allowing it to be committed in Git and deployed as per normal, without having to do any composer install.

I'm not a big fan of pulling from third-party repositories when you're about to do a live deployment, and being dependent on third-party repositories is kinda risky, unless you've got some kind of proxy cache for your network.

Read this article and it'll give you a different perspective: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Basically, NPM went down (sort of..) and everyone's build systems stopped working (for critical deployments!) because they were directly depending on NPM. (NPM is kinda like Packagist for Javascript, except that NPM actually hosts the file and Packagist just points to the Github repos of modules - correct me if I'm wrong)

edit: just red fschmengler's response.. This is an elaboration on his 1st approach

Answer 3

It is important to understand that Composer is not a deployment tool, but a development tool.

There are different approaches how to prepare a deployment with all dependencies:

• commit the vendor directory (or wherever composer installs the sources) to the project repository
• use a build server that runs composer install and creates an archive with the result, which you can deploy repeatable to different target systems
  • running composer install on the server and then switch symlinks as suggested by @jharrison.au is a variation of this one

That aside, I don't recommend using composer for every single module and only keep composer.json and composer.lock in the project repository. This is overdoing it and makes development needlessly complicated. It makes perfect sense for code that is reused over several projects but why would you put project specific code into separate repositories?

My current project structure looks like this (using the alternative composer installers by AOE):

• src contains all project specific modules. Composer also installs any other Magento modules here
• .modman links to src so that modman can handle the symlinking easily
• www is the webroot. Composer installs the Magento core here

This way I include external modules in the repository. If you prefer not to do so, adjust it like this:

• src contains all project specific modules. To include them in .modman so that modman creates symlinks, use modman link
• .modman is in .gitignore. Composer installs Magento modules here
• www is the webroot. Composer installs the Magento core here