The Juggernaut of Pull Request!

One of the most path-breaking innovations as part of the Git effect is the creation of pull requests. In this blog we are going to cover:

1. What is a pull request?
2. The juggernaut of the pull request.
3. The innovation gap.

What is a Pull Request?

In its simplest form, a pull request is a mechanism that allows a developer to notify other stakeholders (in the DevOps pipeline) that:

1. The developer has done all the changes needed for a feature.
2. Changes are ready to be merged to the main branch as per the developer.
3. Other stakeholders now have the opportunity to validate, test, and give comments.
4. Once changes are approved, they will get merged to the destination branch.

A pull request is much more than a change though. It is the whole space or a project in which a change resides during its life cycle. Every stakeholder can comment in a pull request. Multiple commits can be done in a pull request with a back and forth feedback loop. Even incomplete code can be committed to a pull request if a developer needs help from another team member.

The Juggernaut of Pull Request

Every innovation big or small is creative destruction. Pull requests are also destroying a lot of legacy artifacts and creating space for new ones.

R.I.P. Permanent Branches

Branching for a long-time was considered the swiss army knife of source-code control systems. They were used in a myriad of ways:

• branches for features
• branches for developers
• branches for different environments
• branches for major releases
• branches because someone in the development team felt like having a branch

Due to this indiscriminate use, branching became a disaster. You would find as many horror stories of branching failures as the number of people you get an opportunity to ask. There may even be some supporters of branching. We are not going to focus on that debate in this blog. What we are going to focus on is the primary weakness in branching strategy which made branching dangerous. The weakness was the permanent nature of branches.

As soon as branches are made ephemeral, all the negative effects of branching disappear. This is made possible by associating a branch with a pull request. Pull request is a dynamic artifact that is created for a purpose. As soon as purpose (the successful merge) is served, the pull request life-cycle gets over. If a branch is associated with a pull request, it will have a coincidental life-cycle with the pull request.

R.I.P. Legacy Pre-Production Environments

The legacy pre-production environments are as static as the legacy branching. With the dynamic nature of pull requests, every pull request has a nuanced definition of the environment it needs. A few examples of the static nature of legacy environments are:

• a static QA environment may be running all the tests but a pull request may actually need a subset of those tests and that also specific version of services in it.
• A static QA environment may be running mock services.
• A static staging environment may have data that has significant drift from the production, as it’s a lot of painstaking manual work to get clean data from production.

The Innovation Gap

There is a need to make every other artifact in the DevOps pipeline ephemeral to maximize the synchronicity with a pull request and maximize the productivity gain. One such example is short-lived branches on the architecture side as we discussed. The biggest gap which needed to be filled was on the environment’s side. There was a need to create ephemeral dynamic environments which exactly fit the need of a pull request (created to serve a pull request and nothing else). This gap is being filled with the Roost.ai Environments-as-a-Service platform.