Continuous integration and delivery 

A continuous integration and continuous delivery (CI/CD) pipeline is an automated process to quickly move applications from development through testing to deployment.

The following image depicts the high-level overview of the Pega CI/CD pipeline. Different questions are asked during every stage of the pipeline. These questions can be grouped into two different categories:

• Developer centric questions – Are the changes good enough to share and do they work together with other developer changes?
• Customer centric questions – Is the application with the new changes functional as designed and expected by customers and ready to use by customers?
  

Drilling down to specific questions for each step in the pipeline:

• Ready to share – As a developer, am I ready to share my changes with other developers? Ensure that the new functionality being introduced works and critical existing functionality still continues to work.
• Integrate changes – Do all the integrated changed work together? Once all the changes from multiple developers have been integrated, does all the critical functionality still work?
• Ready to Accept – Do all the acceptance criteria for the application still pass? This is typically where the application undergoes regression testing to ensure functional correctness.
• Deploy – Is this application ready for real deployment? The final phase is where the fully validated application is deployed into production, typically after it was verified in a preproduction environment.

With continuous integration, application developers frequently check in their changes to the source environment and use an automated build process to automatically verify these changes. The Ready to Share and Integrate Changes steps ensure that all the necessary critical tests are run before integrating and publishing changes to a development repository.

During continuous integration, maintain these best practices:

• Keep the product rule Rule-Admin-Product, referenced in an application pipeline, up-to-date.

• Automatically trigger merges and builds using the Deployment Manager. Alternatively, an export can be initiated using the prpcServiceUtils.bat tool

• Identify issues early by running PegaUnit tests and critical integration tests before packaging the application. If any of these tests fail, stop the release pipeline until the issue is fixed.
• Publish the exported application archives into a repository, such as JFrog Artifactory, to maintain a version history of deployable applications.

With continuous delivery, application changes run through rigorous automated regression testing and are deployed to a staging environment for further testing to ensure that the application is ready to deploy on the production system.

In the Ready to Accept step, testing runs to ensure that the acceptance criteria are met. The Ready to Deploy step verifies all the necessary performance, scale, and compatibility tests necessary to ensure the application is ready for deployment.

The Deploy step validates in a preproduction environment, deploys to production, and runs post-deployment tests with the potential to roll back as needed.

Follow these best practices to ensure application quality:

• Use Docker or a similar tool to create test environments for user acceptance tests (UAT) and exploratory tests.
• Create a wide variety of regression tests through the user interface and the service layer.
• Check the tests into a separate version control system such as Git.
• If a test fails, roll back the latest import.
• If all the tests pass, annotate the application package to indicate that it is ready to be deployed. Deployment can be performed manually or automatically.