Using Cloud Acceleration Manager’s tools

Transcript

I’m going to discuss the Best Practice Analysis, and then I’m going to focus on some Local Development and Code Refactoring. So these are kind of the main three areas that I want to talk about and get into some lower level details then. So if we upload our BPA report to the cloud acceleration manager, we’re presented with this analysis that gives us, basically, a breakdown of all of the violations and things that the scanner, the analyzer finds when it’s, you know, looking through the code, looking through the AEM server.

All of the things that are listed here on the critical side of things to be paid attention to, most of these, if it’s a critical-level importance, most of these things are not going to work in AEM as a Cloud Service. So if the expectation is for these things to work, you’ll need to make sure that you review all of these critical ones especially, to make sure that they’re going to be working. We’ll get into some more details about what all of these types of alerts and what they mean in the code refactoring section, but just kind of, giving you a high level of what the importance it means. So, you know, all of those critical ones, we’re going to want to make sure that we try to fix. All of the major ones are also likely not going to work, but you’ll need to check. And if they do work, they might be violations in terms of things like, sustainable upgrades and things like that, where functionality and features may be impacted if the modification continues to persist in AEM as a Cloud Service.

So these are kind of, the high level overview of the report. From there, you can go into the Best Practices Assessment, and it will give you a breakdown of your current AEM version, your Java version. If it detects any AEM products being used, like dynamic media, and then, it will give you another further breakdown of the components and what you’re doing with your component breakdown. So this is showing me that I have nine components that have been scanned, and seven of them are inheriting from the foundation components, which is not to use the inherited foundation components, but to use the core components. So you’ll get some, best practice analysis here of what you want to do. You know, same thing with additional findings with Legacy UI, if there’s any Classic UI dialogues or anything like that.

It will give you a further breakdown of what all of these sections mean, and it’ll show you slow queries, maintenance tasks that have been detected, make sure, you know, just to verify what these need to be doing in your current system when you’re moving. So this kind of gives you a high level breakdown of your instance, and it shows you some of the best practices and what it found with your code base here. And then you can click on the tile for migration complexity assessment, or this uses a few key factors from the assessment to determine what the relative migration complexity would be for the migration. Things that are taken into account are, you know, as I mentioned before, the usage of Legacy UI, the level of non-backwards compatible code, and then contents, and then the level of customization for outdated code, as I mentioned before previously. So it also will show you the page count, asset count. So these things are important factors to consider when you’re doing your content migration. So this will kind of show you all of these high-level things that it uses to determine what it thinks the relative migration complexity should be. And what I want to make sure that it’s important to note too is that, when we talk about migration complexity, this doesn’t necessarily determine like a level of effort or amount of effort to do the migration. It might be a medium complexity assessment, but there might be, you know, some of the functionality that you’re using might be significant that, you know, the effort to refactor it is a lot of effort to refactor it. So it is important to not confuse level of effort with the migration complexity, because they are two different things. That’s kind of the overview of the best practice analysis report. And then after you’ve done that, you’re going to want to go into the set up and get ready for your local development. So getting ready for your local development, I just want to make sure that, you know, bring up it’s even more important now in AEM as a Cloud Service, to make sure that when you’re doing your testing, that you’re doing your testing end to end properly on your functionality in your local environment before you do your deployments to Cloud Manager. That means setting up an author environment, a published server, and using the local dispatcher tools to stimulate a dispatcher instance on your local computer. The Cloud Manager deployment time takes time as we know now, and we want to try to avoid as much of that unnecessary deployments and minimal code change kind of deploys as possible. So if you can really make sure that you set up your author and your publishing environment, as in your dispatcher, all end to end, like you’re supposed to, it’ll really help you validate cash and validations, your filtering rules, all of those types of things that makes it a lot easier than trying to go through a deployment process to the actual application servers and do your testing there. So I just want to make sure that I really emphasize trying to make sure that you set up the local dispatcher tools, that you set up an author and a publisher server, that you’re not just using the author server to simulate what it will look like on a publisher, but you’re actually using the public server to test your content.

And then we’ll go and look at the code refactoring and we’ll see what some of the things that it highlighted were and what we can do to fix some of those things. So the first thing that it found is it saying that it found the usage of the classic version of commerce integration framework, that is incompatible with AEM as a Cloud Service. So each one of these line items that it finds for a category it will have an eye next to it, and it will have a magnifying glass with a box next to it. So this eye icon will open up a page that will give you a breakdown of what the warning means possible ways to fix it. And if there are any tools available that can be used to help fix it, it will give you tools as well to help you do that. So this page here is the same information that can be found within the experience matter pattern detection documentation site, to this kind of outlines the same possible implications and risks. So both of these two pages can be used to give you a breakdown of what the issue means and possible solutions for it. And then when you click on the magnifying glass, it’s going to show you where the violations were at. So this is also an important thing to note, because if it’s scanning a certain, if you’re like, as a DT mentioned before, you know, you might be migrating multiple sites to Cloud Manager, and you might be doing them at separate times. So, you know, it’s important to know which sections of the JCR violating, and if they’re relevant to your application or not. If I’m not migrating than the real retail project, then I don’t need to worry about these violations, right? Because I’m not doing anything with this pieces of functionality. So it’s important to make sure that you’re clicking on these magnifying glasses and you’re looking through the list of all of the violations to see whether or not they’re relevant to you. And then obviously also giving you the additional context to see where the issue is and how you can go about fixing it. So that was so commerce integration framework was one of them. Another one here is Legacy UI dialogues were detected. though this one, again, Classic UI dialogues are not supported in AEM as a Cloud Service. So this will show you where those violations are at. And then this also will list tools and resources that are available. So we have a component converter from the modernization tools that can be used to convert plastic dialogues to Touch UI dialogues. So we do have the AEM modernization suite that can help with that. So that’s one of the violations that occurred, and again, like I said, it’s important to make sure that you’re looking in here to see which one of these you’re using, right? Like these community components I might not be using, but maybe, you know, this weekend component is mine. This hello world component that I made, you can see it’s pointing to my classic dialogue. Another important thing to note is this is just going to identify usages of where the Classic UI dialogue was detected. You might also in addition, have a Touch UI dialogue already in this location. So, you know, as long as you have the parody that you need with the Touch UI dialogue, you know, you might just have to just, might be as simple as just deleting this dialogue from the code base when it goes into AEM as a Cloud Service, since they’re no longer supported or necessary. So it’s really important to make sure that you analyze these items carefully, and you’re looking at what the readout is for each of them. Another one is telling me that I have some Oak Index Violations. And again, this will go over the outline of the issue, will give you some links to background and how you can properly index your contents. It’ll show you we have the index converter that’s a tool that we can use to convert your indexes to cloud service compliant index definitions. So we do have tools that are available to help with that. And this kind of gives you the breakdown of what that issue is as well. This will show me the two, my two custom indexes that I created that needs to be migrated to the new cloud service index format.

Another important one that I want to point out is a, you know, reverse replication. So this again, replication agents identifies where enabled replication agents are, the AEM is a Cloud Service uses sling content distribution for replication agents. So it’s important to make sure that you’re looking at your replication agents and seeing what you’re doing with them. Another important thing about replication agents that is called out in the code analysis is if you’re using any custom functionality within your replication agents to handle cash and validations of CDN and validations or anything like that, any type of serializers or anything with your replication agents, you’re going to want to make sure that that functionality is looked at and addressed as well. And refactored to be more compatible with AEM as a Cloud Service and the sling distribution feature functionality. So this will outline where it’s finding any usages of those, and it will tell me that I’m using reverse replication on my publish instance which isn’t supported, and it will show me the error and I have to remove that replication agent and expect that functionality to network. Another important one to note is runmodes. So runmodes, let me first show you the violation. So it shows me that I have to runmodes here that are violating the standards for AEM as a Cloud Service. The first one is I have a QA runmode, and the second one is I have a staging runmode. So in AEM, there are two types of application servers for far as configurations go, there are author servers and published servers, and then there are three different environment types. There’s a dev, there’s a stage and a prod. So there is no QA runmode.

There’s no way to set custom runmodes in AEM as a Cloud Service. So there’s no way for me to say that I want to have this runmode be QA.

And the same thing with staging this staging one is in violation because it’s showing me that I have, I’m calling it staging, and the proper naming convention is actually stage. So this is just alerting me that I need to update those names and the info icon, again, will show you more information about the proper naming convention for the runmodes and how they resolve, what they should be looking like instead of what you currently have. So this will give you all of those links to documentation. If there’s any tools, we also have a repository restructuring tools of duty you mentioned that will restructure your code and it will migrate configurations. It won’t move any of your legacy ones, but it should flag them in the report and it will tell you that you’re using, that it found some that I didn’t migrate. So that is available there. Another thing that’s important to know about runmodes that I wanted to bring up as well, is that this is talking about. So there are ways around these things, and that’s why it’s important to take time, to like, analyze and think about some of the problems and look at the items, assisting what you’re doing. So one of the possible solution that I just wanted to bring up for this one is, if you want to have multiple environments like a multiple, you know, like a QA environment, something other than just your staging and production, other than dev, and you know you have the credits in your code manager program to provision another non-production environment. You can create another environment and you can use as outlined on this page in the documentation, you can use environment variables, so you can set environment specific variables for different configurations. So for example, if you want it to have four environments and you need it to have a different API end point for QA than you did for dev, you know, you could set that end point to be an environment variable, and you would set that environment variable. So you would only have one runmode. You would have just the dev runmode, but that dev runmode would be pointing to the environment variable. And you can, you know, set that to be your API end point or whatever you need it to be. If you set it for things like timeouts or keys or other things like that, this also has the added advantage of not having to go through an entire deployment to get the configuration to be the update, to be published to the AEM environment. If you’re doing just configuration updates, it just requires a restart of the AEM instances and it takes about 15 minutes instead of the normal full Cloud Manager deployment time. So something to keep in mind, if you’re trying to simulate that, you know, that fourth QA environment type of effect, and you need to have some type of configurations different for your Devin servers, but you can use environment variables to handle that. Another thing that I wanted to bring up was content area violations. It might require a lot of effort because let’s say for example, in your existing code, you’ve overlaid something that is no longer overlayable. So content overlays or overrides since the AEM 6.4, we started doing what are called sustainable upgrades, where we start to mark certain sections of the repository with certain properties that indicate whether or not the content can be overlaid or what the implications of that overlay will be, if you tried to do it. And if you’re in violation of one of those areas, an AEM as Cloud Service, those things are not likely to work. So you’re going to have to make sure that you’re going through and you’re looking through all of those and validating them. Another important one to note that I don’t have a violation warning for, but to the same token is if you’re overlaying any of the out of the box, non-backwards compatible contents. So NBCC warnings, non-backwards compatible content.

These are relative because a lot of changes have been made to how AEM as a Cloud Service works functionally. So a lot of the, you know, like, it was common before for you to overlay, you know, rows or card rendering AEM offering interfaces to give yourself additional functionality that you want to draw others to be able to see like additional data about your pages or your assets or whatever. So it was common to kind of overlay those files. It’s important to make sure that you’re going back in the AEM as a Cloud Service. And you’re at a very minimum, if the changes are allowed to be overlaid still, or you’re going to want to make sure that you’re merging all of your changes with the newest version of those files that you overlaid previously. Because like I said, there’ve been a lot of changes to AEM as a Cloud Service, so things like processing profiles especially for assets and things that are different and the functionality is different than how it was in previous versions of AEM. So those overlays are likely going to be significantly different than what they were in your old version. So if you have a lot of AEM offering customization, you’re going to want to make sure that you pay careful attention to those, and that you’re really taking time to make sure that you merge those properly because if you don’t, you know, obviously the AEM offering servers are not going to be behaving as you would expect.

Those are the main code refactoring activities that I wanted to highlight. But this, again, this will highlight all of the important violations that have been made, it will tell you overview of what they are, and it will show you how you can fix them. And then we also have a link on the top that will talk about the dispatcher. So this doesn’t do any type of dispatcher, the best practice analysis doesn’t do any type of dispatcher validation, but we do have the just local dispatcher tools, which does have a dispatcher validator. And that’s why I was also saying before, you know, that it’s important to make sure you set that up locally, your dispatcher server, so you can validate that configurations are working properly, especially if you’re coming from on premise, there are chances are that you could be doing a lot more custom things that need to be converted using the AEM just special converter because we have folder requirements and naming conventions for where things need to be placed and how they need to be placed. So if your files aren’t matching our conventions, you’re going to want to make sure that you’re using the AEM dispatcher converter to go through that and convert your dispatcher configurations to be AEM as a Cloud Service compliant configurations. Then we also have information here that talks about testing, so these three areas, all of these links that goes through how you can set up selenium testing to do UI testing. We also talks about how in Cloud Manager you can set up, on your production pipelines you can set up, experience audit tests that are powered through Google white house which will basically say that you’re expecting, certain pages to act within certain thresholds after the deployment’s done, to make sure that nothing detrimental has been introduced to the code base since the last deployment that you can do your critical pages, so you can do that for your experience audit. And it also talks about how we can set up your custom product functional testing as well. So these things aren’t necessarily called out in here, like having a lack of testing or anything like that, but we just want to make sure that it’s important to note that testing is something that you need to take into consideration with your application and you need to implement it. So we have given you some links here on the top to help guide you and direct you to make those testing more reasonable. And then the only last thing that I wanted to bring up is I just wanted to go over this Go Live checklist. And I just kind of wanted to go over, if you’re using an AEM Managed CDN, it’s important to make sure that you set up your domains and all of that is set up and configured and ready prior to Go Live and you’ve been testing on those DNSs before you Go Live, we don’t want to deal with any firewall issues or anything like that, or any type of connectivity issues with your actual DNS when those resolutions start to happen. So it’s very important to make sure that you give yourself enough time to set up your custom domains, and you test all of those non-prior domains to make sure that you’re not going to experience anything unexpected when it goes to production. So it’s important to make sure that you set those up early, and it’s also important to make sure that you’d give yourself period of stability within the system before you do your cut over, right? The ideal situation, I think with AEM as a Cloud Service would be that the code and the contents is all there, and there’s been a freeze, there hasn’t been any contents updates, and there hasn’t been any codes deploys, But the AEM as a Cloud Service server for a little while, you know, a week or whatever, and then you can do a DNS, cut over to the AEM as a Cloud Service Instance. So it’s to make sure that you’re not trying to, you know, do run production pipeline deployments for configuration changes to update production URLs or whatever on the day that you’re going live, you know, make sure all of those things are set up in advance. And all of those kind of figuration values are ready and the system is stable and working adequately. Before you try to do that closer to Go Live. -