Unravelling the Code Tapestry: Learning the Release Process and PR Strategy

  • Friday, Apr 5, 2024
A number of coloured sticky notes are arranged on a pinboard. The sticky notes do have handwritten text on them, but they are out of focus, meaning that the text is unreadable

The cover image for this post is by Patrick Perkins

This is part eight in our series of blog posts detailing our system for genius when working safely with legacy code. The other parts of this series include:

  1. A Series On Safely Navigating Software’s Timeless Artifacts
  2. Preparing To Tame Legacy Code With User-Led Odysseys
  3. Conversations with Code Custodians
  4. Why Documentation is Key to Legacy Code Success
  5. Before Running the Build
  6. Documenting your Progress
  7. Accessing a Development Database for Local Testing

Introduction

In this part of our series, we’ll focus on understanding the release process and pull request (PR) strategy for legacy codebases. By taking time to learn these processes, you can ensure that your work is incorporated effectively into the system without causing disruption or unintended consequences.

Understand the Release Process

Investigate how releases are managed in the legacy codebase. This may involve understanding manual release processes (i.e. “copy to the server via SFTP”), gated automated deployments (i.e a DevOps pipeline with sign off), or fully automated release strategies (i.e. a DevOps pipeline without any kind of sign off). Regardless of the process involved, you need to respect it; some development projects will use the “older”, more manual, methods for deployment either because it just works or because the team haven’t had the time to invest in updating and upgrading their processes.

Whatever process used, make sure that you add it to the documentation that you’ve been compiling so far. This will provide a double-win in that it gives both you and the team a place to go when preparing a release of the code.

To begin with, familiarise yourself with the following aspects of the release process:

  • The deployment environments (e.g., staging, production), if any
  • Release frequency (e.g., continuous deployment, scheduled releases)
  • Any specific requirements or conditions that must be met before deploying new code (e.g., approval from a project manager or team lead)
  • Any rollback procedures in case of issues during or after deployment

Learn the PR Strategy

Take some time to understand the pull request process used by the team. Of course, this makes the assumption that the team has a PR strategy—if they don’t then it might be worth starting the conversation about using PRs. The last thing that you want, when working on legacy code, is to be able to accidentally push directly to the main branch; especially until you’ve understood the release process, or if the release process is completely automated.

Familiarise yourself with any preferred branching strategies (trunk-based vs. git-flow), collaboration practices, and merge methods (squash merges, rebasing, or merge commits). This will help ensure your work aligns with the team’s established processes and guidelines.

Some important points to consider when working with PRs include:

  • The process for creating, reviewing, and merging PRs
  • Any branch naming conventions that should be followed
  • Guidelines regarding commit messages and squash commits
  • Best practices for collaborating on code through comments, reviews, and discussions in the PR

Again, ensure that you document this.

Collaborate, Adapt, and Improve

Engage with other developers to discuss and suggest ways to refine the release process and PR strategy. The other developers on the team might be against making changes to the release process and PR strategy, but everyone has a voice in the conversation (including you). You may also be able to see gaps in the processes that others might not—they might not be able to see the wood for the trees, or they might have been stuck working with this legacy code for a long time meaning that they don’t have knowledge of current industry best practises.

If you are going to suggest any refinements, you will need to ensure that all relevant stakeholders are included in the conversation and that their concerns are taken into consideration. Make sure that you only propose changes which align with the team’s goals while considering potential impacts on existing infrastructure and workflows. Be open to feedback and be willing to adapt as necessary.

It’s important to remember that a release or PR process which works is infinitely more valuable than any other process that you might suggest. As such, you will likely see a little pushback. As with everything in development, don’t be precious about your suggestions as they will likely be shot down. And remember: just because it’s a practise that other teams or companies do, it doesn’t mean that it’s a best practise for either this team or this code base.

In Conclusion

This part of our series focuses on understanding the release process and pull request strategy within a legacy codebase. By familiarizing yourself with these processes, you can ensure that your work is incorporated effectively without causing disruption or unintended consequences. Be sure to collaborate with teammates, document best practices, and continually adapt and improve existing processes to maintain smooth development practices.

If you’d like us to help you work through the challenges involved with working safely with a legacy codebase, either in a hands-on capacity or as a consultant, get in touch with the form below

We'll never share your name with anyone else.
We'll never share your email with anyone else.
Providing a subject can help us deal with your request sooner.
Please be as specific as possible; it will help us to provide a more specific response.
Un-checking this box will ensure that your data is deleted (in line with our privacy policy after we have dealt with your request. Leaving this box checked will auto enrol you into our email communications, which are used for marketing purposes only.