Example module for Magento 2 in a different manner

Last fall, when Magento 2.0 was released, I wrote an article " Example module for Magento 2 ", in which I outlined one of the possible options for creating an environment for developing a module for the second version of Magento. More recently, updates have been released (v 2.0.1 and v 2.0.2), judging by which Magento developers move away from the deployment scheme using the Magento Composer Installer (with which Magento 1 deploys and deploys in my previous Magento 2.0.0 example). at least, simply changing the version of Magento from 2.0.0 to 2.0.1 led to the fact that what was being deployed did not want to work as a Magento application.

Under the cut - a new example of the deployment of the environment, adapted to the changing conditions.

Environment Tasks

The example contains scripts that provide the ability to:

1. Deploy the environment locally to develop the Magento2 module;
2. Deploy the environment on the Travis CI service to test the Magento2 module;

Summary

Description of the main directories and files flancer32 / sample_mage2_module :

• / deploy / : files used during deployment;
  
  • /composer_opts.json : options to add to the original composer.json Magento2 CE;
  • /composer_unset.json : list of keys of the original composer.json for deletion;
  • /merge_json.php : utility for merging Magento2 CE main JSON file and additional options;
• /dev/fw/FuncTestApp.php : implementation of a Magento2 application to run functional tests;
• / src / : sources of the Magento module itself;
• / test / : tests of the Magento module;
  
  • / functional / : functional tests of the module (with connection to the database);
  • / unit / : unit unit tests (the whole environment is mocked ');
• / work / : environment deployment directory for developing and testing the Magento module;
• /.travis.yml : test script for Travis CI;
• /composer.json : composer.json for the module under development ;
• /deploy.sh : deployment script;
• /deploy_cfg.sh.init : a template for setting local scan configuration parameters;
• /deploy_cfg.sh.travis : configuration options for deployment to Travis CI;

General deployment algorithm

• Using composer, we create a Magento2 CE project;
• We complete the composer.jsonproject CE with the instructions we need;
• Using composer we update the project;
• Run the installer of Magento itself to initialize the database;
• We expose the rights to directories and files;

Configuration

During deployment, the configuration is read from the file ./deploy_cfg.sh(it is not under version control for obvious reasons). The template for creating a local configuration file contains two types of parameters:

• settings of the magento-installer that starts from the command line in deploy.sh;
• rights to the file system of the Magento application (owner and group);

Additional options composer.json

In additional options, the following are added to the original Magento2 CE application:

• the module under development itself;
• instructions autoload-devfor using the implementation of the Magento2 application to run functional tests;
• lowering the minimum stability of composer packages from alphato dev;

Merging JSON configurations

In this example, the JSON configuration is read and further processed through a universal data container ( DataObject ), which, by and large, is unnecessary (see ./deploy/merge_json.php). However, I used this component to test connectivity when deploying additional dependencies that are used exclusively during deployment. In general, it can be thrown out if it interferes. In addition to edits, you merge_json.phpalso need to throw out the ./deploy.shline

echo "\nAdd initial dependencies to M2 CE project..."
composer require flancer32/php_data_object:dev-master

Before merging, the element minimum-stabilityin the original composer.jsonMagento2 CE is deleted (see file deploy/composer_unset.json), because otherwise, it will contain an array ['alpha', 'dev'] instead of a single value of 'dev' .

Application initialization

The Magento2 installer simply starts from deploy.sh:

php $M2_ROOT/bin/magento setup:install ...

Parameters available for initialization .

Module testing

$ cd work/vendor
$ php ./bin/phpunit -c flancer32/sample_mage2_module/test/unit/phpunit.dist.xml
$ php ./bin/phpunit -c flancer32/sample_mage2_module/test/functional/phpunit.dist.xml

Log Travis.

Additions

Version control

The development of the module takes place not in the catalog ./src, but in the catalog ./work/vendor/flancer32/sample_mage2_module/src. In order for the IDE to recognize all modules that are under development, you need to list them in the appropriate settings (for PhpStorm it is File / Settings / Version Control ).

Secret key for Magento Connect

To create a composer project

$ composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition $M2_ROOT

you need to create a pair of "keys" on the Magento Connect website . In case of manual deployment from the command line, composer saves these parameters in local settings, in case of deployment on Travis CI, you need to set these parameters in the environment variables $ M2_KEY_PUB & $ M2_KEY_PRIV or directly specify in .travis.yml:

  - composer config -g http-basic.repo.magento.com PUBLIC PRIVATE

Error: Maximum function nesting level of '100' reached

If this error occurs, add to php.ini:

xdebug.max_nesting_level=200

Phing

Phing does not offer anything to build Magento-projects (and it should not, in general). Therefore, like this - shell & composer.

"In another manner"

The phrase is taken from a very old cookbook that once caught my eye.

Responsibility Bounce

This material is just an example and cannot serve as the basis for the deployment of real applications without understanding it.