Great to hear that this is coming! It would be nice if also Feature updates could use Rolling Upgrades. Because some bugs are only fixed in Feature releases or new features are needed by our customers and waiting for a new LTS release takes to long.

This feature is really making our customers happy!

Hey varun.agarwal,

The good news is that we're shipping rolling upgrades for bugfix versions in Bitbucket Data Center later this year. This can be used for admins running bitbucket in a multi node configuration to upgrade between bugfix versions (e.g. 7.X.0 > 7.X.1). We just shipped similar functionality in Confluence 7.9, and you can read about it here (click through to the release notes). For those whose preference is to stay on our LTS versions (6.10 & 7.6), this will allow you to upgrade to bugfix and security patches without downtime for end users.

We know many customers want more than this though, so we're planning our next steps in this space to align with larger pieces of work in flight - updates to come.

Hi Rob,

Following up to check if we had any progress on this improvement.

Regards,

Varun
 

Hi varun.agarwal - please feel to reach out to me on my email (rsaunders at atlassian dot com) and we can setup some time

Looking forward for the design, would be interested in the discussion around this topic and perform POC when this is released.

Hi everyone,

Thanks for voting and commenting on this suggestion. Your input in the comments helps us understand how this affects you and what you're hoping to accomplish with Bitbucket.

We're pleased to share that work on this feature is now in our short term roadmap and we're looking forward to providing some more concrete updates on that very soon.

If you'd like to be involved in our discussions as we continue to gather feedback and share initial designs in the next few weeks and months, we'd love to speak to you.

Cheers,
Rob Saunders
Product Manager - Data Center
rsaunders at atlassian dot com

I would like to get an update on this "feature request". For an enterprise level product, not having zero-downtime upgrade capabilities puts you years behind on the competition.

We can no longer afford to put our central GIT repositories offline for hours just to be able to install security patches and upgrades. 

This feature (or lack off) will play a major role in our decision making for renewal of our licenses. 

• How often do you do feature version upgrade e.g. 5.1 ? How often do you do bugfix version upgrade e.g 5.2.1?
  We are following Enterprise Releases and would like to keep current on the latest minor release because of bug-fixes and security-fixes.
  Our main requirement is minor version upgrades, however being able to feature-upgrade to the next ER without any downtime would be the ultimate goal.
• What are the most trivial and most time consuming tasks e.g upgrading database, upgrading application nodes, plugin compatibility check etc?
  There are no trivial tasks, the complete deployment/upgrade is automated. Our staging/test environments are automated including a refresh-procedure, meaning we have a sound procedure and grasp on the production upgrade.
• How long does the current upgrade takes? How much of it is planning, testing on staging environment and execution?
  We also use Ansible and require roughly 10 minutes for the first node + 5 minutes per node/mirror to upgrade in production. Planning/testing/staging takes up the longest part given critical processes are using Bitbucket+mirrors and cannot afford any downtime. While being fully automated, the planning of an upgrade can take months because our global teams using Bitbucket Datacenter are working on different releases and schedules and there just isn't a good time for down-time. Downtime on the main-cluster or a mirror node can be quite disruptive (especially when pushes are impossible to a mirror when the master is unavailable for maintenance)
• What have you tried so far to reduce the amount of downtime during upgrade? Hypothetically, will you still need zero downtime upgrade even if the upgrade happened with few minutes of downtime?
  The deployment is automated, so essentially after stopping the entire cluster, the service becomes available again in a few minutes when the first node has completed the upgrade. Having ZDU would remove this downtime window and we can upgrade a lot more and faster being completely transparent to the users. 
• Have you ever rolled back the upgrade? If yes, what was the root cause?
  No, rollbacks are not done. The upgrade has been tested multiple times, we know what is coming and we will address issues in order to move forward in case they should happen on prod.
• Have you considered redirecting builds to mirror nodes during the upgrade process?
  No. That would add complexity because of the global usage of our deployment and the extra /bitbucket/ being added in the url. Given that the mirrors are not accepting pushes when the master is unavailable, that would cause confusion instead of a workaround-fix.

• How often do you do feature version upgrade e.g. 5.1 ? How often do you do bugfix version upgrade e.g 5.2.1?
  • We use the most recent Enterprise Release as soon as it becomes available.
• What are the most trivial and most time consuming tasks e.g upgrading database, upgrading application nodes, plugin compatibility check etc?
  • There are no trivial tasks; everything about upgrading this application is time-consuming and disruptive to end users.
• How long does the current upgrade takes? How much of it is planning, testing on staging environment and execution?
  • About 40 minutes per cluster node, as we deploy individual Bitbucket instances via Ansible.
• What have you tried so far to reduce the amount of downtime during upgrade?
  • Automated deployment via Ansible.
• Hypothetically, will you still need zero downtime upgrade even if the upgrade happened with few minutes of downtime?
  • Yes, in order to be able to run upgrades during sociable hours for the support team.  We consider "downtime" and "planned outage" of application services to be very much a relic of pre-2005 (or thereabouts).  All our internally-developed applications are designed for continuous deployment and zero downtime.
• Have you ever rolled back the upgrade? If yes, what was the root cause?
  • No, and we would never consider this; we would fix forward.  Our system is under constant use, and it would be far too complex to synchronise the corresponding database backup.
• Have you considered redirecting builds to mirror nodes during the upgrade process?
  • No.

+1