Rapid Frontend Development - Your Future Workflow

Transcript

Hello, welcome to this session. This is about the rapid front end development, basically your future workflow if you’re working on front end development or with front end developers. My name is Gabriel Wold. I’m still product manager for AMSides, right? We start to know each other. I’ve presented a few sessions here. Yeah, so let’s dive in. The agenda for this session, we’ll first quickly look at the current state, how the front end development works now more or less, then how we want to have it in the future. And then I’ll give you a quick demo of how that currently works. And we’ll end up with a few technical details just before you have the possibility to win the $1,000 in gift cards with the contest to build your own site templates. But we’ll come to that, right? So a lot of exciting things have been built already in AM Experience Manager. And these are really like pieces of a puzzle that come together. And like I’ve told already a little bit in the introduction session, roughly the direction into which AM goes is really into more automation, more front end centric features, but also we want to give more control to authors and basically with this allow to also kind of hand off certain tasks to the authors that don’t necessarily need to be always taken care by developers. So we have worked on a number of features to simplify this website creation process over these last years. There has been HTML template language, sling models we have introduced and the core components have made use of these two. The template editor is then coming into place to allow to edit the core components and to assemble the page templates and to configure all of that. Then the style system came in to basically allow you to have different variations of the same component and apply different class names to them. The grid system is there so that you can create a layout. The content and experience fragments actually also play a role in the site creation process because they allow you to maybe define things also on the templates that are recurring, like if you have a copyright string or legal text that you might want to introduce that could be a good usage for a content fragment as well, or experience fragments are actually used a lot in the template editor recently for creating the page header and future components to kind of assemble them together. And then together with the style system, you just apply a class name and you can have your header that then looks really as you wish. And the project archetype that kind of puts all of these points above into an easy way how you can bootstrap a website. So this is all nice. The traditional site creation flow, when you take all of this into account, goes roughly on high level like that, that you first do use this project archetype that I just talked about to create a new project. And then you actually can start to implement some components. You probably want to extend the core components that are existing and make sure that they match your design requirements and maybe create a few additional components. Then the front end developer can come in and start to create a theme for those and to implement the CSS and the JavaScript that should match the design requirements, after which actually all of that gets deployed again by the back end developer, who will basically update the production environment with what has been implemented. And at that point, the site author can start to create content. And that is really quite a back end centric process. It works well if you do have a lot of needs for customization and such, but the front end developer really relies heavily on the back end developers. They cannot really deploy much themselves. They don’t really have a good flow here to work independently. You can set up something. Most people who work a lot with AIM have created their own setup for front end developers to be efficient in this process still. But it shouldn’t be something that everybody does and reinvents all the time just to solve a common task. And the authors also are kind of at the end of the whole process here. So you need to at least have gone through that once. Maybe you can iterate afterwards, but at least once you have to go through the whole process before the content author can even start to create some content, which is kind of leading us in, even if we try hard to be agile and to take this maybe in iterations, but it’s really leading very much into a waterfall. And waterfalls are beautiful. I like them very much. It’s always a pleasure to sit by a waterfall, but in a project, you probably want to have something a little bit different. So let me introduce the rapid site creation process that we are proposing here. And this is really a tech preview here. So it is kind of a sneak peek that I’m giving you here. And you will have the possibility to join the beta program if you are interested here to play with this. So actually, we would like to start with a site admin. We would like to have some way inside of AM how we can create a site. So this site admin should be able to choose from a template, a site template at that moment, and to run some site creation wizard. And after that, actually, the site author could start creating content. I mean, if the template corresponds to what the website should look, why would you need any more work to be done here? You would be done on the whole setup part. You still have, obviously, after that, the deployment to set up the, I mean, mostly the dispatcher configurations and things like that. But on the AM side, you’re mostly done. Actually, you might want maybe to tweak the template that you have chosen. So only in that case, the front-end developer should be able to step in and to take the theme, the visual theme that the site template contains or proposes, right, and start to customize that and modify the CSS and the JavaScript of that site template. And the front-end developer should also be able to deploy that theme independently without requiring further back-end developers to help here. And back-end developers are still very much needed on projects, but they should only be needed really afterwards if there is more customization to be done. They shouldn’t be blocking the whole thing. And they might be starting before, they might be starting at the same time, or they might be starting afterwards, after the page author maybe has started to create some content already. I mean, the core components are there. They are ready to use out of the box. Why, if they are good enough, why should the site author not be able to start with that? So this is really the process. It doesn’t mean that you are not able to do any customizations. You’re still able to do them. But it shouldn’t be that those are blocking. And if you’re building a small site, maybe a microsite, it should be really maybe as simple as just create a site and create the content. So this introduces a few new concepts here. First, we need the concept of a site template, right, that we can initialize a website from. We need a site creation wizard to do the site creation. We need a front-end module somehow that allows the front-end developer to work independently here, and also then a front-end deployment pipeline or something like that that allows the front-end developer to deploy that after the work is done to the dev stage or prod environment. So the availability of this feature, as I said before quickly, is actually in a private beta. We estimate this to be available more generally for later 2021. And if you’re interested, you can already start to use that pipeline for you building your own site. I mean, the whole site creation process can already benefit from that. And it shouldn’t basically be a problem for you to go live if your site has been created with that process. So if you’re interested, you can join that beta program that is linked here. Now let’s quickly jump to a demo here. And I have here an AM instance that is freshly provisioned or could have been freshly provisioned. If we go into the sites part here, we will see that there is nothing here, nothing yet has been deployed. No code has been deployed. It’s really a vanilla AM instance that could have been just set up by a cloud manager. So here, what we have now is a new menu entry for create site from a template. And if I choose that, I can choose a site template that I can create the site from. But for that, I first need to go and fetch a template. We do have for now a basic site template that is made available here on this GitHub repository. And I can go here and download the latest release of that. So let me do that. I just download this zip file here. And on AM side, I’m uploading that here so that I can actually have a template that I can create a site from. So let’s select this one and create a new site. Let’s maybe, I don’t know, randomly call this site Adobe Developers Live and create the site. That’s it. And at this point, we are done. The website is here. It is fully functional. I can open that site. I can start to edit the site like any other websites that I would have deployed in that case maybe in the traditional workflow created with the archetype and deployed with a normal build pipeline. But here, I didn’t have to do any of that. I can take my content in context that it’s, I mean, all the features that you expect from a website are here. All the features that I listed before are available here. So that’s great. So here, we could change the title. And yeah, you see, fully functional. Now, let’s go into the next phase here. Maybe this site is not really branded yet to what I would like it to be. I mean, here, look at this template. It’s really super basic. As the name says, it’s really the basic site template that is kind of the boilerplate thing just. What I need to do here is to now download the template for the theme sources. So I can do that in the site wizard, site rail here. I can download the site sources here or the theme sources. And if I unpack this locally, I’ve done that already because I wanted to accelerate a little bit things. I have here this folder. Maybe let’s open that one in my favorite code editor and look at what it contains. What we see here is that this is really a very standard front-end project. It doesn’t contain anything that is specific to AEM. What it has is a readme. It instructs me to start with an npm install, so maybe we should do that. I mean, it will be fast here because I just did it before, and my computer is very slow these days. I’ll need to upgrade to a new one. But this is basically the only thing you need to do. And after that, what you can do is to run npm run live so that you can start a proxy server. Let me do that. Whoops. Not the right string. Copy it. Do that. Won’t work. There we go. So this will start now a proxy server that is run on localhost, and that will proxy the production environment from which I downloaded the sources. You could also configure it a little bit more so that you can proxy maybe a stage or a dev environment, but by default, this is the behavior you’re getting here. So I mean, here I could navigate to my page again. I will just open a link so that I more quickly get to the point here. But I now have opened the same page that we have edited before, but it’s on localhost 3000, and it’s proxied locally. What I could start to do now is to do actually a change in this project. I can go into the sources and maybe look at the few variables that are made available here. I mean, it’s maybe not very original, but I will just change the background to yellow maybe. I save the changes. On my machine, it takes a little bit of a few seconds here to rebuild the project. And once this is done, it will do a live reload of my browser instance that I have still open here on the background. Maybe I could open it to the background. And as soon as this build went through, you see that it does automatically update my page to preview the changes that I’ve just made. So this should allow the front-end developers to work quite independently from the AM instance. They don’t need it to have it running locally. They can proxy it. But they can really preview the content, how it looks on the actual website. Now after this is done, what you might want to do is actually to deploy this to GitHub. So I do have theme sources on GitHub. There we go. Yeah. This is basically I just wanted to access first this URL here. This is where I have checked in my theme sources after I have made some changes potentially. So now as a front-end developer, I’m checking these changes that I’ve done into GitHub. And the way we are now currently in the beta program, allowing to deploy these files is via a GitHub Action that is here in the GitHub Action tab. This GitHub Action actually really comes together with the site template here so far. So if you look at the sources, the site template already contains this GitHub workflow that I can use here. And here I can actually build and deploy my files to AM. What I need to do additionally in AM to make this possible is to update here the GitHub settings so that I actually have a reference here in AM to my GitHub settings. So what I would do here is basically just take this base URL of my GitHub repository and configure that here. And I would also need to give here a personal access token so that the two can communicate and are allowed to access each other. I will not do it here. I also need to do on GitHub, set up a few secrets so that GitHub also knows about AM and which site this should get deployed to. But once this is set up, it will be as easy as here running this workflow. Now I will not do it, but once this workflow goes through, it will update my site on AM and then I will get the changes that I checked into GitHub on AM. This is kind of an intermediate solution here. However, what we want to do instead of these GitHub actions is really to more tightly integrate this into the Cloud Manager pipeline. The idea here is that we also have the Cloud Manager pipeline to be able to deploy front-end artifacts in a way that doesn’t need to rebuild all of AM because this is what’s currently happening in the Cloud Manager pipeline when you deploy something. This is why it is actually quite fast for all the things that our Cloud Manager pipeline does because the Cloud Manager pipeline currently basically will rebuild all of AM with the code that you deploy into the JVM. It will test that AM still works properly. It will test your website that your website runs properly. It will test Lighthouse in Google Lighthouse Core and it will first deploy that to stage and if everything succeeds, it will then deploy to prod. It will then take down the production environment once the new or the production instances once you as soon as your new instance is up and running so that you have zero downtime. I mean, it’s a huge thing that the Cloud Manager pipeline does, but none of that is really necessary to just deploy a few CSS files. You don’t need to rebuild all of AM for that. So this will be very fast. It will create a pipeline into Cloud Manager that allows to deploy these kind of files super quickly and so that you don’t need to wait for all of that to happen and so that this is also actually possible to be executed by front-end developers without, if it fails, maybe not understanding if something actually failed because of a Java change in or a change in the Java code. So this is basically the demo that I wanted to show you here quickly and so that you have an idea of what is coming and as you have seen, some things are still being worked on, but it is usable for beta customers and if you’re interested, you can join that. Now let’s take a closer look at these things or the different concepts that I have just shown you. There is first the site template. The site template is actually this folder that contains the site content package. This is the first thing that the site template contains. This is a standard AM content package. So you can actually package anything in a site template that you can deploy as mutable content. You cannot deploy anything that is in apps or libs, but anything that is in conf or content can be deployed with this content package. It will take the path that corresponds to the given string. Basically it will replace the site template name with the site name that you initialize. So the content package can contain different places where maybe the site name occur and all of these will be replaced with the site name that you’re initializing so that every site name, the website that you initialize from this template is basically independent copy. The site template also contains the front end theme. So this is basically the CSS and the JavaScript sources for the website that you want to initialize. It contains a few preview files. This is used in the creation wizard, in the site creation wizard so that you can preview how the website is looking. For now we are just displaying one image. And it can contain further files. So you can package other files into there. It’s not limited. Typically what we want it to contain is maybe also the wireframe that correspond to the theme that you are having for that site template so that if you want to customize that, you could easily start already with the front end developer. So you could actually give this wireframe file then to the front end developers so that they can start with this theme and not maybe do too many changes if they are not necessary and so that the front end developer doesn’t need to re-implement things that might be already okay in the provided theme. And finally the site template has a package.json which is basically having all the build instructions and the metadata of the site template that is built here. What this build process does is that it will take all of that and package it into a template zip file. It will not just zip it. It will really build things. So there will be, if you actually unzip the site template, you will see that it contains further zips and actually it does contain also the theme in two flavors. It contains the theme in the packaged and compiled form that we can easily deploy and it contains the theme also with the sources so that if you want to download the sources from the template, you can do that later and give these sources to the front end developer. The wizard is actually quite basic. It just chooses the site theme. You can choose the site templates to upload there and you can configure a template site name. I mean as a result it deploys the, or it creates the content structure that the package of the template contains and it deploys the JavaScript and the compiled JavaScript and CSS from the theme. The front end module is as we saw in the sources, the standard NPM project. It requires no Java tooling such as Maven. It is allowing to do anything that you might want to do with NPM tooling. What we provide out of the box is some web pack and SaaS, but you could do whatever you want in there. It will build static files and these static files is basically what then will be deployed. AM will not compile anything past that point and AM also will not wrap the built theme into a client library. So we don’t rely at that point anymore to client libraries. The front end deployment pipeline is just deploying these files that have been built to storage that is behind the CDN. It deploys the file into a path that is timestamped so that the cache gets killed efficiently and AM will then be informed so that it can reference the latest path to the latest timestamp folder when it’s referencing the files in the HTML. And the core page component has actually already now a context-aware configuration. If you look at the core page component that is available there already. So this is basically what we’re using here to update the configuration of the site with the new location of the files and where they have been deployed. Important to know is that, like I said before, the only content package that you, or the only path that the content package can contain is what is in content.conf. You cannot deploy anything like custom components. So if a website does rely on custom code, like custom components, you would have to deploy them first and you could afterwards maybe still use a theme or a template that relies on these components, but you would first need to go through the backend pipeline and deploy them the traditional way before you can start to use that template for your website. That might be useful maybe if you are in a use case where you want to repeatedly create websites that maybe rely on custom components, that is fine, but you want to let your authors or your admins easily be able to create these sites. That is a good use case for that. And for the time being, you still need afterwards to go through the dispatcher configuration that needs to be deployed still manually. That is something that is still required at that point. That’s it. To the contest, you see here the URL if you want to join this contest. There are three gift cards that will give away for the three top winners. And the objective here is that you build your own site template and that you try to come up with something really cool and useful so that we could feature that. The top winner will also be featured in a blog post, and we can then also select the final list for the Rockstar challenge, the aim Rockstar challenge. So if you’re interested, if you want to take that challenge and use that feature, try to come up with a cool site template, go ahead, take this URL, and wish you good luck there. All right, that’s it. Here a few more URLs repeated again, the contest, the beta program, and the place where you can find the basic site template if you want to get started. Basically, we are at the end of this session, but since we have a networking break afterwards, I can stick around a little bit for those who would like to ask a few questions. I didn’t have the possibility to follow the chat pod, so if you want me to take some questions that you maybe have posted earlier, post them again so that I can answer to them live. Question, what quality measures are we planning to implement into the process so that from the end staff can be sure they don’t break the site while deploying their themes? Would they be part of cloud manager pipeline? So yes, they will be part of the cloud manager pipeline in the pipeline we’re implementing there. For the time being, this GitHub action is not having this, but you could set it up so that you deploy maybe first to a development environment, and you need to run maybe another pipeline so that it gets into a stage and prod. This is basically for now not yet automated. However, you can preview also the changes locally in the proxy server. After that, when you deploy it, they actually get deployed only to the author environment because this context-aware configuration first is only updated on the author instance, and you need to publish the site so that this context-aware configuration change gets replicated to publish. So this is how you can do it now or setting it up manually, but eventually it will be all contained in the cloud manager pipeline, yes. Second question, is this available for cloud and on-prem AM? For now, it is only available for cloud service and not on-prem or managed services. There are some pieces that might be useful also for other kind of environments, but for now it is really limited with the whole pipeline that we’re setting up and all these things for cloud service. We’ll see if we later maybe can take something to cloud manager, but that is later, and I cannot promise anything there, so for now it is cloud only, yes. If the CSS and JavaScript don’t depend from AM client lips, how will they be consumed in the live website? So we are deploying these files to an Azure Blob store, and these files are then available on a given URL through the CDN, through a public URL, and AM is just consuming or accessing that URL. It’s just referencing. Basically, AM is just referencing that URL. So these are just static files that are deployed to online storage. Okay, with that, we can wrap up. Thank you very much, and have a great rest of the conference. Bye then.