API Mesh starter kit using workflows

Transcript

Hi, I’m Russell with Adobe Commerce. And in this session, we’re going to discuss GitHub workflows. The API Mesh Starter Kit, it comes pre-built with two.

We’re going to start with the Deploy Mesh.

The purpose for this is to help with the deployment process. So for example, if we push a commit to the main branch, this Deploy Mesh will run, and so that way you can automate the process. And of course, this would be expected when you work in a production environment. So by using some credentials and configuring your workflow, you can use this feature in your own project.

The Adobe docs for the developer console has all the information that you would need. So be sure to check that out if you need help setting up your own server to server authentication implementation.

By using an OAuth server to produce tokens, the Adobe developer console, you can then take those details, things like the client secret, the technical account ID, the technical account email, and you would use these details to set up in your project. And I’ll show you some of these in my GitHub.

So assuming you have these values set up in your project, once you merge a commit into the main branch, it will automatically deploy your mesh. For this demonstration, I’m going to be using GitHub code spaces, but just realize that this can be done from your local computer or another IDE that you might be using. So now I’m going to open up the repo that I created using the APMS starter kit. And we can look at the results for merging into main and how the deploy mesh workflow ended up.

So I’m going to go into actions and quickly you can see that the action is running based on a commit that I’ve recently just made. This process, it takes a few minutes, maybe two to three to complete due to all the steps that are involved. But let’s take a look at a few actions from the past. And the first one I’ll open up, it’ll be the very first commit that I made.

When I open up some of these actions that are executed, you’re going to get a really good understanding for the steps that happen. So the first one is to check out the main branch. The next step is to install a node server to validate the secret and the all secrets. And those are those things that I just mentioned earlier. So the first thing that it’ll do from here is do a get mesh. And what it does is it checks to see if a mesh has been committed on the workspace. And since this is the very first commit for the repo, there was no mesh. So the action that happened was to do a create mesh. But if I go back to a previous or a subsequent push that happened after this one, the software will then realize that a mesh already existed.

And when we review that step, that get mesh step, it was able to retrieve an existing mesh on the workspace. So instead of doing a create mesh, it does update mesh. And what’s really great about this is that it’s an automated process. So you don’t have to worry about all the statuses and whether the workspace has a mesh or not. The CI CD will automatically do this for you.

So we’re gonna take a look at another action that comes out of the box. And this is performing a load test. The template used when you clone the API mesh starter kit gives you a K6 test. However, it is a rather simple test, but the intent is to provide a starting point and then let you add more tests to it. So for example, you can set up the pipeline to watch for pushes to the develop branch. And if that occurs, we want to run a load test. Then you can review the output and make sure that it’s the same or hopefully even better than previous ones. So let me show you some of these settings. I’m gonna switch over and I’m gonna look at variables.

And here we can see that in the variables, I’ve set up a duration to be 120 seconds and then the virtual users to be two. And obviously these can be adjusted to whatever makes sense for your use cases.

So I’m gonna go and I’m gonna look at some of the load tests that I had produced earlier on previous commits.

You can see that the run K6 test, that’s in the main step. This loads up a K6 instance, and then it starts running my two virtual users that run for two minutes. And then once it’s done, the statistics are displayed. And it includes some pretty interesting things. Things like how much data was received and how much time the request was blocked. But now hopefully you can see that all of these tests, they’re all compiled and stored in a single place. So then you can start comparing them. In this particular example, you’d have to do it manually, but just realize you can use another config in the same load test where then you would create a report out of it and then upload it into the same repo. So you have a lot of methods and options for how to use the results for these load tests. Well, that’s about it for this session. I hope that you learned a lot about GitHub workflows and the effect of a CI CD pipeline and running load tests. Please come back to Experience League to continue to learn more about Adobe Commerce, as well as all of the other Adobe products.