Upgrading Without Stopping: Development Strategies and Environment Planning

Before the hands-on upgrade work begins, it is critical to establish a strategy that allows the upgrade to proceed in parallel with normal, business-as-usual (BAU) development. Freezing your project's main branch for the duration of a potentially multi-week upgrade is not a viable option.

This guide outlines the best practices for setting up your code branching and environment usage plans to ensure the upgrade work is isolated but not divergent, allowing both your upgrade team and your BAU team to work productively and without conflict.

The Code Strategy: Isolate with a Long-Lived Upgrade Branch

The core of a parallel development strategy is to isolate the upgrade work in a dedicated, long-lived branch. This creates a separate workspace for the upgrade team while allowing the BAU team to continue merging new features and bug fixes into the main branch as usual.

Action: Create your upgrade branch.

• Create a new branch from the latest version of your main branch. A common naming convention is feature/platform-upgrade-v2.8.

Action: Establish a process for staying in sync.

An upgrade branch that is never updated from main will quickly become impossible to merge. It is essential to have a regular process for incorporating ongoing BAU development into your upgrade branch. This is covered in detail in the documentation's guide to Ongoing development during upgrades.

The key activities for the upgrade team are:

• Rebase Regularly: On a consistent schedule (e.g., weekly), rebase the upgrade branch against main. This pulls in the latest BAU changes incrementally, making the final merge much simpler.
  
  
• Maintain a Changelog: As you work, keep a simple changelog. Note down any changes or decisions made that will impact other developers when the final upgrade is released (e.g., "The custom-function-x has been replaced with the new new-native-function-y").
  
  
• Update Your Trackers: Keep your issue and effort trackers up to date. This provides real-time visibility on progress and ensures knowledge is not lost.

The Environment Strategy: Plan for Shared Resources

Just as your code needs to be isolated, your execution environments need to be managed to prevent conflict. Upgrade tasks, particularly full batch runs, can be resource-intensive and interfere with other development or testing activities if not properly coordinated.

Action: Define your upgrade environment.

Designate a specific development or test environment for the upgrade work. This ensures that the upgrade team's activities, such as running a newly migrated ETL process for the first time, do not impact BAU sprint testing in another environment.

Action: Establish communication protocols for shared resources.

Your project likely shares key infrastructure components like a Spark or Elasticsearch cluster across multiple teams or use cases. It is vital to establish clear rules of engagement to avoid contention.

Your project should have a defined process for:

• Announcing when resource-intensive batch jobs will be run (e.g., via a dedicated Teams/Slack channel).
  
  
• Distinguishing between short, small jobs and long-running overnight jobs.
  
  
• Resolving prioritization conflicts if two teams need to run large jobs at the same time.

For larger programmes, a brief daily stand-up focused on cluster usage can be highly effective for aligning priorities across teams. By clearly communicating intentions, you can prevent most environment-related conflicts before they happen.