Magento module development with application deployment through Magento Composer

Introduction

The article describes the experience of deploying a development version of Magento-application using Magento Composer. The structure of a typical Magento application in our company:

• Magento
• Third-party modules used in the project
• Modules developed by us, used in more than one of our projects
• A module we are developing that contains functionality specifically for this project
• Theme for a specific project

The development version of the Magento application should allow us to develop the code of our modules and upload changes to the corresponding repositories, allowing the code of common modules to migrate between projects.

In connection with the start of a new project for the deployment of Magento applications, we decided to try Magento Composer . At the moment, we have the code for each project stored in its SVN repository, plus in a separate one, all the modules we develop (both general and specialized):

• Magento installation and third-party modules for project 01;
• Magento installation and third-party modules for project 02;
• ...
• our modules;

To use Magento Composer, the project was divided into the following parts (each in its own git repository):

• z_mage_composer_prj_01_full : deployment scripts for the entire project, theme, third-party modules not available through Magento Composer;
• z_mage_composer_mod_01 : the first module on which the project depends;
• z_mage_composer_mod_02 : the second module on which the project depends;

Environment preparation

In the process of experiments, it turned out that Windows is not suitable for deploying a development version of the application. Magento Composer offers two deployment strategies: copy (copying module files to the structure of the Magento application) and symlink (creating symbolic links to module files in the structure of the Magento application). The development version can only use symbolic links, because you need to keep the source code of the modules compactly in your folders in the vendor directory(the place where Composer places the files of the modules used). Symbolic links in Windows do not work out well enough - changes made to the original file are reflected by the link with a long delay (both in the PhpStorm IDE and on the web server itself). Plus (or rather, minus) - the approach used by Magento to find templates and description of layouts ( app / design / frontend / [default] / [default] directory) does not work on Windows (you need to modify Mage_Core_Model_Design_Package :: validateFile and Mage_Core_Block_Template :: fetchView), but this is more of a problem at the PHP level than at the Magento level. In general, after long attempts to deploy the development version of Windows, it was recognized as not the most convenient development option (although possible), so Linux remained for further continuation (Ubuntu 14.04).

There were no problems with installing Composer itself:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

Everything else (including installing Magento Composer) is done through setting up the project in composer.json.

composer.json

I bring only the settings that are significant in this context (the full version of composer.json ):

{
  ...
  "type": "magento-module",
  ...
  "require": {
    "magento-hackathon/magento-composer-installer": "*",
    "magento-hackathon/composer-command-integrator": "*@dev",
    "composer/composer": "*@alpha",
    "magento/core": "1.9.1.0",
    "magento-hackathon/hackathon_magemonitoring": "*",
    "connect20/nmmlm_log": "*",
    "praxigento/z_mage_composer_mod_01": "*@dev",
    "praxigento/z_mage_composer_mod_02": "*@dev"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "http://packages.firegento.com"
    },
    {
      "type": "vcs",
      "url": "https://github.com/praxigento/z_mage_composer_mod_01"
    },
    {
      "type": "vcs",
      "url": "https://github.com/praxigento/z_mage_composer_mod_02"
    }
  ],
  "extra": {
    "magento-root-dir": "mage",
    "magento-deploystrategy": "symlink",
    "auto-append-gitignore": true
  }
}

Require section

• magento-hackathon / magento-composer-installer : directly Magento Composer itself;
• magento-hackathon / composer-command-integrator : module for incremental updating of Magento modules during development (to create symbolic links to new files when adding files in the module);
• composer / composer : an exact alpha classifier is needed for composer-command-integrator to work;
• magento / core : the actual Magento code;
• magento-hackathon / hackathon_magemonitoring : a third-party module loaded from the Magento Composer repository (for example);
• connect20 / nmmlm_log : module freely available through Magento Connect (fetch from store Magento Connect to store Magento Composer)
• praxigento / z_mage_composer_mod_01 : one of our own module, whose code is in the github repository;
• praxigento / z_mage_composer_mod_02 : our second own module, the code of which is also in the github repository;

Repositories section

We close composer to the repository of Magento-modules:

    {
      "type": "composer",
      "url": "http://packages.firegento.com"
    }

... and specify the addresses of the repositories where our own modules are used in the project:

    {
      "type": "vcs",
      "url": "https://github.com/praxigento/z_mage_composer_mod_01"
    },
    {
      "type": "vcs",
      "url": "https://github.com/praxigento/z_mage_composer_mod_02"
    }

Extra section

• magento-root-dir : set the directory in which we will deploy Magento ( mage );
• magento-deploystrategy : set deployment strategy - symlink for development version;
• auto-append-gitignore : indicate that the files of the Magento modules that will be linked to the Magento application (the mage directory ) should be added to the mage / .gitignore file in order to get out of version control;

Project deployment

$ git clone git@github.com:praxigento/z_mage_composer_prj_01_full.git full
$ cd full
$ composer install

As a result of the project’s deployment, the source codes of our modules fall into the vendor directory (screenshots were taken from a local Windows station)

... link to the mage Magento directory :

... themes and modules that are not installed through Magento Composer are poured directly into the mage directory :

Mount points of various source code repositories:


There are two .gitignore files in the project :

• .gitignore : manually populated by developers;
• mage / .gitignore : populated automatically by Magento Composer when deploying Magento itself and modules;

Features of the development of modules

All module files must be registered in the mapping of modman's registry :

path/to/file/in/module path/to/file/in/magento

You can create a modman file with this command :

for i in `find . -type f | grep -v \.git | grep -v "^.$" | grep -v "modman" | sed 's/\.\///'`; do echo ${i} ${i}; done > modman

After adding a new file to the module, you need to run command integrator so that the new files are linked to the Magento root directory:

$ ./vendor/bin/composerCommandIntegrator.php magento-module-deploy

In order for the module to be deployed in a form suitable for working with the version control system, you must specify in the composer.json file of the module:

{
  "name": "praxigento/z_mage_composer_mod_01",
  ...
  "config": {
    "preferred-install": "source"
  }
}

When editing a file by reference in the IDE (PhpStorm), there is a discrepancy between the "apparent" ( mage / app / code / community / Vendor / Ext / Model / Observer.php ) and the "available" (vendor / company / module / app / code / community / Vendor / Ext / Model / Observer.php) - editing the "available" version with a delay is reflected in the "apparent" (and the Refresh function in PhpStorm is not provided for this case - you have to add a character to the "apparent" version, press Ctrl + S and do the update via “Load File System Changes”). Breakpoints for debugging can be installed in both versions of the file, but step-by-step tracing is done only according to the “existing” one (sometimes the stop appears as if from scratch - in the “apparent” version there is a breakpoint on the corresponding line).

Additionally

" Using various VCS repositories in PhpStorm "