In this video, we’ll take a look at how the fictional WE.RETAIL organization would work in the context of Adobe managed services. Cloud managers, CICD pipeline. CICD allows implementation teams to quickly build, test, and deliver code to AEM environments, including production, in a safe and consistent manner. Cloud manager organizes AEM instances by program, which more or less describes an AEM deployment with one production environment and at least one pre-production environment. An organization can have multiple programs. If they have multiple AEM deployments. For example, WE.RETAiL has one for their global websites, another further enterprise dam and a third for their intranet. Let’s click into WE.RETAIL’s global websites program, and we’re greeted with an overview page that displays a summarized state of the program, including the AEM environments, contextual guides that signal the likely next action for the program as well as links to the best practices and documentation based on the program’s current activities. So, we can see that we have two environments provisioned for our program stage and production. And these are the environments we’ll be deploying, using the pipeline. -

So we take a look at our contextual guide at the top. It correctly suggests that we should set up our pipeline. So, let’s do that. The first thing we need to configure is the code repositories branch. Cloud Manager uses a hosted Git repository to maintain the application source code. The pipeline must be set up to pull code to build, test and deploy from a single branch in the Git repository. Typically, there’s a Git branch that holds release-ready code, often named master. When and how code gets into this branch is determined by the development team’s processes. For this video, we have two branches set up that we’ll switch between. The yellow branch will help us see a failing pipeline execution, and then we’ll use master to see what a successful pipeline execution looks like. So, let’s select the yellow branch for now. Next, environments configure how the CICD pipeline will interact with each AEM environment. In the stage AEM environment configuration, we can select one code from the previously selected Git branch will be built and deployed to the stage environment. And we have several options. On Git changes, which means whenever there is a commit to the selected branch, that code will be automatically built and deployed. Manual, which requires a Cloud Manager user to manually invoke an action to deploy the selected branch. Or scheduled, which allows the code in the selected branch to be built and deployed at some set interval. For instance, every Thursday at 5:00 PM. Let’s choose manual. Over to the right under the testing heading are indicators of what testing must be completed for this deployment to be considered successful and eligible for promotion to the next environment, in our case production. This is showing the Cloud Manager default quality checks of static code testing, load and performance testing and security testing. And they’re all required. We’ll take a look at how we can configure the test parameters in a moment. Below stage is the next environment which is production. And we have a slightly different set of deployment options. And this is because it’s the production environment. So, it enjoys some special treatment. Here we specify if deployments to production require Go-Live approval, which requires a Cloud Manager business owner, product manager or deployment manager to log in and explicitly approve the deployment. Use CSE oversight, which requires the involvement of an Adobe Customer Success engineer to support the deployment. Though note, this is only available to programs assigned to CSE. And scheduled, which allows a future date and time to be selected for the deployment. Let’s let Go-Live approval for our example. Lastly, let’s head over to the testing tab. Here we can configure the testing parameters for the pipeline. Since this program is for the We.Retail global websites, we have the option to configure a few settings for site content delivery. Peak page views and max response times are set up at the program level. And the 30-minute test duration is the standard time for Cloud Manager performance tests. Know that the peak page view and max response times can be updated at the program level at any time. Cloud Manager provides smart sets of predefined pages to test against. These options make it easy to ensure that the performance and load testing are representative of real use once the code is deployed to production. Once we’re happy with our pipeline configuration, we can save it. And remember, you can go back at any time and edit these. -

Okay, we’ve finished setting up the pipeline. The next step is to use the pipeline to build the Deployer code to production. Let’s use the contextual guide at the top and click deploy code to try this out. Since we can configure our stage deployment to be manual, we must first kick off a build of the configured git branch. Remember, we’ve selected the yellow branch, which has code we know will not pass our quality tests, so we can see what a pipeline execution failure looks like. This will take a few minutes, depending on the size of the AEM project. We’ve been alerted the bill has not passed all the quality checks, which is expected for our yellow branch. Let’s take a look at the output. We can see the first set of quality checks which runs is the build of the Maven project, which also runs the unit tests, which are the build time tests written by developers to test the code, often using a unit testing framework like JUnit. The good news is our unit tests all passed. The Maven build log is available for download, which is, of course, most handy when the checks fail, as it shows exactly which unit tests didn’t pass, or where the build failure occurred. Next, we see our static code scanning test fail. This test runs the application through a set of AEM best practice SonarQube rules, performing a static code analysis, checking to ensure the cod adheres to development best practices. Reviewing the results gives us a high-level summary of what passed and what failed, in this test. We see the deployment failed because the code’s critical security rating is an E, and a rating of a B is required for deployment. Ideally important, an information failure should also be resolved, but these will not block the deployment. The details of all the failures can be obtained by downloading the details as a CSV file, which includes the offending code files, line numbers, issue descriptions, and the violated static code analysis rule IDs. This report can then be handed off to the development team, so they can quickly understand what needs resolution. Okay. So, at this point, the deployment stages stopped, due to the failures to meet the minimal level of quality. -

So let’s see what a successful build looks like. For this, we’ll head back to the overview and configure the pipeline settings to pull from the master branch.

Let’s deploy again.

And we can see our build and unit tests have passed, as well as the previously failing code scans. Because all the quality checks had passed, the code has been automatically deployed to stage. Let’s take a peek at the deployment logs.

These include information about how Cloud Manager has automatically backed up the IAM instance, detached the IAM instance from the load balancer, ensuring the IAM instance doesn’t accept traffic during deployment, deploying the application packages, and finally reattaching to IAM instance to the load balancer so it can resume accepting traffic. Note that this will perform a rolling deployment across all AEM instances in the stage environment.

The next step in our pipeline is pre-production testing which involves security and load testing against the stage environment. In our example, we see there’s an issue with security testing so we can review this. Luckily it looks like all critical or mandatory tests have passed, but there’s one failing test under Important. Because this failure is not critical, we have the option to override and continue with the deployment. Optionally, we could reject to the deployment and resolve this failure. But for this example, we’ll override so we can continue. Next are the performance tests which we configured in the pipeline settings. We configured this to evenly distribute the test traffic across live popular pages, live other pages or pages that didn’t make it into the popular cut, and new pages that exist on stage but not in production. The popular live pages are automatically derived by Cloud Manager, looking at real traffic pattern to the production IAM environment. This test runs for 30 minutes, so I’ll speed it up for the video.

All right, so we partially passed our performance testing, so let’s review the results.

We’ll see the usual critical, important breakouts with the critical test passing. There’s one failure under Important which tells us that we missed our target threshold of 200 pages per minute as we only obtain 174. Remember this 200 page views per minute is a configuration at the program level. Let’s override this failure and say that 174 is sufficient. At this point, the release has passed all of the automated tests and ready for any required user acceptance testing. Once the user acceptance testing on stage is completed, the release can be approved for production deployment. Note that when the deployment to production happens, Cloud Manager uses the exact artifacts deployed to stage and does not recompile from the git branch. This guarantees consistency in the release between all environments. Let’s continue our release and continue our path to production. If in our pipeline settings we had selected CSE support, the pipeline would notify the program CSE and pause for their involvement. Since we didn’t, the artifacts are deployed to production in the same rolling fashion as was done to stage.

So, each IAM instance in the production environment is backed up, taken out of the load balancer. The packages are deployed and finally the IAM instance is put back in the load balancer and resumed serving traffic. So, as you just saw, Cloud Manager makes getting code from source control into IAM environments safely and quickly easier than ever with minimal setup. So, before we end, let’s head up to the activity tab at the top. During this video, we ran through and promoted our code fairly quickly and it’s reasonable to imagine that the deployment manager may need to step away from their computer or have accidentally closed their browser tab during this process. All executions of the pipeline for the program are logged under the Activities tab so we can always see any active pipeline executions, as well as success and failures. We can always click into these to resume executing or review and collect the feedback and logs from finished executions. -