Establish a robust approach to development at the start of the project and document it so that the whole project team can collaborate most effectively to produce the highest-quality outcome.

Understanding your build and deployment process

A solid development practice starts with rule development and system configuration, and ends with a repeatable and secure process to move finished software from the development environment through to the production environment.

By organising your rulesets and applications by following best practices, you use experience gained over years of development and give yourself the best chance of producing a robust outcome.

Having a defined deployment process for your project team ensures that only finished developments are released to downstream environments and that all the necessary project stakeholders are aware. You give yourself the best chance of recovery should something go wrong.

You may already have an established change management process, so wherever possible, fit the development into that process so that your entire organisation can understand the way the Pega project is being developed and managed.

The process is usually defined by the project’s Lead System Architect (LSA) who works with your business and IT team to ensure that the process fits into your organization’s existing change management process, if any.

Configuring your build process

The following best practices help to ensure your development is robust and future-proof.

1. Have a dedicated ruleset version for each of your application rulesets for each sprint. Lock rulesets at the end of the sprint so that work done on each sprint is kept isolated and unique.
2. Have a separate application for unit tests. By creating an application that is built on your main application that only holds unit tests, you can be sure that unit tests only get deployed to the environments where you need them. For more information see Managing test cases separately in Deployment Manager.
3. Ensure that every rule that can be tested with a Pega unit test has at least one.
4. Have a separate application for your development. By creating a further built on application on top of your unit test application, you give a natural home for development branches to make releasing of the underlying application easier. You should consider having multiple development applications if your team is large and concurrent development is happening in similar parts of the application. For more information see Best practices for using branches with Deployment Manager.
5. Set up and test your DevOps pipeline as early in the project as possible. This gives the best chance of your deployment process being repeatable and robust and reduces any manual work when releasing your development to downstream systems.
6. Agree upon and enforce a minimum guardrail compliance score. Aim for as high as you can; always ensure that guardrail warnings are addressed or at least justified. Agree and enforce a process by which the LSA must review justified warnings above a given severity.
7. Agree upon and use a manual review step which must be completed before development can be released out of the development environment. This ensures that the project LSA has reviewed the development for correctness before it is released.
8. Agree upon which stage the Product Owner needs to make a go/no-go decision on promotion to downstream environments and ensure that this is reflected in your deployment process.
9. Finally, agree a definition of done that encapsulates these best practices and be sure to check that any user story is only marked as done when it meets that definition.

Outcome

Once you have followed the steps above, you will have a build and deployment process that the whole team follows for the duration of the project. By following the best practices, you can be sure that high-quality development is released in a repeatable way and that environments downstream of Development contain tested and accepted functionality.

Frequently asked questions about the build and deployment process and procedures

Should developers use private checkouts?

A private checkout is useful to allow a developer try something out quickly without having to copy a rule from a locked ruleset into the latest development branch. We don’t recommend using private checkouts for ongoing development though as it is easy to check-in a rule without realising that another developer may have changed it and checked it in whilst you had it privately checked out. This can cause you to check in an old version of the rule without realising.

How far down the environments should I release unit tests?

Unit tests should certainly be running on your Development environment, but it can be beneficial to release them (or a subset of them) to downstream environments too. This could be used to enable you to do automated smoke-testing of the release, particularly if you have a large set of static or reference data you need to ensure is up to date. It is not usual practice to release unit tests to Production, but do consider releasing them to your Test or Staging environments.

When should I use branches?

Get into the habit of creating a development branch for each user story or bug that you work on. Even if your project team is small, following a branch-based development process helps keep development isolated and makes it easier to manage multiple concurrent development tasks. Always delete the branch again once the work is finished and accepted by the Product Owner.