Upgrade Bitbucket without downtime

To upgrade Bitbucket with no downtime, you'll need to perform a rolling upgrade. A rolling upgrade allows you to upgrade Bitbucket Data Center to a later bug fix version with no downtime. This involves upgrading nodes individually within a multi-node cluster. When you take a node offline to upgrade it, other active nodes keep your Bitbucket site available to users. This allows you to avoid downtime.

Bug fix upgrades only

Bitbucket only allows rolling upgrades for bug fix upgrades (for example, from Bitbucket 7.9.0 to 7.9.4). For platform upgrades (such as Bitbucket 7 to 8) or feature upgrades (such as 7.4 to 7.8), see Bitbucket Data Center upgrade guide instead.

Learn more about the different types of upgrades/versions    

Bitbucket Data Center features an upgrade mode that allows Bitbucket nodes with different bug fix versions to form a cluster. Upgrade mode lets you upgrade a node to a later bug fix version and then re-connect it to your cluster, letting you take another node offline to upgrade it.


On this page

Before you begin

Before you start planning a rolling upgrade, there’s a few questions you need to answer.

Does my Bitbucket deployment support rolling upgrades?

You can only perform a rolling upgrade with no downtime on a multi-node Bitbucket cluster. Clustering is only supported on a Bitbucket Data Center license. In addition, a rolling upgrade involves enabling upgrade mode, which is only available in Bitbucket Data Center.

Learn more about multi-node clustering in Bitbucket

Do I have enough nodes to support user requests during the rolling upgrade?

You need to take a node offline to upgrade it. During this time, other active nodes will take over the offline node’s workload. Make sure you have enough active nodes to handle user traffic at any given time. Whenever possible, add a node temporarily to your cluster to compensate for offline nodes.

Prepare for the rolling upgrade

1. Complete pre-upgrade checks

  1. Check the Version specific upgrade notes for the version you plan to upgrade to (and any in between).
  2. Go to  > Support Tools, then review the Log analyzer for any issues that may need to be resolved.
  3. Check the compatibility of your apps with the version you plan to upgrade to.

    1. Go to  > Manage apps > Bitbucket update check.
    2. Choose the version you plan to upgrade to then hit Check.

      If you have incompatible apps

      If your users rely on particular apps, you may want to wait until they are compatible before upgrading Bitbucket. App vendors generally update their apps very soon after a major release.

      Good to know:

      • Upgrading from a version older than Bitbucket Server 6 will automatically disable all user-installed apps. You will need to enable your apps after successfully upgrading, regardless of compatibility with Bitbucket Server 6.
      • You can disable an app temporarily if it is not yet compatible. 

2. Prevent the installation or upgrade of apps during the upgrade period

If you manage Bitbucket with a team of admins, schedule the rolling upgrade with them. Notify them to postpone any app installs or upgrades until after the rolling upgrade. Installing or upgrading apps during a rolling upgrade could result in unexpected errors.

3. Back up Bitbucket 

  1. Determine which backup strategy to use. 

    Summary of the different backup strategies for Bitbucket...

    For Bitbucket Server (version 4.8 or later) instances, you can use Zero Downtime Backup, the Backup Client (version 2.7 or later), or DIY Backup (version 2.12 or later) while Bitbucket is running, or just stop Bitbucket and zip up / snapshot the home directory and database and keep them somewhere safe.

    For Bitbucket Data Center (version 4.8 or later) instances, you can use Zero Downtime BackupDIY Backup, or take snapshots of the shared home directory (on NFS) and database while all nodes are stopped. 

    For Bitbucket mirrors, the home directory doesn't store any persistent state that can't be reconstructed from the primary Bitbucket instance, but you should still make sure you have a backup of at least the important configuration files such as SSL certificate, server.xml,  config/ssh-server-keys.pem,  bitbucket.properties file, and so on in a safe place. See  How do I back up my mirrors? for more information.


    See the article Data recovery and backups for detailed information and guidance on creating an effective backup strategy.

  2. Back up all the data in your Bitbucket home directory and external database.

If your deployment is hosted on AWS, we recommend that you use the AWS native backup facility, which utilizes snapshots to back up your site. For more information, see AWS Backup

4. Set up a staging environment to test the rolling upgrade

We strongly recommend that you perform the rolling upgrade on a staging or test environment first. 

  1. Create a staging copy of your current production environment.
  2. Follow the steps below to upgrade your test environment.
  3. Test any unsupported apps, customizations and proxy configuration (if possible) before upgrading your production environment.

 Perform the rolling upgrade

There are three methods for performing a rolling upgrade, depending on what orchestration tools your deployment uses:

MethodDescriptionInstructions

Manual upgrade

A manual upgrade is suitable for deployments that feature minimal orchestration, particularly in node upgrades. If your deployment is based on our Azure templates, you'll also need to perform a manual upgrade.

AWS CloudFormation

If your deployment is defined by an AWS CloudFormation template (like our AWS Quick Start), then you can use the same template to orchestrate your upgrade. 

API-driven

You can orchestrate the entire rolling upgrade process through API calls. 
Last modified on Feb 24, 2022

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.