Defining a release pipeline
Archived
2 Tasks
10 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 on a daily basis by the end of 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 develop the first release of the application at Front Stage headquarters. Front Stage plans to hire a team of 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 year.
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 Solution detail
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 nonpipeline 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:
- Bringing someone onto the team with automation server, repository, and CI/CD experience
- Determining the automation server and repository to use
- Describing how the automation server invokes automated testing tools, such as PegaUnit
- Identifying release tasks to be automated and in what time frame
Your recommendation includes the following actions:
- Identifying a release manager to oversee the pipelines
- Identifying who creates new ruleset versions and branches in the system of record
- Determining and communicating the process for handling import conflicts
- Communicating the frequency of development environment rebase
- Establishing pre- and post-import tasks, such as notifications and testing, to refine and improve continuous integration process
2 Solution alternatives
You could 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 begin to introduce the practice of unit testing individual rules, developing test suites, and delivering rules to target environments in an automated way using the Deployment Manager or the prpcServiceUtils utility. This approach prepares the organization for automating the delivery pipeline as the organizations CI/CD processes mature.