High-level Process Lifecycle and Role of Pull Requests

Pull Requests (or whatever their equivalents are called in your favorite Git distribution) are a norm. Most of us have adopted them as the primary way of reviewing and accepting changes that will ultimately be deployed to production. They work hand-in-hand with feature branches.

🔍 Some of you might cringe thinking about pull requests. You might prefer trunk-based development, and work directly on master. Even if that is your preference, I still recommend you go through this chapter and do all the exercises. If processes were manual, getting pull requests merged would be a slow, hands-on, and time-consuming effort. If you use pull requests, you should use automation to speed up the process, and reduce the human effort required. That’s precisely what Jenkins X is doing for us. So, put your reservations about pull requests aside, and follow along.

High-level process of a lifecycle of an application

A common (and recommended) workflow is to create a new branch for each feature or change we want to release. Once we create a branch dedicated to a feature or change, we either work locally or in DevPods until we are satisfied with the outcome. From there on, we make a pull request, which should execute a set of automated steps that will deploy the preview and validate it. If all the steps are successful, we might have some manual actions like code review. Once finished, we merge the pull request and that, as you already saw, results in yet another round of automated tests that end with the deployment to one or more environments (those set to receive new releases automatically). Finally, the last step is to promote a release to production whenever we feel we’re ready (unless the promotion to production is set to be automatic). Hopefully, the whole process from creating a branch all the way until it is deployed to permanent environments (e.g., staging, production) is measured in days or even hours.

The high-level process of a lifecycle of an application usually contains the following steps:

1. Create a feature branch
2. Work on the feature locally or through DevPods
3. Create a pull request when the feature is ready
4. Deploy the preview
5. Execute a set of automated validations that will confirm that the pull request works as expected
6. Review and approve the pull request
7. Create, deploy, and validate a new release in permanent environments (e.g., staging)
8. Promote the release to production (unless that part is automated as well)