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.
Remote development systems
Follow these best practices on the remote development systems:
- Multiple teams can share development systems, which can depend upon geographical distribution of teams, system load, risk of teams making system-wide changes, and demand for system restarts.
- Build a team application layer that is built on top of the main production application. The team application layer contains branches, tests, and other development rulesets that are not intended to go into production. For more information, see Using multiple built-on applications.
- Put all necessary configuration information for the development server in a development application that you can maintain, package, and deploy on demand so that you can quickly start up new remote development systems.
- Create a branch of your production ruleset in the team application. For more information, see Adding branches to your application.
- Name the branch with the feature or bug ID from your project management tool so that you can associate changes with a corresponding feature or bug.
- Perform all development work in the branch in versioned rules. Use branches for targeted collaboration and so that you can use development best practices such as conducting branch reviews and monitoring application quality metrics. You can also quickly test and roll back changes before you merge branches.
- Do not do branch development on the source development system to avoid having multiple versions of the same branch on the both the source development system and remote development system. The same branch might contain different contents that conflict with each other.
- Avoid developing rules in unlocked rulesets. Lock rulesets to ensure that
rules are not accidentally and directly changed, because changes should be
introduced only when branches are merged. Use a continuous integration
server such as Deployment Manager to ensure that passwords to locked
rulesets are not shared publicly.
For more information, see Versions tab on the Ruleset form.
- Optional: Use release toggles to disable features that are not ready for general use. Using toggles allows you to merge branch content frequently even if some content is not final. For more information, see Toggling features on and off.
- Optional: Create formal review tasks for other members of the development team to review your content. For more information, see Creating a branch review.
- Optional: Use the branch developer tools to review the content and quality of your branch. For more information, see Reviewing branches.
- Optional: Lock the branch before you migrate it to the source development system. For more information, see Locking a branch.
- Avoid deleting a branch before you migrate it into the main development system.
- Delete a branch after you import it into the main development system so that you do not import older data or rule instances and unintentionally merge them into the main application.
- Maintain a branch only as long as you need it. The longer that you keep a branch, the likelihood increases that the branch will have conflicts, which can be difficult to resolve.
- Be aware that you cannot make some rule updates in branches, such as updates to application records, classes, libraries, and schema. Senior application architects on he team should make these changes directly on the main development system.
Source development system
Follow these best practices on the source development system:
- Use an established and reliable backup and restore process.
- Maintain high availability on the source development system so that development teams are not affected by extended periods of downtime.
- Limit and restrict developer access to the main development system so that developers cannot make impromptu application changes without going through the DevOps workflow.
Previous topic Understanding development best practices working in a shared environment Next topic Understanding the DevOps release pipeline