As a company, we at Amasty believe that transparency and collaboration are essential to building strong relationships with our customers. That's why we're excited to announce that we're sharing our pipelines with our customers.
By sharing our pipelines, we aim to provide you with a behind-the-scenes look at our processes, so you can understand how we create our products and services. We believe that this will help us build trust with you, as you’ll have a better understanding of our values and quality standards, and be ready for future Magento releases.
But sharing our pipelines isn't just about transparency – it's also about collaboration. We want our customers to be involved in the product development process, so we can gain valuable insights and feedback that can help us improve our products.
We believe that by working together, we can create even better products that meet the needs of our customers. Let's get on with it!
Subscribe to our blog newsletter and get the latest e-commerce trends, our extensions updates, and news in your inbox
Maximize the potential of your website with our Magento 2 extensions! Get set to revolutionize your online presence and skyrocket your success.
Amasty pipelines
The first thing you can find in our GitHub is the repository that contains the tools we use to organize the process of continuous integration within the company. This branch is the main one and contains the documentation on our tools. For convenience, all tools are divided into blocks stored in separate repositories.
Let's dig a little deeper into the GitLab CI/CD pipeline that automates the software delivery process for a Magento e-commerce extension.
The pipeline has several stages, including merge-master, quality-check, testing, and magento-deploy-test. Within each stage, multiple jobs are executed in parallel. The jobs include quality checks, unit and integration tests, and deployment testing.
The first stage is the merge-master stage (This stage is generally launched only when we are preparing a product for release), which includes two jobs: composer.json and i18n. The composer.json job checks and validates composer.json file of our extension to ensure it can be installed via the composer package manager without any issue. The i18n job executes the Magento translation tool to extract, validate, and compile translation dictionaries for the application.
The second stage is the quality-check stage, which includes several jobs that perform various quality checks and security analysis of the codebase.
The jobs include:
- SonarQube, which performs a code analysis and measures code quality;
- Secret Detection, which detects potential secrets (such as API keys or passwords) in the code;
- SAST: nodejs scan, which performs a static analysis of the JavaScript code for security vulnerabilities;
- SAST: phpcs security audit, which scans the code using the PHPCS security audit tool;
- SAST: semgrep, which uses the semantic code analysis tool Semgrep to detect security issues;
- PHPCS: Custom rulset, which performs a code check based on our custom PHPCS rulesets;
- PHPCS: Magento marketplace rulset, which checks the code against the Magento Marketplace coding standards;
- PHPStan, which performs static analysis of the code; and
PHPmd, which checks the code for potential code smells and other issues.
The third stage is the testing stage, which includes three jobs: Unit Tests, Integration Tests, and Api Tests. These jobs run PHPUnit to execute the unit, integration, and API tests for the codebase. The Integration Tests and Api Tests jobs use MariaDB and Elasticsearch as services.
The fourth stage is the magento-deploy-test. This stage consists of jobs that deploy the Magento application to different environments (Community/Commerce editions and the latest versions from 2.3 and 2.4 branches) and run Smoke tests based on MFTF to verify that the deployment was successful.
The fifth and final stage is the master-only stage, which includes one job: Create tag. This job creates a Git tag that means our extension is ready to be delivered to our customers.
The pipeline uses several configuration files (located in the /src directory) that define the services and jobs used. The configuration files are included in the pipeline using the include statement. Pipeline jobs also use several templates (defined in the .tags, .rule, .image, .composer, .phpcs, .sast, .static, .phpunit, .magento, .services, and .security files) to define common configurations for the jobs. The pipeline uses GitLab's extends keyword to extend the jobs from the templates. This solution allowed us to combine any configuration to create a new job and to be able to change any part of a job without it full rewrite.
In the above pipeline, there’s a smoke tests stage as well, which is a set of automated tests that quickly verify that the application is functioning as expected after a new version is built and deployed. This stage includes basic tests like verifying that the application launches, that the main pages load and that critical functionalities work as expected. If the smoke tests fail, it is an indication that the build is not stable enough for further testing, and it will be halted so that the development team can address the issues before proceeding.
Amasty code standards
What about our company's coding standards? This is where you can find our custom code standards which we run with severity 1. The following code will define a set of rules for the "Amasty" coding standard for Magento 2:
Overall, it defines a customized set of coding standards for Magento 2 that extend the default Magento 2 coding standard, while also adding additional rules for checking the line length and indentation of code blocks.
To sum up
In conclusion, having a shared pipeline in place can bring many benefits to a development team. It can ensure that code is consistently built, tested, and deployed, while also providing visibility and traceability into the software development process.
By sharing our pipelines and discussing the various stages and tools that we use, we hope to provide some insights and ideas for other teams looking to implement their shared pipelines. Ultimately, the key to success is to continually iterate and improve the pipeline to meet the specific needs of the team and the project at hand.
