Efficient Development on Adobe Experience Manager as a Cloud Service

Transcript

Thank you all for joining this afternoon. I’m going to go ahead. My name is Lamont Crook. I’m going to go ahead and kick this off. What we’re going to be talking about, what I’m going to be talking about today is a more decoupled, a faster way to deploy content, front end development, CSS, JavaScript to AEM. So the objective of this session will be to understand what the front end pipeline is, understand how to use it, how to deploy code to it, and then how to adapt your full stack project that you probably have right now such that it uses this new front end pipeline. Fundamentally, how do you decouple it? So before we get started, what are we talking about? What is the front end pipeline here? Well, if you think about the different personas that use AEM, there’s obviously the site admins, the site authors. They don’t use any code. They’re creating content. They’re working with inside the interface. I think that’s pretty straightforward. Nothing really changes about that. Front end developers, however, they’re working with CSS. They’re working with JavaScript. They’re working with different components. And quite often, they’re working independently of AEM. They may know AEM but don’t really have in-depth experience with the back end functionality of AEM. And then, of course, you have your traditional AEM developers who are working on back end functionality, writing compiled code. So really, the new element to this is the low code front end developer workflow. This, what we’re going to go through today, can be really worked on with parallel, like the front end developers and the back end developers can work in parallel with one another, independent of one another. Or you could combine them together as a deployment. This really depends on your governance practices. So today, we’re going to go over a few things. This isn’t particularly difficult, but there’s a lot of details. So what we’re going to do is I’m going to walk you through how to set up the local project archetype. So what are the changes you need to make? What is decoupling the UI front end mean? What are the things you need to do? How do you then update the UI front end so it uses front end pipeline rather than the traditional way within the actual archetype? And then we’ll look at Cloud Manager, how to set up those pipelines, committing the code to those pipelines, and then committing front end code to it. Sorry about that. So decoupling the UI front end from the full archetype. The first thing we’re going to do is go into the interface, and we’re going to enable front end pipeline. We’ll use that then to update some sling configs. And then we’ll work within the code to decouple it. And in full confession, I’ve recorded elements of this so that you don’t have to watch me click around and try to remember the actual flow that I should be following. So let’s go ahead and get this started. So what we’re going to use today is the weekend site. The weekend site is, if you’re familiar with AEM, AEM is a pretty typical example of reference architecture. And what we’re going to obviously be doing is adapting this. If this is new to you within Cloud Service, you have a new left rail item called a site. The site allows you to do a few different things like install a template, like create a site from a template, and then, of course, this enable front end pipeline functionality. And what that’s doing is adding some sling configs. And we can take a look at that. Inside of CRX, you’ll notice that there’s two new sling configs here, the HTML page item config and the site config. We will look at these two items in just a minute, the XML of them. And I will walk you through how they’re going to relate to the new theme. For this particular example, what I’m going to do is create a package from those two sling configs. We’re going to bring that package into our local archetype. So we’ll download them, and then we’ll unzip them inside of our archetype. What I’m walking you through here in terms of the setup of the local project can be accomplished in many different ways. You could start with code. You could add these sling configs in. You could start locally and do the whole thing locally and then deploy on Cloud Service. However you want to approach this is really at your discretion. I’m assuming that you’re starting with a site fully deployed on Cloud Service. And then doing this adaptation locally and then redeploying on Cloud Service. I think that’s a flow that makes a good deal of sense. And fundamentally, by downloading those sling configs to your local project, you’re creating a situation where now your local code base is in sync with what’s in Cloud Service. So your code bases are fundamentally in sync. With inside the HTML page items config, there’s a few things to take a look at here, the page prefix. So for this example, right now it’s set to a relative path. We’ll look at what happens after running the frontend pipeline. Before a local development, we’re going to emulate that frontend pipeline. So we’re just going to point this out to localhost 8080, and I’ll explain in a minute what that is. You also notice that within this file, there’s reference to theme.css and theme.js. And so those are two files that are really going to be replacing client libs. And then you need to take away the UI frontend reference from the full archetype. So go into the root palm, remove the module reference to UI frontend, and then go into the palm in the UI apps and remove the dependency on UI frontend. And then we can build this locally. So for my example, I’m going to also move the UI frontend out. You don’t have to do that. I just think it’s cleaner. But I’m imagining as a part of this flow, we’re starting with just a blank local SDK, has nothing installed, and then what we’re doing is building to that local SDK. And so if you’re following the same tutorial, after you do that build, you’re going to notice that the site here has no styling. And I’ll explain in a minute why I kind of like this flow. But this is the kind of final check to make sure that you’ve done everything correctly, is weekend broken. So let’s jump over here to the next slide. Sorry about that. All right, for our step two, now we’re going to update our UI frontend. So fundamentally, we’re kind of done with the backend stuff. You can close that all out. And we’re going to go into the new UI frontend. And we’re going to really work with this independent now of everything that we’ve traditionally worked with. And there are a number of changes that you need to make to this directory. I’ve put together a full GitHub repository that I’ll include in a link so you can see all the differences. Quite a few of them are removing things that are no longer necessary. But a few of the notable changes are to the webpack config. There’s also some changes to the package.json. And then I’ll walk you through what that local server is. So fundamentally, that server that we referenced within the HTML page config, sling config. So let’s look at what some of this stuff is. So if we take a step over here to Visual Studio Code, as I mentioned, webpack config needs to be updated. So in this, and I’ve annotated all of this. So if you look at this within GitHub, you’ll notice that all of the comments are here to help you follow along. But fundamentally, since now things are called, things are called like theme.js or theme.cs, we need to change the entry point, the key to that, to theme. And that also means that we need, and so that theme is going to be used within the theme.js here, the name.js. It’ll also be used within the CSS name. And so that’s important because the HTML items config, the sling config, is telling AEM, look for a theme.js. Look for a theme.css. So we need to adapt that within our config. We also need to update where the resources are getting built. So in a traditional AEM archetype, this is going to go to clientlibs-site. That needs to be changed to a folder called theme, such that it matches what AEM is expecting. So not a lot of changes, but some important changes to make sure that some of this content resolves. The other thing, and actually while I have this open, I can show you in the HTML page items config what those different elements are. So this page prefix is what needs to get changed to localhost 8080. That’s fundamentally that local server. And then the theme.css and the theme.js. So let’s then take a look at the package.json. There are a number of things that I’ve changed within this. Some of them are adding and removing libraries. But one of the main things is this build. So the front-end pipeline is expecting there to be a build script, which creates that collateral, that .js file, that CSS file. And so we need to add that in. The other thing that I’ve added in is the live theme. So this is fundamentally the emulation of that front-end pipeline that I was talking about. These other elements here is if you’re familiar with QuickSight Creation Template, front-end developers can proxy AEM. So they can grab AEM content. They can make theme changes. And Browser Sync will update that on save. I’ve adapted all of that to work now with this kind of reconfigured UI front-end. We won’t talk a whole lot about that. But just for reference, that’s why those things are there. So if we jump over here to our local host site, or our site running on local host, you’ll notice that everything here is running. As we expected, based upon where we ended the last video section. But I can come in here to the terminal, and I can run. So I’m doing something wrong. Sorry about that. I’m not sure why I’m not seeing things. OK. And so like I mentioned, this is going to start up a local server. And then now we should have a theme here. And if we look into View as Published, you’re going to notice under the Network tabs, these are now these different files are starting to. So you’ll notice here the theme.js is being referenced. The theme.css is being referenced. The reason I like this flow is we fundamentally break the site locally. And then when we add the theme back in, we’re fixing it. But having things broken really helps you quickly debug. So for instance, one of the things that I immediately noticed was the fonts aren’t being referenced. And so then I need to go back to my UI front end and adapt where the fonts are being referenced. And so this is a nice way to come through and debug what you’re working on. OK. So now let’s go over here and talk about the next step. The pipelines. So we’ve now gotten everything working locally. And that’s pretty standard practice for doing development on AEM. Now let’s get it working inside of Cloud Service itself. So we’re going to walk through a few things like setting up the front end pipeline, deploying on the pipeline, and then looking at how it’s ultimately finally now working on Cloud Service. And while I go through this, I’ll talk you through what Cloud Manager is doing, what its role is, things like that, in case that’s new for you. So Cloud Manager is functionality that allows you to self-service in terms of code deployment, management of that code, different administration things, such as web tier configs, things along those lines. You can create new repositories. So I’m walking you through here how to create a brand new repository for our front end code. There I talked to a number of people. I was putting this together. There’s a good deal of debate. Should I just leave it within the full stack and just reference it as a folder, or should I create a different repo? It’s really up to you. Again, it depends on how you work, how your governance is, things along those lines. But after you set up that new repo, you’ve got to create a project under that repo. There’s a few steps here. But then you commit your code to that repo. Really, as you would suspect, nothing terribly different about this than any other times you’re using GitHub. One thing I call out here is that when you create that repo, there’s already content there. So you either have to force or do a pull or something along those lines to resolve that. But once you have code in your repository, you can now set up a pipeline and run it. So pipeline is fundamentally the thing, like it sounds, that connects your repository to your environment and your site. There’s a variety of different kinds of pipelines, code quality, and then of course, deployment pipeline, which we’re looking at here. And then when you choose deployment, you can choose web tier, full stack, and front end. And so as long as you’ve enabled front end and you have those sling configs, you can then deploy to that front end library. And so this processes, this goes through the steps much more quickly, not this quickly, but much more quickly than the backend pipeline, which is a real advantage here. So fundamentally what’s happening is that build script is getting called. And then that new built theme is being stored outside of AEM and then referenced to in AEM. And so when we then look at our new site, and again, we inspect the network calls, you’ll notice that now, instead of client libs being called, the theme.js, the theme.css, et cetera, are all being called appropriately. One thing to take and look at here is this request. In this request is this long number, alpha numeric number. That references back to the content hash here. So just as reference, after you run this front end pipeline, that static URL is going to match those two things. The reason for that is every time you run this front end pipeline, it becomes a version that you can see inside of AEM, inside of the author interface in AEM, so that an author or a super user can say, I wanna use this previous version, or I wanna use the new version or however. So it gives them a bit of a self-service interface. So all those versions of the front end theme gets saved and referenced in the content hash is the thing that marries those two items together. Okay, and then let’s just finish this section up here. Okay, so at a high level, like I said, there’s a lot of details here, admittedly, but at a high level, it’s pretty straightforward. We’re decoupling the UI front end directory folder from the full archetype. We’re updating that UI front end to use the front end pipeline, which is webpack configs, package.json, removing a few things, adding a couple different libraries. Then we’re setting up the pipeline. So if you were approaching this flow slightly differently, such that you didn’t have anything in cloud service, you’d have to set up the backend pipeline and then the front end pipeline. But since I started with that, my backend was already there. So we walked through that, and then we committed that and ran that front end pipeline. So we then married up the theme with our site. So I’ve put together a number of different resources. I’ve written up, since there is a lot of steps here, I wrote up all of those steps and put them together. So there’s a link to a tutorial. Like I said, there’s a GitHub repository with the theme resources so that you can see the full spectrum of all the changes that I made. There’s also an experience league tutorial that’s slightly different than this, but that’s gonna be updated to match a little bit more this flow. But fundamentally, there’s a good deal of resources for you if you want to do this exact same thing with your project. So lots of details, but we can turn this over to the question and answer point if you have any questions. Looks like Vlad got the vast majority of these questions. I’m not sure if I understand how would you define the archetype. Raven, would you mind clarifying that? Oh, okay, I understand. I can provide you my definition. It’s really where you start with AEM. So by creating an archetype, you get a number of different resources that allow you to deploy code locally and in cloud service. So the archetype is the folders, the files, really a starting place. So it’s a standard thing. If you’re an AEM developer, you probably have an archetype. And when I use the term full stack, it’s a full archetype. UI front end traditionally is a section of that archetype, but that’s fundamentally what an archetype is. Hopefully that helps. Deployment manager process, repositories to pipeline mappings. Yeah, my video went rather quickly. So I’d be happy to walk you through that. So bear with me, there’s gonna be a few clicking around here to get to the right spot. Yeah, so as I go through this, there are some resources on how to marry up your organization’s CI CD with Adobe CI CD. But let’s just go through this. So the repository is pretty straightforward. You’re simply adding a repository, you’re naming it pretty standard here. This is not altogether different than what you would do on GitHub. After you do that, you need to just remember to create the project. So fundamentally this is putting that initial content in the repository. So again, if you already have a project that’s completely unnecessary process, but it’s necessary for the interface, right? But it feels kind of unnecessary, I guess is what I’m trying to say. The, so after you’ve done that, then you can create the pipeline. So the pipeline is you have, since I don’t have a production environment in AEM, so in environments like dev stage production, since I don’t have that, I only can create a non-production pipeline. But when you create that pipeline, you have the choice like you saw between code quality and the deployment. And then with the deployment, you have web tier front end and full stack, provided you’ve enabled front end. So you get, you’re able to create a front end pipeline if you enable the front end pipeline in the author interface, which is where we started this whole thing. And then that is the stages of the front end pipeline. So normally you would run that front end pipeline. If we look over here at the overview, so this particular program, so a term program kind of like an instance in sort of traditional AEM land, where you start up an SDK or run a virtual machine in production, in a, that’s sort of the same thing as a program. And then environments are like I said, dev stage production inside of that. And then you’ll notice over here, my different pipelines. So I could go ahead and I could run that front end pipeline or that backend pipeline that can also be set up on Git, like on the Git commit. So as soon as I commit new code to it, it could run that pipeline. And that is part of how you would integrate your company’s CI CD with this cloud service CI CD. Yeah, the faster backend deployment is something that’s asked about consistently. It has gotten faster, but it’s definitely not the fastest that most customers want. So I know that something’s always being worked on. I’m not necessarily aware like any, what do I wanna say, milestones that they’re trying to hit. I don’t know if Vlad you are. Oh, that Robert, I am not sure about. I’m not sure Vlad if you are, that might be something we’d have to follow up with. Parsana, I’m sorry, I’m not sure how to answer that. I don’t know Vlad you are. Yeah, for Robert, that’s something that we would need to take back. I can’t give you an answer right now. And for Parsana, I’ll post a link with the documentation with custom artifact. Yeah, I’m glad I don’t know if you know the answer to Parsana’s question. If not, we can follow up with you. Yeah, I’m not sure off the top of my head, but I’d be happy to follow up afterwards. It’s great that there’s all these questions, thank you. Any more? So would end up with main bundle and chunks, would this work with the approach you presented? Wow, Mohammed, I don’t know. So fundamentally is your question, would this work with code splitting? Do I, am I understanding that correctly? Yeah, I’m not 100% positive. I would have to, yeah, I’m gonna have to take that one to go. I mean, my assumption, I don’t know, Vlad, if you know. Yeah, I can step in. It should work as long as the main chunk is referenceable from a known path, right? As long as you don’t use hashes for the main chunks, for your entry points, you should be able to do that because the HTML page items can be need to, needs to know the path of the file you are loading. So if you load your main chunk from the same path and that’s the main chunk references the others. I think Mohammed will have to take that one to go as well. Yes, the hash is automatically being added as a part of the build process. I was simply pointing out how it fundamentally works. You could also, if you were doing local dev, if you were working with local dev and you had the front end pipeline deployed, you could grab that URL and use that locally provided there’s not a cores issue. But yes, it’s added automatically. I don’t think it’s visible. Vlad, correct me if I’m wrong. I don’t believe it’s visible to package manager. No, the front end package is not visible in the package manager. Once you have done the deployment on your website, you should see it in the site trail, the one where you activated your front end pipeline. Yes, Sajan. It’s technically not in AEM. Right, the actual files are not in AEM. AEM only has some metadata and knows about the deployment and where to find the files. Yeah, I can follow up Nicole and see if we can get the links added. I’m pretty sure there’s some collateral on experience league but fundamentally with cloud service, you would put Akamai in front of Fastly. Fastly is something that comes coupled with cloud service. So Akamai would be in front of Fastly. In that case, yes, there would be two CDNs. And I’m sure there’s some, there you go, document on experience league. Yes, Fastly is what is coupled with cloud service and there’s no option of removing that. Thanks everyone.