Understand ÃÛ¶¹ÊÓƵ Cloud Manager
ÃÛ¶¹ÊÓƵ Cloud Manager provides a simple, yet robust solution that allows easy management, introspects, and self-service of AEM environments.
Cloud Manager Overview
This video series explores the key features of Cloud Manager’s for AEM including:
For a complete overview, please review the Cloud Manager User Guide.
Programs programs
Cloud Manager Programs represent sets of AEM environments supporting logical sets of business initiatives, typically corresponding to a purchased Service Level Agreement (SLA). For example, one Program may represent the AEM resources to support the global public Web sites, while another Program represents an internal Central DAM.
Transcript
Cloud Manager for AEM, at the highest level, is broken into programs. A program represents a logical group of AEM instances supporting a customer initiative. A standard group of programs consists of a production environment, stage environment, and a development environment.
It is expected that the same initiative and codebase are used within a program. For example, an organization may have a program for their global websites running AEM Sites and AEM Assets and another program for their internal centralized DAM running only AEM Assets. Additional programs can be added to an organization by clicking the Add Program button. This brings up the Add Program Wizard where you can give the program a name and select the program objective. Note that licensing dictates how many programs can be provisioned per organization, and which program objectives are available.
Cloud Manager’s overview page provides a central view into a specific program. The program’s overview list environments in CI/CD pipeline and their statuses, as well as links to other supporting consoles. It also provides intelligent guidance at the top of the page recommending next actions, and at the bottom of the page, links to supplemental materials that can provide further information and support pertaining to the current state of the program.
Several configurations can be adjusted at the program level. To edit a program, click the edit program option in the program menu. The general tab allows us to change the thumbnail and description that helps Cloud Manager users to quickly identify a program. The KPI tab, or key performance indicators, has sections for any purchased AEM product that are part of the program. Here, we see KPIs for AEM Sites and AEM Assets. KPIs are configured at the program level and used by Cloud Manager’s performance tests, which are executed as part of Cloud Manager’s CI/CD pipeline. In order for the CI/CD pipeline executions to be considered successful, these KPIs must be met. -
Environments environments
Cloud Manager Environments are composed of AEM Author, AEM Publish and Dispatcher instances. Different environments support roles and can be engaged using different CI/CD Pipelines (described below). Cloud Manager environments typically have one Production environment and one Stage environment.
Transcript
Each Programming Cloud Manager is broken into environments. Environments are sets of AEM author and publish services, and every program can have one production environment, one stage environment, which is used to validate deployments. And depending on what has been purchased, one or more non-production environments, also referred to as development environments. Development environments may be used for various purposes such as development integration or quality assurance of custom code prior to deployment to stage for user acceptance testing and finally production.
The program’s overview page has a summarized view of available environments, including their status, indicating their general state. Individual environment details can be viewed by tapping View Details in the Environments, Actions dropdown. Or a more holistic view can be accessed via the Show All button or Environments in the top bar.
The environments view lists all the program’s environments their statuses, as well as the URL to the AEM author service which is used to access AEM. If any remaining environments are available to the program’s quota, the Add Environment button in the top right can be used to create the new environments.
Let’s go through the process now of creating a new environment for a weekend site.
Environment type defines the type of the new environment. Either a single stage plus production environment set or a development environment. The environment name is used to identify the environment and the environment description provides additional optional context about the environment. Finally, the cloud region allows you to select which of the available geographic regions the environment resources will be provisioned in. Back in the Environments view, tapping on a specific environment displays its details, including its information such as the author service URL, the region the environment exists in and the AEM release version it’s running. Environment segments provide the status of as well as direct URLs to each service tier. Note that both the published service for AEM and published service for dispatcher link to the same URL, as all access to the published service is always made through the CDN, dispatcher and back to AEM publish. Actions for each environment are available from the details view via the actions dropdown in the top right. Only the actions provisioned to the user are accessible. These same actions are available for each environment from the programs overview screen via the action dropdown next to each environment enlisted there. Download logs lets you download all the environments logs. Developer console opens the developer console, which provides further technical details about the state of the environment and running applications. Manage access opens ÃÛ¶¹ÊÓƵ Admin Console directly in the environment’s product context, where user access to AEM author service is managed. And finally delete which completely removes the environment including the code and content. -
Reports reports
Cloud Manager Reports provide a view into the Program’s Environments and AEM instances through a set of charts that report on and track various metrics for each AEM instance.
Transcript
Cloud Manager provides a number of insights into the operation and health of all managed environments.
Common metrics are exposed via simply a comprehensive graphing interface, providing key insights into the operation and health of the instances.
These graphs not only show the state of the environments, but also provide useful warning and critical threshold indicators, helping identify issues. Reports are split up by environment, and then optionally further by instance.
CI/CD Production Pipeline cicd-production-pipeline
Use the CI/CD Pipeline in ÃÛ¶¹ÊÓƵ Cloud Manager video series provides a deep dive into the Production Pipeline execution, including exploration of failing and successful deployments.
NOTE
Throughout these videos, the build, test, and deployment times have been sped up to reduce the time of the video. A complete pipeline execution typically takes 45 minutes or more (including the mandatory 30-minute performance testing), depending on the project size, number of AEM instances and UAT processes.
Configuration
The CI/CD Production Pipeline configuration defines the trigger that initiates the pipeline, and parameters controlling the production deployment and performance test parameters.
Transcript
Cloud Manager provides a robust CI/CD Pipeline allowing development teams to quickly test and deploy code to production. For example, implementation teams can set up, configure, and start an automated CI/CD Pipeline that leverages ÃÛ¶¹ÊÓƵ code best practices to perform a thorough code scan and ensure the highest code quality before having that code programmatically promoted up through stage to production.
This program does not currently have a Production Pipeline. Using the intelligent guidance from Cloud Manager, we can click Set Up Pipeline to create a new Pipeline. Setting up the program’s CI/CD Pipeline comprises the following configurations. First, specify the Git branch from which to pull the code that should be deployed. This is typically master, but can be any branch in a Cloud Manager Git repository. Whichever branch this may be, it typically receives control code changes as it represents candidate code for production deployments. Keep in mind these branches are sourced from the Cloud Manager Git repository rather than an organization’s on-premise Git repo or private Git hub repo. The Cloud Manager Git repository can, of course, be used as the canonical Git repo, but if this is not feasible, a different Git repository can be configured to push to the Cloud Manager Git repo, effectively creating a bridge between them. Next, configure how Pipeline deploys to stage and ultimately production environments. The top section configures how the stage environment will be deployed to. The deployment trigger configures how the build to stage will be initiated, manually trigger the build via Cloud Manager’s web UI, or automatically trigger a build on commit to the previously selected Git branch. The automatic trigger allows teams comfortable with CI/CD to rapidly and safely release code with minimum manual intervention. Keep in mind that while a Git branch is used for source code the result of building the code is one or more AEM packages. The AEM packages, or build artifacts, are what moves through the Pipeline, allowing the exact same artifact to be deployed to stage and eventually production, ensuring consistency between environments.
The Pipeline’s behavior for handling important failures is configurable as well depending on the organization’s tolerance. Note that this applies only to important failures. Critical failures will always prevent the Pipeline from progressing. The testing section for this stage, while grayed out, is actually permanently enabled requiring static code, load performance, and security testing to complete and pass prior to allowing the artifact to be deployed to production. Before the Pipeline passes through the stage environment, a predefined set of product functional tests must be passed. The product functional tests are defined by ÃÛ¶¹ÊÓƵ and perform basic functional tests that ensure that the Author environment and Publish environment continue to work as expected. Custom functional tests are a series of tests defined by the product’s code base. These are expected to be specific to a customer’s code base and content. They can range from test against the homepage to validation of certain groups and personas. The next section defines how the Pipeline deploys to the production environment. This section of the Pipeline is only engaged at the stage and build passes and all quality gates pass or are overridden. Deployment options include GoLive approval requiring a manual acceptance in Cloud Manager before deploying the artifacts to production. A production deployment can also be scheduled for a specific time in the future to help coordinate with marketing initiatives or other extra AEM dependencies.
The experience audit tab will run a series of audits based on Google Lighthouse criteria. These audits will test a selected pages for performance, best practices, accessibility, and SEO. The scores for each of these categories will be persisted and displayed on subsequent deployments. This allows a customer to see historical averages and ensure that new code does not adversely affect any of the scores. The audit will also identify any significantly slow or underperforming pages. -
Pipeline Execution
The CI/CD Production Pipeline is used to build and deploy code through Stage to the Production environment, decreasing time to value.
Transcript
Once the Production CIC Pipeline is configured, it can be rung repeatedly to promote code through stage to production. Configuration can be quickly reviewed on the overview page in the Pipeline card settings and reconfigured as needed over time. Since our Pipeline is configured to be triggered manually, the start new deployment button in our intelligence guide at the top can be used to start the new Pipeline execution. There are three phases for a production pipeline. Stage deployment, stage testing and production deployment. A simple validation check is initially run to quickly verify that a valid project is being deployed. The next step is build and unit testing. Cloud Manager will tag the latest commit of the configure to get depository branch with an auto generated release version. The tagged get commit is then checked out and a build is reformed against the code’s maiden project, which executes all test units created by the development team and generates the version release artifacts, which consists of one or more AEM packages. The build version artifacts are then stored by Cloud Manager, allowing the exact artifacts to be deployed to stage and eventually production.
Next, the source code is run through Cloud Manager’s code scanning gate, which performs static code analysis, ensuring AEM development best practices have been met. After code scanning has completed, we can click review summary, where we can review which checks have passed and failed. Only critical fails will absolutely block the pipeline. Important failures can be overwritten. It’s worth noting, all the quality gates, code quality, security and the performance can be either pass, partially pass or fail. Partially passing quality gates, which indicates at least one non critical quality metric failure can be overwritten. Failure of critical quality metrics can not be overruled and result in an immediate termination of the pipelines execution. Next is the build images step. In this step, the customer built artifacts are combined with the latest AEM release to produce an image runable in the Cloud.
The next step in the Pipeline is deploy to stage. In this step, the images built in the previous step are deployed to the stage environment. It should be noted that the stage deployment and all other deployments in Cloud Manager, use a rolling deployment strategy that ensures that users experience no down time or interruption of service. Once deployment to stage has completed, the Pipeline moves into the stage testing phase. The first step is production functional testing, in which server site integration tests, defined by ÃÛ¶¹ÊÓƵ, are run against the live staging environment to ensure quality. The next two steps, custom functional testing and custom UI testing, are defined by a customers project. The testing is expected to be specific to the customers application.
The last step in stage testing is the experience audit, where the live content is validated against a set of rules to check content quality, performance and user experience. Finally, upon passing all of the stage testing steps, the images are rolled out to the production environment. Once again, a rolling development strategy is used to ensure that users experience no down time or interruption of service. -
CI/CD Non-production Pipelines cicd-non-production-pipeline
CI/CD Non-production pipelines are broken into two categories, Code Quality pipelines, and Deployment pipelines. Code Quality pipelines all code from a Git branch to build and be evaluated against Cloud Manager’s code quality scan. Deployment pipelines support the automated deployment of code from the Git repository to any Non-production environment, meaning any provisioned AEM environment that is not Stage or Production.
Transcript
Non-Production Pipelines are paired down versions of the Production Pipeline. There are two types of Non-Production Pipelines, Code Quality Pipelines and deployment Pipelines. Code Quality Pipelines provide a great way for developers to check their code for quality early and receive feedback, enabling them to quickly and iteratively improve the code during the normal development cycle. All while reducing the chance of Code Quality failures when the code ultimately enters a Production Pipeline. Code Quality Pipelines are associated with a single name branch in the Cloud Manager Git repository. This means any code run through the Pipeline needs to have either its own branch that has a corresponding configured Code Quality Pipeline attached to it, or it must be merged into a branch that has a Code Quality Pipeline already registered to it. There’s no limit on the number of Code Quality Pipelines. And typically, each developer has their own dedicated Code Quality Pipeline they push the code to, as they deploy their code. Code Quality Pipelines can be set to be triggered manually or on Git changes based on the developer’s preferences.
When triggered, Code Quality Pipelines build the code, execute unit tests, and run the code through Cloud Manager static Code Quality Analysis, as well as build the final deployment image, providing the results in the usual fashion on the Pipeline execution screen. All results, positive or negative can be reviewed and downloaded in detail. The other type of Non-Production Pipeline is the deployment Pipeline. The deployment Pipeline is used to deploy code from Cloud Managers Git repository to a non-production AEM environment such as development or QA. The main difference from the Code Quality Pipeline is that a non-production environment is selected during configuration. Non-production environments can only have a single deployment Pipeline attached to them. Since our program has a single non-production environment, the dev environment, it only supports the creation of a single non-production deployment Pipeline. The same paradigms of selecting the source Git branch and development trigger apply. Additionally, since the end result of this Pipeline is the deployment to the non-production environment, the failure behavior can be specified, allowing the deployment teams to control what gets deployed.
Building the development Pipeline executes the usual build unit tests and Code Quality checks, and the AM image is built. Assuming prior steps are successful or approved, the build is deployed to the non-production environment associated with the Pipeline. Since these builds are not intended to be production candidates, the artifacts are non-versioned and not saved by Cloud Manager for use later. Deployment Pipelines allow development and QA teams to rapidly and iteratively deploy builds to a shared non-production environment. A common practice is to automatically build and deploy to a development environment whenever a change is committed to the develop Git branch, allowing developers to smoke test their work alongside one another in an integrated development environment. Likewise, the quality assurance team can set up a deployment Pipeline to their own QA environment using the manual trigger and at coordinated intervals deploy the latest code to this environment to execute their test scripts. Quality assurance tends to use the manual trigger so as to prevent changing code out from under tests being executed by their team. -
Activity activity
Cloud Manager provides a consolidated view into a Program’s activity, listing all CI/CD Pipeline executions, both production and non-production, allowing visibility into the past and present activity, and any activity’s details can be reviewed.
Cloud Manager also integrates at a per-user level with ÃÛ¶¹ÊÓƵ Experience Cloud Notifications, providing an omnipresent view into events and actions of interest.
Transcript
The Cloud Manager Program’s Activity tab provides a unified view of all the program’s pipeline actions, past and present. Each instance of a pipeline execution, production and non-production alike, show up as entries in Activity view. Clicking into the details shows the state of the pipeline execution allowing past executions to be revisited in detail or re-engaged with running pipelines.
On a per user level, Cloud Manager also integrates with the Experience Cloud notifications providing a proactive accessible view into Cloud Manager-related events and actions, such as the triggering of a pipeline, it’s failure, or successful completion from anywhere within ÃÛ¶¹ÊÓƵ Experience Cloud. -
recommendation-more-help
c92bdb17-1e49-4e76-bcdd-89e4f85f45e6