Development workflow
In a DevOps workflow, the most important best practice for application developers to adopt is continuous integration. Continuous integration is the process by which development changes to an application are integrated as frequently as possible, at least once a day and preferably multiple times a day, every time developers complete a meaningful unit of work.
To enforce best practices when developing an application and to ensure that application changes are of high quality, developers should use Pega Platform features such as branches. Before merging branches and integrating changes, developers should also verify that the application meets guardrail compliance and that unit tests pass. If the validation of development changes passes, the branch is merged into the application ruleset.
However, if validation fails, then the merge is rejected, and developers should be notified so that they can address the failure and resubmit their changes. The feedback cycle of validating and integrating development changes should be as fast as possible, preferably 15 minutes or less, because it increases productivity in the following ways:
- Developers do not spend unnecessary time to see that their changes are valid, which enables them to make incremental changes.
- Incremental changes tend to be easier to validate, debug, and integrate.
- Other developers spend reduced time coordinating making changes and can be confident that they are building on validated functionality.
How you implement best practices for continuous integration depends on whether you have a smaller scale development with one or two scrum teams using a shared development environment or multiple distributed development teams. See the following topics for more information:
- Understanding development best practices working in a shared environment
Development environments can be shared by one or more teams collaborating on the production application. To practice continuous integration, use a team application layer, branches, and release toggles.
- Understanding development best practices in a distributed development environment with multiple teams
If you have multiple teams working on the same application, each team should have a separate, remote development server on which developers work. A central Pega Platform server acts as a source development system, which allows teams to integrate features into the application in a controlled manner and avoid unexpected conflicts between teams working in the same rulesets.
- Adding a branch from a repository
If you are working in a continuous integration and delivery (CI/CD) pipeline, you can add a branch from a repository to your development application. You cannot add a branch that contains branched versions of a ruleset that is not in your application stack.
- Publishing a branch to a repository
If you are using a continuous integration and delivery (CI/CD) pipeline with third-party tools such as Jenkins, you can publish a branch from your development application to a Pega repository on the main development system (remote system of record) to start a merge.
- Understanding rule rebasing
If you are using continuous integration in a CI/CD pipeline with either Deployment Manager or third-party automation servers such as Jenkins, after you merge branches, you can rebase your development application to obtain the most recently committed rulesets. Rebasing allows development teams working in separate development environments to share their changes and keep their local rule bases synchronized. Having the most recently committed rules on your development system decreases the probability of conflicts with other development teams.
Previous topic Understanding the DevOps release pipeline Next topic Understanding development best practices working in a shared environment