Adobe Commerce and the Community Contribution Model

Transcript

Hello, everyone. My name is Stanislav Idolov, and I’m Senior Software Engineer at Adobe Commerce. And today, I want to share with you some changes to community contribution model. So I would like to start first with challenges that we are faced by merchants and clients and how we are going to resolve them. So the first one is size of the monolith. It’s challenging because it’s growing over the years. So major development activities focused on the monolith and all the features, all the bug fixes delivered to the monolith. And code base is growing over the years and leads to complex and costly maintenance of the application. Also, one of the biggest challenges is upgrades complexity of the applications and instances because of highly customizable magenta environments. And number of fixes, large number of fixes delivered to each version can lead to complex upgrade process because a lot of extensions, a lot of processes and customization should be updated in order to get the newest magenta version. So let’s take a look on some interesting numbers. So we can see that over the last few minor releases, we are growing in our code base. It’s only Magento 2 repository without extensions like inventory, page builder, and so on. So it’s only monolith. And we see that we are adding around 10%, 15% of the code per each Magento major release. So one of the statements that code base is growing over the years. And the next one is that only for 2.4 release line, we already delivered more than 1,000 fixes for more than 1,000 GitHub issues. So a lot of issues fixed, a lot of changes delivered, a lot of functional areas are affected. So that’s one more point to complex delivery, complex new releases delivery to their merchants and customers. So before we go to the way how we are going to resolve these challenges like these questions, so I want to give a minute and talk a little bit about the tools that will help us to do that. I’m going to talk about quality patches tool. It was released more than a year ago. It was developed initially by Adobe Commerce support team. The main goal of this tool is to deliver the patches to the customers, to the merchants as soon as possible. And this tool is natively integrated to cloud environments and available for on-prem customers. So it’s pretty much easy to use it. It’s Composer packages that can be installed on any on-prem installation. And as I mentioned before, it’s available on cloud out of the box. Basically, it’s CLI tool that provides ability to review all the patches that can be applied to some particular instance and patches that already applied. Basically, manage patches for some particular instance. By using this tool, customers can get all the patches as soon as possible. And using the cloud environments, it’s pretty much easy to do that. You just need to specify some patches ID and deployment config, and they will be applied during the next deployment procedure. Let’s take a look on how patches are distributed via the quality patches tool. So first of all, once Adobe Commerce support is created a patch, it should be delivered to quality patches tool repository. And as a source for their publications, this repository, all the packages will be packaged and delivered to repo.magento.com and will be available for all the customers. And then using their Composer and just a few simple commands, this package can be installed on Magento instance, and customer can review and apply any patches they need to apply for their business scenarios. So let’s move on to contributions process. But first, before we are going to introduce any changes to talk about, any changes to contribution process, I want to go back and see what the process we have for years with direct code contributions. So on this schema, you can see the lifecycle of any fix delivered to the Magento. So first step. First step is when someone from the community reports an issue for Adobe Commerce or Magento Open Source. And then it’s issued charged and available for contributors to work on it and develop the fix, provide the solution. Once one of the developers picked their issue, worked on it, and created the pull request, this pull request will be tested by automatic tool using GitHub application, using all the automated tests that Magento Open Source provides. It’s a huge number of test suites. Then the next step, pull request should be assessed and reviewed by their maintainers team or by the NCHCOM team. So review procedure includes review according to Magento Backward Compatible guidelines, review according Magento Technical guidelines, and so on. So to guarantee that solution is stable and can be delivered to the Magento core. After the review, pull request should be quality assurance, should be provided for the pull request, and quality assurance is done by internal Adobe team. Once pull request passed QA, it should be delivered to the core. And currently, only one team responsible for the delivery of the community contributions is NCHCOM team. And this one team delivers all the community fixes to their Magento core main repository. Once all the fixes are delivered, they will be available for the Magento with the next Magento release. And merchants have to upgrade to get all the fixes and all the scenarios fixed. Just a few highlights of the model. So community fixes delivered to the main repository, delivered by internal team, and available with the next Magento open source or Adobe Commerce release. And all the delivery handled by internal teams or maintainer teams can only provide review, some quality assurance, but delivery handled exclusively by internal team. So finally, we got to the new contribution channel. So let’s talk briefly about it. On the schema, you can see the difference, what changes. We are introduced and how they will affect the flow. The first half will remain the same. So basically, it’s the same experience when someone in the community reports the issue. But the only difference is that issue should be reported for some particular version. Once issue is reported, some of the contributors can work on it, can pick it and fix it. And as a result, submit a pull request with a fix. As it was previously, all the fixes should be automatically tested. They’re tested by automated GitHub application with all the test speeds that we have on board. And then pull request should be reviewed according to all the guidelines and provided all the feedback to the contributor. And then there will be some changes. So first of all, we added the new field it called release notes. The main idea is to provide meaningful description for the fix because in scope of the patches, it’s really important to see what fix is going to change, what fixes should provide changes to some functionality, and so on. So release note is pretty much important there. So once release note is verified and approved, pull request can be merged by the maintainer. And it will be automatically converted to quality patch and delivered to the quality patches repository by automated tool. And then patch will be available via the quality patches tool next day. So we have scheduled publications for the quality patches tool. And all the fixes delivered today will be available in the quality patches package tomorrow. So basically, from the fix, from the pull request, will be available to merchants next day. So we are significantly reducing the time to market for the merchants and fixes. So I have added changes to the schema that I previously shared. So as you can see, as a source of the patches, community was added. And along with their Adobe Commerce support, can deliver the patches to quality patches tool repository. And the patches will be available to customers. And customers can apply them to the instance and easily use them. So basically, by providing ability for community to deliver patches, we are extending patches database. And all the fixes can be delivered and be available for the customers. Let’s talk about some benefits of the new contribution channels. So first of all, potentially, we can support any Magento version for patches delivery. Currently, we are supporting only 2.3.7 and 2.4.3 releases, its latest releases for both release lines. And we potentially can open more, let’s say, 2.4.2, 2.4.1, and so on. Also, community empowered to deliver and accept such fixes as community patches. Delivery process will be boosted in several times because we have a big community maintainers team. I believe we already have more than 40 community members there, and they’re there to help us with review and delivery such fixes. Also, critical fixes will be delivered basically next day. You don’t need to wait next release to get them. So once you need the fix, you can find it in existing database or submit a pull request and fix will be converted to Pouch and available for all next day. Also, as I mentioned before, it’s the QPT tool fully integrated to Magento Cloud with EC tools, and it’s pretty much easy to use it, just a matter of configuration of the deployment scripts and also Pouch will be applied automatically during the next deployment procedure. QPT tool packaging also automated. We have schedule for it, and on a daily basis, package is updated and delivered to the repo.magento.com. So from the drawbacks of this new approach, so the first one is no direct code contribution, so fixes will not be delivered to the Adobe commercial Magento open source. Core teams will pick most important issues. Basically, it’s high priority issues with priority P0, P1, and some of the tools, and they will be delivered to the core, saving the authorship of their fixes, so all commit history will be preserved. Also, we not guarantee multiple patches compatibility because all the patches tested individually, and it’s up to solution integrators to check the multiple patches compatibility and provide assurance that they will work together. Also, in this new contribution model, there is no place for general refactoring, cleanups, test coverage, because such fixes does not bring any functional improvements or any even functional changes, and I don’t think it’s a case when someone will apply fix for the log block to the production environment, so that’s why patches should be delivered only functional improvements and functional changes. So the main question is how I can deliver the patch to the QPT repository, so process pretty much straight forward, and it’s very similar to direct code delivery. Contributor just need to submit the pull request, but not to, let’s say, to the for develop branch. Pull request should be submitted to release branches. For example, 237 release or to foster release. Also, just make sure that all automated tests are passed to guarantee that these changes, provided changes will not break anything, and those are automated tests are passed. The next step is request review from the maintainer or from one of the HCOMP team members, and get a feedback on the changes and what changes is approved. They will be merged and automatically converted and delivered to quality patches to repository, and will be available next day. So as I said previously, there is no direct code contributions to the Magento core, but how community can deliver changes to their Magento core code. So the short answer is that yes, it’s possible. Community still can deliver changes to the Magento core in scope of joint development projects. So joint development projects, it’s basically project shared with the community. We had a good experience with them. We had projects like inventory, Adobe Stock integration, and so on. And project showed us that it’s pretty much good experience to share some backlog to work on some predefined backlog with the community, work along with the community, share some thoughts, share some architecture, and so on. So the main statements of the joint development projects are first one is every joint development project should have predefined backlog by Adobe Commerce product engineering and share it with their internal team and then with the community. So project always should consist two parts is internal team and community members, internal team who is responsible for review, delivery, some product questions, support, and so on. So basically internal team will support all the processes and all the product questions related to joint development project. And also every joint development project should be supported by Adobe Commerce teams like starting from the UX product questions and then like quality assurance and documentation. So from the beginning to end. So currently we are running two joint development project. First of them is page builder. This project aim to create some custom content, customize CMS pages and provide rich content. Contact to the customers that can be easily changed, that can be easily edited from there from the panel. The second project is Platform Health. The main goal of this project to update technology stack and libraries observe Magento open source and Adobe Commerce. Following the strategy, we will always use stable and secure software. And all the libraries will have all the new features, performance improvements, security updates, and so on. And the last one that I want to talk about today and probably like the main interesting part, the main important part, it’s community maintenance team who supports us for years, help us to deliver review changes to answer the questions. So they’re the most active community members. So the responsibilities like, and some permissions of the maintainers team. First of all, it’s code review. The maintainers team helping us to review all the code submissions and help provide the feedback for the contributors in order to provide some stable and reliable fixes. Also maintainers help us to try the backlog, to set the priorities for backlog and filter most important issues and move them forward and provide most important fixes first. Also they help us to provide verification for issue reports because each issue report should be verified, should be clarified steps to reproduce and so on. So it’s pretty much hard work to get the issue ready for development. Also maintainers team supports Magento open source on any events like contribution days, hackathons, have talks on different conferences and so on. So basically they participate on all public events related to Magento open source work. And with this new contribution model, we are extending maintainers permissions to provide ability to deliver community fixes. So maintainers has permissions to merge their pull requests to patches branches and basically delivers patches to QPT repository and provides a review for them. So that’s basically it from my side. I believe we have time for questions. Okay, there is no question. So thank you everyone for attending and just let us know if you have any questions or proposals. So have a good day.