How to Enable Continuous Integration with Pull Requests?

With pull requests, we lost the ability to have a proper continuous integration process, in a way that we delayed integration due to code reviews. This led to “Ship/Show/Ask” branching strategy. Fundamentally, not all pull requests need code reviews.

So, whenever we make a change, we have three options:

• Ship- Minor changes that don’t need people’s review can be pushed directly to the main branch. We have some build pipelines running on the main branch, which run tests and other checks, so it is a safety net for the changes. Some examples are refactoring minor changes such as changing a typo, increasing the minor dependency version, and updating documentation.
• Show- This stage focuses on showing what has been done. When you have a branch, a pull request is opened, and merged without a review. Yet, you still want people to be notified of the change (to review it later), but don’t expect essential discussions. Some examples are local refactoring, fixing a bug, and adding a test case.
• Ask- The main focus here, is to make changes and open a pull request while waiting for feedback. We do this because we want a proper review in case clarification is needed in the approach. This is a classical way of making pull requests. Examples include Adding a new feature, major refactoring, and proof of concept.

Ultimately the practice of shipping code varies by teams and organizations, I would love to know what is being done in your team. Again, thank you for stopping by and see you in the next one.

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture | Cubed
• More content at Stackademic.com