Using Adobe Cloud Manager - CI/CD Production Pipeline using-adobe-cloud-manager-ci-cd-production-pipeline

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 Adobe 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 Adobe 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. -

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 Adobe, 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. -