ÃÛ¶¹ÊÓƵ

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