Defining a release pipeline
2 Tasks
20 mins
Scenario
The first delivery of the event booking application is targeted for production within 90 days. Front Stage wants to deliver new application features and fixes daily by the end of the year. Front Stage believes frequent improvements to the application helps them gain an advantage in the event booking market. The Front Stage architecture team thinks a Continuous Integration/Continuous Deployment (CI/CD) model is the best way to meet this objective. Front Stage does not currently use any automated deployment practices or testing tools.
Your team of three developers creates the first release of the application at Front Stage headquarters. Front Stage plans to hire five new developers based in Poland to support new feature development and bug fixing. Front Stage wants to move to a distributed development model within six to nine months, starting with the Event Booking application. Front Stage also envisions every developer working in a local environment by the end of the yea.
Recommend a release strategy and plan to structure the development teams and environment to support Front Stage's need to deliver new features and bug fixes daily after the first production release..
In your recommendation:
- Explain how to manage the work of the development team to deploy the first release application.
- Recommend an approach for moving to a CI/CD model.
- Describe how the two teams work together in a distributed environment.
Detailed Tasks
1 Review solution details
For the first release, you can apply the standard release process as described in the Pega Community. To support development and deployment tasks during this first release:
- Identify someone to fulfill the role of Release Manager (responsible for managing ruleset versions and overseeing the schedule)
- Use the prpcServiceUtils tool for service-enabled scripting to migrate rules between environments manually. The preferred method is to implement pipeline automation for the first release using Pega’s Deployment Manager. However, this infrastructure is not readily available.
- Introduce branch reviews, guardrails, unit testing, and branches and branch rulesets in the non-pipeline model before implementing an automated release pipeline.
After the initial release, work with the Front Stage architecture team to develop an automated pipeline for implementing CI/CD.
Your recommendation includes the following actions:
- Bring someone onto the team with automation server, repository, and CI/CD experience
- Determine the automation server and repository to use
- Describe how the automation server invokes automated testing tools, such as PegaUnit
- Identify release tasks to be automated and in what time frame
Your recommendation includes the following actions:
- Identify a release manager to oversee the pipelines
- Identify who creates new ruleset versions and branches in the system of record
- Determine and communicate the process for handling import conflicts
- Communicate the frequency of development environment rebase
- Establish pre- and post-import tasks, such as notifications and testing, to refine and improve the continuous integration process
2 Review solution alternatives
You can also propose moving to a CI/CD model for the first release. Because Front Stage does not already have a CI/CD model in place, attempting to implement this type of change could put the goal of delivering the application in the 90 days in jeopardy. You can introduce the practice of unit testing individual rules, developing test suites, and delivering rules to target environments in an automated way by using the Deployment Manager or the prpcServiceUtils utility. This approach prepares the organization for automating the delivery pipeline as the organization's CI/CD processes mature.
Available in the following mission:
Want to help us improve this content?