MCPA MuleSoft Certified Platform Architect Level 1 – Getting Production Ready Part 3

5. Demo: Promoting Mule Apps in Runtime Manager

Now let us see how to deploy mule applications from one environment to another environment manually. Okay, I’m on the any point platform. I will now navigate to the runtime manager to show you what apps I currently have in the Sandbox environment. As you can see, I currently have four apps running on the Sandbox environment. The experience is under AP Process Sales Order Replay and System Sales Order appear and all of them are running on three nine four run times and working good.

All right, so now the promotion or the deployment of the MuLab one environment to another environment is somewhat similar to a normal manual deployment where we go to the deploy application, right? So we click on the deploy application and same way we need to give a unique name for the application we are going to deploy, of course, choose the deployment target, everything else, the runtime, the worker size, number of workers, et cetera.

Okay? The only thing that changes is instead of choosing a file manually from your local machine or from an exchange, you have to click on this Get from Sandbox. Okay, so this is the option where we need to click to get app deployed from an existing environment into your environment. Okay, so when I click this Get from Sandbox, don’t worry about the name here why it’s saying Sandbox, why it is not showing some other environment name. This is a general hard coded name on the button by Mule Soft. But once you click it, it will give you a pop up where you actually get full list of all the environments you currently have and you can choose your environment and choose an application.

And you also have an option to choose whether you want the environment variables in the mule version also exactly to be same as what the app was running on your source environment. Because the reason being you can choose your runtime and the properties in your target environment as well. Just like how you give the name and the deployment target, you can choose your runtime here and same time you can have your own properties here, right?

And you may only want to get the artifact or the bundled application to be deployed, but you still want to go with your own runtime and properties for this environment. If that is the case, then all you need to do is just choose your source environment and select the app and leave this option untouched. Don’t touch this option.

Whereas say you don’t want to take any chance and just go with for now the same runtime variables and the mule version the source environment is having, then you may opt this option. You can check this box so that the same new runtime and the runtime variables or the properties that the source environment have will also get promoted.

Okay, one thing I want to highlight and explain you is if you see this environment list, right, the one difference or the important difference you can notice between the promotion of APIs in the APA Manager versus the deployment of apps in the Runtime manager is that in the APA manager, you can only promote the APIs between two different environments.

Meaning, if you are currently in the sandbox environment and click on Promote APIs Promote from Environment button, then the list that you get right? The environment list will not have the current environment in it. It will only have the environments other than the current environment. So you have to choose a different environment to promote the APA from that environment into your current environment. Correct.

But if you see the Runtime Manager list, this list will always show you all the environments. Okay? The reason being you can deploy the same app with a different name in the same environment. That’s the beauty of this frontier manager. Because it’s quite possible, right? You may want to run the same your application as two separate apps with two different names for whatever is the reason. Okay, there can be a number of reasons.

Then you can choose the same environment as source like sandbox. Currently I am in the sandbox environment and I’m going to choose the sandbox environment as my source. I will say I want to deploy test math app. I’ll apply that. Then immediately that artifact will be chosen as my application file. Now I can just name a test test app two and then the name is not available. Test app 21. Yeah, all good. And then what I’ll say is, okay, I’ll just go and get it deployed.

So what happens now? The moment I do this is if I go back to my applications, you can see that I have tested app 21 getting deployed into the same environment. All right? Same way. Say if I go to the test environment now, currently there are no apps running on test environment. I can say, okay, deploy application. I’ll give the name as EXP sales order API Tst. And then I’ll just choose my app from the sandbox environment. I can’t choose from test because there are nothing, right? So I’ll choose from sandbox environment and I want to use the same environment variables and mule version as my sandbox.

I don’t want to choose my own in the test environment. Okay? So that’s why I didn’t go and change any of those things in deployment options. So I’ll just click on apply. If you see it automatically changed the version from Four X 2394. I’ll just say deploy. And if you go back to the applications now, you can see that there is a new API listed which is getting deployed. So you can see that in the logs. Now if you click on this, you can see that it is getting spinned up now.

So this is how we promote the applications from the Runtime Manager to different environments or to the same environment. Okay, but one last thing. I want to remind you guys again is that this is just a way to do not the ultimate way or the final way we can do the deployments or APA promotions. This is just one of the ways we can do in real life projects generally.

This is the very last option we do because we want to implement the deployments and promotions as part of CI CD, right? So all the runtime manager new labs are generally 99% gets deployed using Mule Maven plugin integrated with your CICD tool and the Mule management plugin will take care of the deployments across the environments.

Okay? That is the good way, fully integrated way, automated way and same way for the APA manager promotion of the APIs. Any point CLI is the way to automate it to promote the assets between the environments. Okay? Reason being like you have seen right in the API manager, if you want to deploy, say ten APIs, you have to go and click on every single API, choose it and deploy it. It’s very tedious task when you have some, say hundreds of APIs. It is not practical to go and click every time.

Promote from environment, choose each and every individual API and then promote them. So any point CLI is the best bet for you where you can go and do a bunch of API deployments and promote them from one environment to another environment. Very easy. So what I was trying to show you in these demonstrations is just a way how we can do manually as well. All right, happy learning.

6. Understanding Automated Testing

In this lecture, let us discuss about the automated testing. But before proceeding, I just want to highlight one thing that the practice of the testing automated testing does not change fundamentally for this new Soft or the Apollo connectivity project, okay? Testing is always testing and the testing skills are agnostic to the the technology or the product we are using, right?

That is why we see that the testers in many projects are even not aware of the full product knowledge. They just have some fundamental principles for testing. So same way there is no change when it comes to the safety connectivity. So, why are we discussing this? Why we are discussing this is to just address some of the important topics in the testing that should have some special interest or concentration or focus in the testing area when it comes to the API Led connectivity and the application networks.

Okay, let us see what are those due to the interconnected nature of this application network as it’s like a web kind of thing, right? Like you know, it’s a very network is growing one and as the more related architecture come, the more big it grows, right? The main important testing focus should be on the resilience tests, okay? This is very important in establishing confidence in the failed safety of the application network.

What are the focus areas? The APIs and the API specifications take the focus area here when testing the application networks. So it covers in two ways. One, there should be proper unit tests written for each of the APA implementations that are being done. And there should be some integration tests as well documented so that the EndToEnd scenarios are covered.

Let us see in detail what are the unit tests and integration test approach should be. So, the distinction between them is let’s go to the unit test first. The unit tests do not require deployment into any special environment, okay? Such as we need not be in a specific environment like staging or UAT for it to run. They can be run from within an embedded mule run time. Okay? The tools you can use for unit test for the mules of project is the Amunit one.

This is the best tool because the ammunit supports many of the mule native features and works effectively for mule unit testing. Although they run in embedded runtime and do not require to be in actual environment for read only interactions. If you have any dependencies like to actually call the back end system for the read only thing, you can still point them to the actual endpoints like in UAT, staging or production even because the read only generally doesn’t harm the functionality of the back end system. But for the right interactions, developers must implement the mocks using the M unit. Okay? The unit tests also require the knowledge of the implementation details of the API implementation under tests. Okay? That is why this is called white box testing. Reason being the AMI units or the unit tests are written with the knowledge of the AP implementation.

They know how the APA works. With that things in mind, the white box testing should be done and the unit test should be returned. Now, let us see about the integration test. Integration tests are full end to end test, okay? They exercise the API just like production API invocations would happen over Https protocol with all API policies applied, et cetera. They require deployment into a specific environment for testing in each environment, like Sit UAT staging environment with all dependencies available, just as in production. No mocking should be permitted for the integration tests. Integration tests can be implemented using Soap UI and its Maven plugin to trigger APA invocations against the deployed APA implementation and asset responses.

By the way, the integration tests do not require the knowledge of the implementation details of the APA. Okay? This is the display called Black Box Testing. To be frank, it is not just that it does not require you have to make sure that you prohibit the knowledge of the AP implementation as much as possible for the testers or someone who is documenting these scenarios, okay? The more or less knowledge they have have an AP implementation, the better the integration tests will be. All right? Now, let us move on to the next lecture in this section and discuss first about the integration tests.