Tracking changes on Adobe Commerce Cloud

Transcript

All right, everyone. Next up, we have Aaron Meehan talking about tracking changes on Adobe Commerce Cloud. So take us away, Aaron. Welcome, everybody. My name is Aaron Meehan. I’m Lead Customer Technical Advisor for Adobe Commerce here in APAC. And today I’m going to be presenting on how you can track changes in Adobe Commerce for better observability. So we’re going to take a look at why you might want to track changes in the first place. We’re going to take a look at the updated New Relic change tracking features that are available and how we’ve implemented that into Adobe Commerce and New Relic. We’re going to talk about some of the current challenges that you may face or businesses may face tracking changes and implementing this within a project. I’ve got a little demo to run through so we can see some of these features action. And then we’re going to discuss the installation steps and then talk about how to implement this on staging as well as some options for our on-prem customers and open source customers. The audience for today is people like software engineers, SREs, delivery managers, DevOps teams. But really, this is useful for any team or anyone who wants to improve deliverability and increase deployment velocity on Adobe Commerce. So if you’re not one of these people that fits into this short list that I’ve got here on screen, stick around. We’ve got some interesting stuff over the next 25 minutes coming up. And I’d encourage you to take it away. And if you are part of one of these teams, share this information, share this recording with the people, the right people in these teams and make them aware of this because it’s something that can definitely help improve your observability on Adobe Commerce. So first off, why would we want to track changes? Well, specifically speaking, let’s just identify the changes. We’re talking specifically here about changes that can affect performance. So deployments primarily, but other changes on cloud that can potentially affect performance as well. So there’s a saying that change is the only constant in life. Some of you listeners may be aware of that or heard that before. But generally, change is something that everybody learns to deal with from a fairly young age. Learning to deal with change builds resilience and it makes us stronger in the things that we do. Like in life, this statement also resonates for those in the software industry. And we learn early in our careers that this is an industry that changes rapidly and has a lot of change. We experience a lot of change in our day to day in our jobs. Sometimes a little too rapidly, depending on the way you look at it. But things like new platforms, new languages, new trends, these are all examples of things that are introducing change to our jobs and keeping us on our toes as developers. So getting used to change and building better processes for dealing with it is the key to success here. And Adobe Commerce projects are no different. They’re a prime example of constantly changing situations where change is constantly occurring, constantly happening. But like life, we can learn how to more efficiently deal with these changes in our projects and the developments and features that we’re implementing. And we can implement a process that helps us better deal with situations where change may have a negative impact on performance as well. So implementing change tracking can build resilience within your project and also your teams. And it’s this that ultimately helps us shift more reliable and robust products at the end of the day. So there are a few of the reasons why we might. These bottom two here are important. It also helps build confidence around the deployment process. So once we’ve got our teams have more confidence in actually deployments and deploying, making sure that we’ve got everything we need to quickly assess and pinpoint a performance issue to then roll back a change or put out a hot fix to fix that. It’s going to give everyone in the team a bit more confidence. And that is hopefully going to or can lead to an improvement or an increase to your deployment velocity as well, which is another benefit of adopting a change tracking process within your projects. So how do we do that? Well, enter New Relic change tracking. Released earlier this year, New Relic has brought out an updated change tracking interface and an associated API that ties deployments and other changes to performance data. So you can troubleshoot and resolve incidents faster across your New Relic observability app. You can see deployment markers and change notifications within different charts and different parts of the app, like errors, logs, transaction traces. In context and things like that. So previously, this did exist and you may have maybe familiar with deployment markers and have worked with deployment markers or the deployment marker REST API in the past. It had some limitations. It was only the deployment markers were only lodged or would only appear on charts within the APM section of New Relic. So this new change tracking API, along with, you know, was released, sorry, along with a user interface update that allows teams to view things in context and do their troubleshooting around change and see everything they need to in one screen. So that in context part is quite important because previously the way that we would do this is as we were made aware of some performance decrease or impact that we might need to look into. If we weren’t aware of the changes, we’d be, and even if we did have the original deployment markers set up, we’re often bouncing from logs to infra to back to APM to check some web transactions, maybe adjusting the time, going back in time to see what speeds were like previously and then coming forward again. We’re doing a lot of moving around out of context. This new feature allows us to have a nice interface to be able to see all of those golden metrics in one screen and that really helps resolve these issues faster. So a couple of other features here that are worth noting is that we can capture changes on any entity. So that’s great for Adobe Commerce with multiple entities, a default store will have production and staging. But if you’ve got second or third staging environments as well, then you can use this approach that I’m about to go through today as well. And it quickly helps answer the question, what’s changed in the system? So not all teams are always aware of what’s going on or the level of detail that’s gone into some of those changes. Remember that some change can be small, but it also can be quite large depending on what’s being introduced. So being able to quickly pinpoint what’s changed, sorry, what is causing an issue, but just identifying what has changed can help you get on fast track resolution. And that’s where our mean time to resolution comes in. So that’s speeding up the resolution. The next three are kind of related to the UI changes that have been introduced. Being able to have everything in one page in New Relic is really handy and then not bouncing around through the context is really great as well. Okay, so when we’re talking about New Relic change tracking, we’ve gone through the features here. So the current challenges and some of the reasons you might look to implement this within a project. First one is change introduces risk. So obviously code and configuration change is a leading contributor to performance drops and downtime incidents, which are expensive. So if we can reduce that, then we’re on our way to improving our observability and our applications. Performance drops here is probably worth mentioning. Downtime is an obvious one, but any performance drop is something that might be maybe closer, more related to Adobe Commerce. If we introduce change into the system and say category page speed or product page speed is affected. But there’s no other indicator that that’s happening. And it goes unnoticed for a week or two and then marketing reaches out because a few customers have contacted them. You know, that’s two weeks or several weeks where the project or the site has been running at suboptimal performance, 80, 70 percent, whatever it is. And that also has an impact, obviously. So it’s both of these things, downtime and performance drops are what we’re trying to improve here. So lack of visibility is the other one. Often teams aren’t aware of the changes occurring or the level of the detail in the change. Being aware of upstream changes that are occurring is crucial to starting when you’re optimizing performance on any system. Inefficient process and tooling is another challenge or something that people may face. Not having this implemented or not thinking about it, having the correct process may not exist. So it’s recommended to have a think about it and get one set up. Current tools don’t always allow you to correlate deployment data in context as well. And that jumping around from different sections in New Relic is really what can delay your time to resolution as well. OK, so I have a demo here now. This is New Relic for those that are familiar with New Relic. This will look or you recognize this screen. This is the APM application performance monitoring screen. And these are entities that have got set up. This is my sandbox, our sandbox, CTA sandbox. And you’ll see here we’ve got the production entity, we’ve got the staging entity. We’ve also got a few extra entities that we’ve gone and set up to test with as well. So if you click on one of these entities. Before I show you that, one of the things that isn’t immediately obvious, but we’ve got these three dots over here. And we’ll see this in a moment when we look at the installation steps. But you’ll need what’s called the entity GUID. And that’s obtained from here. So any entity in New Relic has its own ID. And it’s just accessed by the three dot menu here and then into the metadata and tag section. And you’ll see that. OK, so if we load this up to have a look at this. The first thing that we’ll notice is that we’ve got a few options, different options that will start appearing. So we’ve got using the menu on the left here, we’ve got a change tracking item in this left hand submenu here. We’ve also got this last deployment notification box at the top here with some high level information on response time error rate, whether it’s improved or gone down since the last deployment. But probably the most obvious thing is within our charts now we have these little markers, deployment markers here that indicate that this is the point in time when a deployment occurred. So those are really handy. We can access the change tracking interface by clicking on any one of these markers. And then this is where we’ve got our in context UI that really lets us quickly start to have a look at how this change has affected performance. So starting from the beginning, we’ve got the key impacts here. And if you don’t see data here, you may need to just adjust the time. This is just my sandbox, so there may not be any data coming through to these charts as well. But these are just errors, the logs in the middle here and then related alerts on the right here. So you can see that was a three related alerts. We can customize this. We can add any other New Relic data in here or chart that we like or multiple of, which is great. But this section here is really what I think is one of the most useful sections here. You can see we have a before and after response time for the top 10 sales transactions or most time consuming, I should say. And this is really helpful because we can quickly and easily see if a certain transaction has increased or decreased due to a change or deployment that we’ve released. So this is we can adjust this similar to our chart information or similar to if we’re looking at transaction times, we can filter these by total time or aptX and different metrics here as well. Moving down, we’ve got performance indicators. And again, this is where the previous API didn’t bring in data from the other sections of New Relic. So it’s really handy to be able to have one screen that we can see things like CPU utilization, throughput, memory utilization and then database transaction times as well. So and again, all of the charts have the deployment markers that we can just click on and then inspect further. So this is this is a really, really big improvement and really helps change tracking, observing changes in Adobe Commerce. Over to the right here, we’ve got the change details section. So within this section here, we have information related to the deployment. So the commit SHA, we have entity and then a version. So these two fields or attributes are required within the API. We also have just time and date and things like that. And then the change log here, we have what type of event triggered this. And this is just how we’ve defaulted this setup. This can be customized. You may want to, depending on your setup, you may want to actually have the commit message in here. So you could easily modify this to have the commit message in here. And then, you know, you could also look to add in other things like a deep link. So if you’re using GitHub integration, for example, and you’re using pull requests, you may be able to or you can set up a deep link here so you can link directly to that pull request and start to troubleshoot that way as well. So this is this is very handy. Changes in the group. This is related to to group ID. So we can also set up group IDs for tracking changes across multiple deployments that may be related, which is a useful feature as well. And then just the activity stream so we can see at a high level what other deployments have been in the times that they were deployed. This is a really useful stuff for change tracking. So another thing, if we if we come back over to the sub menu and click on change tracking here, we’ll be presented with the change tracking table that we can see a history of our deployments or a history of our change. And again, this is pulling just in from that deployment information in the change tracking. So if you wanted to customise it, you could add descriptions for or even users in here as well to have more information. But at a high level, this is very useful to be able to see aptX change, response time change and throughput change related to a particular deployment or change in the system. So again, very useful. And then clicking on one of these just takes us into that context view of of the change and the details related to that change as well. Oh, so I didn’t mention when I had this screen open before is, you know, when we’re in this view, it’s a before and after. So we can when we adjust the time period, we’re going, you know, three, six, 12 hours, whatever it is either side of that deployment to be able to review to be able to view information like we have in this this table here. So that’s very useful also. We can also compare to previous deployments using this option here. OK, so that’s the change tracking side of things. I’m going to jump back into the slide now. OK, so when it comes to to installing cloud, users can follow the steps in the guide that I’ve linked to here. And it is this this guide. You need to be using Adobe Commerce Cloud for this because we’re using some cloud native features. But I do have some slides on how to install and some of your options for on prem and open source customers coming up with it later as well. But at a high level, we’ve got these three steps here. It’s just creating the the JavaScript file with the with the template locally, create the script integration using the cloud CLI tools and then using those tools again, create the environment variables that are required to to make it work. So. Couple of notes on on installation here. It is installed using the command line Adobe Commerce Cloud CLI tools. So if you’re not familiar with those tools, you’ll need to install them. They’re a set of a locally installed toolset that allows us to perform actions on the cloud. It uses the recently released Node Graph change tracking API from U Relic, which is a GraphQL based API, and it supports a lot more deployment information compared to the to the previous rest deployment marker API. It’s quite easy to customise. Once you start having a play around with it and look at the scripts, you realise that you can customise it quite easily. So this this installation process also uses and this is an important one, we’re using project level cloud variables here to set this up. For those that are familiar with cloud variables or using the variables on the cloud, you may have used environment variables before and you’ll know that when you create one or update one of those environment variables that it triggers a redeploy of that environment. So using project level variables is a way that we can get around that because project level variables don’t require a redeploy. So this is a way to be able to get this installed on production if redeploying is an issue for you there. And it uses a cloud native feature called activity scripts that we’re going to take a little bit of a deeper look at in a moment as well. So a few notes there. If you are customising it, I encourage you to have a look at the New Relic change tracking API in their documentation that I’ve linked to at the bottom of the screen here. It’s very easy to start to play around with it. There’s only two required fields, the entity ID and the version, but you’ll be able to introduce any other of these attributes if you want to or if you require. Okay, so when it comes to the activity scripts, Adobe Commerce Cloud supports custom scripts that fire in response to cloud activities. So a cloud activity could be environment redeploy, a branch, or if you’re familiar with the cloud user interface, pretty much anything that can be performed in that interface and more can be set up to respond or fire in response to any of those events. So an activity script is just a JavaScript file that runs once your deployment has completed. So there’s a lot of info. There’s a global variable that holds all of the cloud activity details. So it’s very flexible. We can grab a whole lot of information about the cloud and the deployments, which makes this approach very flexible for a number of other use cases as well. But activity scripts are configured as integrations on the cloud and it’s quite easy to set these up. If you’ve configured something like Bitbucket integrations before or GitHub integrations, this is just very similar, but it’s a script-based integration rather than a pipeline integration. OK, customizing and extending, it is possible. We can update, remove, and then there’s logging that we can access for debugging as well. Updating, it’s important to be aware that once we’ve created and implemented the script, we need to then make sure that we’re updating it. Otherwise, we’ll actually add another one each time. So it’s easy to remove them, but just be aware of that. Updating is useful for adjusting the integration, but it’s also, you know, you’ll be able to customize and add more information to this script and then update it if you want to as well. I recommend to review the attributes in the NerdGraph change tracking API that I showed before. I had a couple of slides back there. This is all the information to be able to pull into the change tracking detail. And debugging is, you know, what’s happening with the debugging side of things is, or actually, if you do need to debug, you can put a console log into the activity script. You might be able to preview that in the browser like you might be used to, but it’ll actually dump the results of the console log to a log file and you can then review that log file. So before I go on, I’ll just jump into the actual, this is the track deployments guide that we’ve got set up for cloud users to follow. I just wanted to show you the sample response here, just to point a few things out. So once you’ve set the integration up on the command line, you’ll get this response. And if you follow the guide, you’ll set the integration up to respond on these activity events, cloud activity events. So environment push when we push code, branch, activate, restore. But if you look down here too, we’ve got just a standard redeploy, but we’ve also got some environment variable events that we’re tracking as well. So this is useful because sometimes changing or adding different values in cloud variables can affect performance as well. So having some transparency into what’s changed in this regard is quite helpful as well. We’re setting up what and specifying what environments we’re going to run on. And then the state here is once deployment completes, then the activity script will run. And then you’ll see just the results from the script below here as well. So that’s the sample output response. So staging environments. We mentioned earlier that this change tracking supports multiple entity, entities, sorry, in New Relic. So that means that with a little bit of modification to the cloud variables, we can actually set this up quite easily on staging or any other second staging environments that we may have. Actually any environment that’s information as a service architecture that supports, that has New Relic on it, we can set this up for. So we’re going to be using those cloud variables and overriding them. That’s the process here. And just an important little update on the last one there. Make sure that you, if you are doing this, update the entity GUID values for the correct environment. Or you might find that as you’re redeploying staging and testing, you’ll have a couple of extra deployment markers appear on your production New Relic. So that’s always important as well. On-prem and open source customers. You have a couple of options for implementing this. The first one is what we’ve had for some time that uses the original deployment marker API. So that’s part of the Derby Commerce CLI tools. So not the cloud tools, but the Bin Magento tools. And you can run New Relic create deploy marker and that should just manually create a deployment marker in the APM section of your New Relic account. Another approach might be to use GitHub actions for this. So by setting up GitHub actions, if you’re using, if you’re using a new API, if you’re using GitHub, you can set this up to use GitHub actions and then trigger on deploy and automate it through the GitHub actions. I haven’t tested on Bitbucket or GitLab or other solutions. But those other solutions have similar ways of implementing something like this. So with a little bit of research, you can probably get this set up in some of those other pipelines as well. So on-prem and open source, there are your options there. That’s the end of the presentation. I hope that was useful and you can see how starting to implement this on your Adobe Commerce Cloud environments is something that will help improve your observability and reduce the amount of time that it takes to resolve issues that are related to change and specifically deployments on Adobe Commerce Cloud. So I might open up to any questions if there are any questions at this stage. It looks like all our questions are answered and we’re a bit out of time. But thank you so much, Aaron. I appreciate you taking the time. Pleasure. Thanks, everybody. Thank you.