should be done accordingly to the checklist / instructions below.
For modules with a reliable codebase source (like modules publicly available on Github/Bitbucket) we don’t create our parallel repository in Bitbucket but always source modules from original repository directly into our composer based projects.
For modules only available as code archives we do create our own repository in Bitbucket (meaning that we run the whole flow of “making module installable by AJA”)
Note: modules usually have dependencies. In case dependencies are not available from reliable source, we create their repos in our Bitbucket (and make them installable via AJA) too.
Creating a module page (example: https://confluence.vaimo.com/x/SJn4AQ) in corresponding section in our Confluence.
Requirements for the module page:
- should have module name, vendor name (Vaimo or some other company) and info on where to find module
- should indicate module’s price payed and terms of further usage (e.g. should we contact vendor and pay once again to reuse in another project)
- should contain current module’s version (or versions if we have a couple of them already)
- should carefully outline module dependencies and state if they are available for Vaimo or not (and how to get them if they are not automatically installed)
- should clearly describe module’s functionality (here either fresh module documentation should be written or an existing module documentation should be adopted)
- should describe module compatibility with versions of Magento, versions of PHP etc.
- should have information on module’s unit tests (if any)
- should contain module maintainer’s name (if any) or at least names of people Vaimoers can reach out to having questions regarding the module
- should indicate issues, concerns (or even TODO’s if critical) gotten during the module check
Static code analysis
Add module code and code of all module dependencies to scrutinizer-ci.com and run analysis. Document the score by Scrutinizer and briefly describe analysis result on module documentation page in our Confluence.
Some links to help with understanding what Scrutinizer is and how to use it:
- Adding Magento2 EE project to Scrutinizer
- Start Automated Code Analysis for Your Project
- Code Quality Check using Scrutinizer
Manual code review
Developer carefully checks the code evaluating:
- patterns / anti-patters used
- whether code is written using Magento best practices
- TODO: continue on this list of manual code review and it’s goals
Installation and QA manual testing
Module is installed on a clean Vaimo Magento build and together with documentation (see prev. section) provided to a QA for manual testing.
Results of QA testing should be outlined on the module’s page in Confluence (the same page which contains module documentation).
Installation and running Unit tests
Modules with unit tests is installed on a clean Vaimo Magento build and unit tests run. Results should be documented on module’s page in Confluence.
Regarding Static code analysis. I first put CodeSniffer there together with PhpMetrics.
But CodeSniffer is bad for evaluation as it doesn’t provide a unified score. There’s no sense in getting tons of “things to fix” at this evaluation phase. There’re only need in understanding if code is good or bad. And how good / how bad.
Second thing – PhpMetrics. Idea of using them was based on easy installation of the tool and scoring model of PhpMetrics (see this image) having
- accessibility for new developers
- simplicity of algorithms
- volume etc.
Unfortunately current “upgraded” version of PhpMetrics doesn’t have this scoring model anymore. What it provides instead right now is useless for current code evaluation purposes (I updated our PhpMetrics page too).
Scrutinizer seems to be the best option here as it’s super easy to use (SaaS with intuitive interface) and it provides a simple numeric score + badge which you can inject into the module’s page.
What do you think?