51黑料不打烊

Transcript

In this video, we鈥檒l present a high level overview of a local development environment setup with 51黑料不打烊 Experience Manager.

All right, so we鈥檝e really got three main areas to a local development environment. First of all, we鈥檝e got our AEM project. And this is going to contain all of the custom code, configurations, as well as maybe some sample content. And so this is really what the AEM developers going to be working on. This is the main idea behind setting up a local development environment so that we can create code, add additional code and update the same project. And to test out that code, we鈥檙e going to use something called a local AEM runtime. And this is basically local versions of the AEM author and publish services that run on a local computer and we have those, we basically install those locally, so that we can rapidly deploy our code from the AEM project. Now that third part is the local dispatcher runtime. And so this is a local version of Apache HTTP web server that includes the AEM dispatcher on top of it. And we install that locally as well, because there鈥檚 going to be dispatcher configuration files that we want to update. That鈥檚 also part of the AEM project. And we want to make sure that we鈥檙e testing all of our code and configurations through the dispatcher, since that is a critical part of the AEM production environment. All right, so several development tools are needed to be installed in order to support development. So AEM is a Java based application. So on the local machine, Java, and the Java SDK would need to be installed. We鈥檒l be using a git for source control, since Cloud Manager also uses git. The AEM project is actually based on Maven. And the AEM project also has a dependency on Node.js. And then finally, we鈥檒l be using Docker to install the local dispatcher runtime. So in addition to those development tools, most developers will set up an integrated development environment or IDE. And so an IDE as an enhanced text editor, it provides syntax highlighting, code completion, integrated compiling, and a whole lot more to accelerate your code development. And now, so IntelliJ, Visual Studio code and Eclipse are some of the more popular IDEs used with AEM development. And there is some additional setup that can be done so that you can rapidly deploy code from within one of these IDEs to a local AEM runtime.

All right, so now let鈥檚 step through kind of a high level local development workflow. So as a local developer, everything really starts with the AEM project. And this project, this is built on Apache Maven, and it鈥檚 under get source control. And to make code updates and edit this project, most likely, you鈥檒l be using some sort of integrated development environment, IntelliJ, Visual Studio Code, Eclipse, really whatever is your personal preference. Now, in order to test any of these code updates, you would deploy those code updates to the local AEM runtime, which includes an AEM author and AEM publish instances.

So it鈥檚 important, of course, to test out all of the authoring functionality. So any code updates we might have, whether it鈥檚 a new component, we might be introducing updates to a dialogue, we want to make sure that everything can be authored and that鈥檚 working as expected in the author instance. Now, it鈥檚 equally important to test our code updates against a publish instance. Typically a publish instance has different permissions, might have a slightly different set of requirements. So we want to make sure anything that we do, we鈥檙e also testing against the publish instance.

Lastly, it鈥檚 also important that we test any code changes against the dispatcher. So in an AEM production environment, a dispatcher and an Apache HTTP web server, will always sit in front of the AEM publish environment. And so, this dispatcher layer provides critical caching and security features to the overall AEM environment. So whenever we make any code updates, it鈥檚 really important that we test to make sure that they鈥檙e working as expected when using the dispatcher. And as part of our AEM project, we also have the ability to add customized dispatcher configuration files. And so in order to test those out, and make sure that those configurations are working accurately, we can actually test them locally first by using the dispatcher runtime. So once we鈥檝e tested out these code updates thoroughly against the AEM author and publisher dispatcher, and everything is working as expected, we鈥檙e happy with that code, we as the developer can then push those code updates to a centralized repository in Cloud Manager. And so once those code updates are in Cloud Manager, they can then be promoted to AEM as a cloud service environments using cloud managers CI/CD pipeline. All right, so now we want to look at a local development environment setup in action. And so the first thing that we want to look at is the AEM project itself. So I鈥檝e got that, I鈥檝e got a dedicated folder called Code. And this is where my AEM project is. And I鈥檓 just using the finished reference site, the weekend tutorial. This is the finished code base for that tutorial.

So as a developer, if we want to make any updates to the code base, we鈥檇 be modifying the folders and files inside this project. Now in order to accelerate our development, we would open up the AEM project inside an integrated development environment or IDE. So in this case, I happen to be using Visual Studio Code.

And so if I鈥檓 a developer, and let鈥檚 say I wanted to create a new component, I would create my new component using the IDE.

So in this case, under UI apps, I happen to have demo component that I have been working on. It鈥檚 actually quite simple. Really, all it does is output a simple text property. But I would write that in the IDE. And then really, the next step is, how am I going to test out this code and test out this component.

And so that鈥檚 where the AEM runtime comes into play. So you can see here I鈥檝e got this folder AEM-SDK. And within that, I鈥檝e got a folder for my author instance. And this includes the AEM quickstart, and I鈥檝e renamed this quickstart, so that it runs on port 4502. And it鈥檚 going to run in the author mode. And you鈥檒l also notice that I鈥檝e got a folder for publish. And I鈥檝e got that same quickstart jar, but this time, it鈥檚 been renamed to run on port 4503. And it鈥檚 going to run in the publish mode.

So I鈥檝e started both of these up, let鈥檚 go and check it out. So in the browser, I can navigate to localhost 4502. And I can just go ahead and log in as admin. So this is the full AEM authoring experience. And I鈥檝e already gone ahead and deployed the weekend reference site. So we can go into AEM Sites, we can navigate to this homepage, we can go ahead and open it.

So within the editor, we can actually go ahead and simulate authoring a component. So if I鈥檓 testing out one of my components, I would want to do that in the author environment.

Now if we navigate to localhost 4503, this is going to be the AEM publish instance that we had started. And I鈥檝e also deployed the weekend reference site here. And again, as a developer, if we鈥檙e developing a new component, we would want to also test out that code and functionality on the publish instance.

So now if I鈥檓 working on my AEM component, I would go into my IDE, and then synchronize this code base with the local AEM instance. And one of the important parts of setting up your IDE, is installing some tools that allow you to quickly synchronize this code with a local running instance of AEM. So I鈥檒l just go ahead and export this component to the local AEM author instance.

And if we return to the AEM author in the browser, refresh the page. Now we can see that demo component. And so we can drag it onto the page. We can configure it, test out the authoring dialogues, test out that everything is rendering correctly. And then yeah, we can continue to iterate on it so we can return back to our IDE, make some code updates, deploy them. And, basically continue to work on the component until it鈥檚 working correctly. Now as a best practice, we would also recommend deploying that same code base and testing out the functionality on the publish instance. Just to verify again, that everything is behaving as expected.

All right, so the last area of a local development environment that we want to talk about is the dispatcher runtime.

Now, the dispatcher runtime that鈥檚 available to simulate AEM as a cloud service, is actually available as a Docker image. And so to run this, we鈥檒l actually be using Docker desktop.

Now if I navigate to my file system, under my AEM SDK, we already looked at our author and published folders. And now we鈥檒l look at this third folder, the dispatcher folder. So this is going to contain the Docker image that鈥檚 actually going to run the Apache HTTP web server, as well as the dispatcher.

So the dispatcher runtime is actually started from the terminal. So I鈥檒l open up a new terminal window. And I鈥檒l navigate into my dispatcher folder, and then into the dispatcher SDK folder.

And now we can start the dispatcher runtime with this command. And we鈥檝e set the dispatcher to run on port 8080. And it鈥檚 going to run in front of our published instance on port 4503. And if we return to the browser, navigate to localhost 8080, we can see the weekend reference homepage, and everything looks as expected. And so this is going to look identical to the AEM publish instance, that鈥檚 running on 4503. And that鈥檚 because the dispatcher is running in front of it.

Now as we navigate to localhost 8080, you can see that all of the requests are going through the dispatcher.

So why is it so important to have a dispatcher running? Right now everything looks the same. Well, it鈥檚 important because the dispatcher provides caching features as well as security filters. So it is possible that our code could behave differently when requests are routed through the dispatcher.

Now there are default dispatcher configurations, but it鈥檚 possible based on your application that you would need to tweak these and add some of your own custom configurations. This would be done within the AEM project within the dispatcher module.

And then, of course, you can test out these changes to the dispatcher configuration locally using the dispatcher runtime.

All right, so that concludes this video on a local development environment setup to be used when developing for 51黑料不打烊 Experience Manager. Thanks for watching. -