Quality patch tool

Transcript

The quality patch tool is a command line utility for Adobe Commerce and Magento open source. It allows you to do a few things such as view general information about the latest quality patches, apply quality patches to your installation and even revert them. These are get patches and they have been proven to fix an associated issue. The best thing to do is once you’re aware of a potential patch is to review it and closely with your architect or dev lead, ensure that the intent of the patch seems to line up with your issue. Typically, you’re going to learn about a quality patch that could be a solution by either using search results or by creating a support ticket, and then having them suggest a an existing quality patch. Let’s dive into a real world example. Let’s say for example, you have a website and you are experiencing some customer complaints and looking through your logs, you see an issue where the maximum number of cookies being set is being exceeded causing an error. This could be a fatal error on the front end, meaning your customers, for example, can’t check out or perhaps you’re just simply reviewing the logs, and you’re noticing a lot of entries. So let me just show you what this might look like. So we’re going to go into var report. And I just have a sample of what this error might look like. And for this one, it’s going to be the unable to send the cookie maximum, maximum number of cookies would be exceeded. So this is it’s an older issue, but it’s one that was around and it would just give you a good idea of what to expect. So now that we’ve seen the issue, and we’ve can kind of verify that our existing project is affected, we want to start the triage to see if there is a way to resolve it. So at this point, you might be tempted to make a support request. But this actually might be something we can resolve on our own. And right now, actually, we don’t really have enough information. And we really haven’t done our due diligence to see if this can be resolved ourselves. So let’s continue our investigation. Now that we see the error in the logs, we can use that to search to see if anybody else has reported this issue. So let me copy the message. I’m going to include the quotes because that might will help in the Google search to see if anybody else has posted it. Try to avoid the urge to use a third party site. Whereas they do offer sometimes good solutions. They aren’t usually the accepted and approved one by Adobe Commerce. So leveraging the GitHub issues is going to lead you exactly to the issue and then the dialogue between the developers and the person reporting the issue. And then hopefully, at some point, someone will mention the quality patch tool, the quality patch that’s specific for this issue to potentially be used. Another good place would be the experience league or the documentation. So both of those would be good places to start. But since we do have a GitHub issue, this is a fairly good and fairly likely location that we’re going to have a resolution. So when we open this up, we’re going to look at the message and it does look very similar. They’re getting basically the same message we’re getting. And so this is the initial instance of the issue. So what you could do is you could, you know, look through this file to see if anybody has any helpful information. And it looks like one thing to note is that the max num cookies is a constant that, you know, possibly could be adjusted. So we can keep reading this. And it does look like several people suggest that changing that value from 50 to, for example, 100 or 200 is probably the best solution. So we’re just going to keep going down until we find the bottom. And it looks like someone from support said that there’s a quality patch available and it’s MDVA-12304. And this patch apparently changes this constant from 50 to 200. So that’s great. So we’re going to use this and we’re going to see if this actually will fix our issue. Okay, so now what we’re going to do is we’re going to go to a website that has all of our patches, and we’re going to look look it up by its number. And let me just copy that link. So if you go to this website, this GitHub, and then you look for if you just simply just use search. So we’re going to do MDVA-1234. And so now we’re just going to go find it on the page. Great, there it is. So now we’re going to open it up, we’re going to look at this patch, and we’re going to see that it’s modifying a single file, which is great, it’s a little less complex. And it’s vendor Magento framework, standard library cookie, and then PHP cookie manager. And we’ll notice that it’s removing this line, which has the value set at 50. And it’s adding a line that has it set at 200. This definitely seems like that matches up with the GitHub issue and then the potential resolution. So I’m fairly confident at this point that this is the solution that we want to try. So now let’s go ahead and look at our core code stuff that’s in our local environment. And we’re going to see if our number does match up to 50, which is what it should be because that’s the original file. And just to make sure we don’t have a conflicting patch or something getting in the way. So by doing this, we know that the string that is used for the constant is max underscore num underscore cookies. And so just for quickness, I’m going to use a cat in terminal, and we’re going to look at the file. And we’re going to grep it looking for max number cookies. And it does look on line 34 that that value is set to 50. So this probably is our problem. And this patch definitely seems like it’s going to be the right answer. Looks like it’s on line number 34. So we’re just going to keep that in mind when we go to review the patch after it’s been applied. So the next command that we’re going to run is going to be the ECE patches status command. So by that you go to PHP space and then dot slash vendor bin ECE patches status. And the interesting thing about this is that patch details can be found at this website. And this is just another way for you to validate that the patch that you’re looking for is still available. And make sure that the description and the intent does match up with the expectation because you could accidentally have somebody type in the wrong number. And so this is a great way for you to double check. So we’re going to use that website and we’re going to go there. And from here, you’ll notice that you can search by keyword. And so since we know the patch number is MDVA-12304, you’ll notice that it auto filters for us and we’re down to just one single patch that matches. And the description says that it increases the number of cookies from 50 to 200. And that is exactly what we are hoping it would do. So we know that we’re on the right path, we know that we have the right patch. Now it’s simply time to apply it. So the way you do this for W eCommerce Cloud is in the dot magento dot env dot yaml file, we need to add a new section underneath the stage. And I’m just going to copy what I have. And let me get back to terminal. So we’re going to do a first we’re going to do a first we’re going to do a second we’re going to do a second. And we just want to make sure that if we don’t already have this information in place, that we go to the stage section. And we add a build node. And then underneath, we need to have quality underscore patches. And then underneath that is the dash, and then the patch number. And you can do as many patches as you need. Simply just follow the same pattern, MD VA dash 9999 or whatever. But for now, we just want to apply one patch. So now that that’s done, we can save it. Now to apply it. Now this notifying that file is meant for pushing it up to the cloud. In order to test this locally, we want to just run a simple CLI command. So by that, we’re going to go to our terminal and we’re going to do vendor. And it’s under the bin directory. And we have a command called magento patches. And then after that, you use the word apply, and an MD VA dash 12304, or whatever your patches. So as long as we don’t get any errors, and it looks like the response is exactly what we expected. The patch MD VA dash 12304 has been applied. It gives us the title, which is just another way for us to double check. And then this is exactly what we’re hoping. So now, we can do another search on that file that was modified. And we can see if it was actually changed. So this command right here, I’m basically combining head and tail. And I’m going to get lines 30 through 38. So we can see what is in between there. And you’ll notice that the constant max num cookies is now 200 instead of 50. So everything looks great. We’ve, we can now do some local testing. And if we’re happy, then we can commit this file to our cloud repository to our dev environment or staging environment, and continue the QA process. Once again, you should always test this thing locally, you should always test it prior to pushing into production that shouldn’t be said. But just a helpful reminder that these patches are available. And that is the expected process. So now the last thing you can do is if you are curious, or you just let’s just say for example, you want to revert this patch, instead of using the word apply, you would switch it out with the word revert. Okay, and now if we go and look at that file, we’ll see that it is back to 50. So that’s a quick tutorial on the quality patch tool. Remember, this is meant to give the developer a fast and easy way to fix a reported problem. The best practice for this is not to use this for a large volume of patches. Keep this down. If you find that you’re doing many, many, many patches like this, then you probably either need to upgrade or figure out why you’re having so many issues. But just remember, if you’re not using the word reboot, you but just remember that this is a process that is meant to keep it as fast and as clean as possible for your developers to continue their progress. Like anything, you can do this in multiple ways. The quality patch tool was created just to offer consistent and easy mechanism to resolve known issues. This is just a short introduction to the process and we have lots of supporting developer docs and experience and tutorials that go into greater detail. I hope you continue your research and learning on this topic and please visit Experience League for your learning journey.