Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-5271

Create CAC documentation for how to set up a staging server

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • Documentation (User)
    • None
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      A separate Stash version of this JIRA 'environment' page may be called for, to address the best practice aspects:

      https://confluence.atlassian.com/display/JIRA/Establishing+Staging+Server+Environments+for+JIRA

      In the mean time, please follow the steps below to replicate your production environment to a different staging server.

            [BSERV-5271] Create CAC documentation for how to set up a staging server

            ThiagoBomfim (Inactive) added a comment -

            For anyone looking at this issue, please refer to the KB written by us: https://confluence.atlassian.com/display/BitbucketServerKB/How+to+establish+staging+server+environments+for+Bitbucket+Server

            ThiagoBomfim (Inactive) added a comment - For anyone looking at this issue, please refer to the KB written by us: https://confluence.atlassian.com/display/BitbucketServerKB/How+to+establish+staging+server+environments+for+Bitbucket+Server

            ThiagoBomfim (Inactive) added a comment - - edited

            Hi Svante,

            Thanks a lot for your feedback here. I will make some notes:

            If I need to setup a staging (or development instance) I would like to take the latest nightly backup. I don't want to run a backup during office hours since it will be downtime for my 500 users. The backup takes approx. 30 minutes today using the Stash Backup Client.

            Answer:

            Makes sense. Please also take into account an alternate backup method we made available for our customers: DIY backup scripts. You'd be able to perform the backup in less time once you've got it set up.

            I could wait for a window outside of the current SLA and turn off Outgoing email. But I also need to disable a bunch of plugins that communicates with surrounding systems, such as Jenkins, Hipchat etc. When these are disabled I can do the backup and then re-enable them again.

            Answer:

            Ok. Please refer to this document on how to do that in a single step: UPM - Disabling or enabling all add-ons (using Safe Mode). Is that how you've actually been disabling your plugins?

            In my opinion this is not a good way to manage a mission critical Stash instance. There are too many changes made that may go wrong at some place. It is also done outside of office hours which makes it harder if somethings goes wrong. A better approach is to NOT change my production environment at all and then alter the restored version that shall be my Staging instance instead.

            Answer:

            Your use case for migration really has a lot of changes. I am not sure the requirements you have will apply to everyone, though. Let's leave here as a note so we can assess your use case when we write the documentation. Bear in mind that our documentation, though, has to consider the most common use case amongst our customers and be useful to everyone. We should definitely keep what you are saying in mind.

            I have tried to disable the outgoing email via database update (See https://answers.atlassian.com/questions/9881301/disable-email-notification-from-stash) and it works fine. I also have a few SQL queries ready to disable enabled hooks on repo level (instead of disable the actual hook itself).

            Answer:

            Thanks for that. Please understand that from a Support point of view we shouldn't be encouraging our customers to change their database directly through SQL queries. The application layer is often more complex than that and we use frameworks that require other tables to be changed. That said, it is always safer proceeding with those changes using our REST APIs or the UI.

            I hope those answers address your comments.

            Best regards,
            Thiago Bomfim
            Atlassian Support

            ThiagoBomfim (Inactive) added a comment - - edited Hi Svante, Thanks a lot for your feedback here. I will make some notes: If I need to setup a staging (or development instance) I would like to take the latest nightly backup. I don't want to run a backup during office hours since it will be downtime for my 500 users. The backup takes approx. 30 minutes today using the Stash Backup Client. Answer: Makes sense. Please also take into account an alternate backup method we made available for our customers: DIY backup scripts . You'd be able to perform the backup in less time once you've got it set up. I could wait for a window outside of the current SLA and turn off Outgoing email. But I also need to disable a bunch of plugins that communicates with surrounding systems, such as Jenkins, Hipchat etc. When these are disabled I can do the backup and then re-enable them again. Answer: Ok. Please refer to this document on how to do that in a single step: UPM - Disabling or enabling all add-ons (using Safe Mode) . Is that how you've actually been disabling your plugins? In my opinion this is not a good way to manage a mission critical Stash instance. There are too many changes made that may go wrong at some place. It is also done outside of office hours which makes it harder if somethings goes wrong. A better approach is to NOT change my production environment at all and then alter the restored version that shall be my Staging instance instead. Answer: Your use case for migration really has a lot of changes. I am not sure the requirements you have will apply to everyone, though. Let's leave here as a note so we can assess your use case when we write the documentation. Bear in mind that our documentation, though, has to consider the most common use case amongst our customers and be useful to everyone. We should definitely keep what you are saying in mind. I have tried to disable the outgoing email via database update (See https://answers.atlassian.com/questions/9881301/disable-email-notification-from-stash ) and it works fine. I also have a few SQL queries ready to disable enabled hooks on repo level (instead of disable the actual hook itself). Answer: Thanks for that. Please understand that from a Support point of view we shouldn't be encouraging our customers to change their database directly through SQL queries. The application layer is often more complex than that and we use frameworks that require other tables to be changed. That said, it is always safer proceeding with those changes using our REST APIs or the UI. I hope those answers address your comments. Best regards, Thiago Bomfim Atlassian Support

            Svante Gustafsson Björkegren added a comment -

            Hey Thiago,
            I have got that questions a couple of times now and I start to think this is the way to solve it

            But my main reason for not doing it this way is:
            If I need to setup a staging (or development instance) I would like to take the latest nightly backup. I don't want to run a backup during office hours since it will be downtime for my 500 users. The backup takes approx. 30 minutes today using the Stash Backup Client.

            I could wait for a window outside of the current SLA and turn off Outgoing email. But I also need to disable a bunch of plugins that communicates with surrounding systems, such as Jenkins, Hipchat etc. When these are disabled I can do the backup and then re-enable them again.

            In my opinion this is not a good way to manage a mission critical Stash instance. There are too many changes made that may go wrong at some place. It is also done outside of office hours which makes it harder if somethings goes wrong. A better approach is to NOT change my production environment at all and then alter the restored version that shall be my Staging instance instead.

            I have tried to disable the outgoing email via database update (See https://answers.atlassian.com/questions/9881301/disable-email-notification-from-stash) and it works fine. I also have a few SQL queries ready to disable enabled hooks on repo level (instead of disable the actual hook itself).

            I will setup my staging environment during this week and can post my steps and SQL queries here if you like and they might be part of the documentation.

            Cheers,
            // Svante

            Svante Gustafsson Björkegren added a comment - Hey Thiago, I have got that questions a couple of times now and I start to think this is the way to solve it But my main reason for not doing it this way is: If I need to setup a staging (or development instance) I would like to take the latest nightly backup. I don't want to run a backup during office hours since it will be downtime for my 500 users. The backup takes approx. 30 minutes today using the Stash Backup Client. I could wait for a window outside of the current SLA and turn off Outgoing email. But I also need to disable a bunch of plugins that communicates with surrounding systems, such as Jenkins, Hipchat etc. When these are disabled I can do the backup and then re-enable them again. In my opinion this is not a good way to manage a mission critical Stash instance. There are too many changes made that may go wrong at some place. It is also done outside of office hours which makes it harder if somethings goes wrong. A better approach is to NOT change my production environment at all and then alter the restored version that shall be my Staging instance instead. I have tried to disable the outgoing email via database update (See https://answers.atlassian.com/questions/9881301/disable-email-notification-from-stash ) and it works fine. I also have a few SQL queries ready to disable enabled hooks on repo level (instead of disable the actual hook itself). I will setup my staging environment during this week and can post my steps and SQL queries here if you like and they might be part of the documentation. Cheers, // Svante

            ThiagoBomfim (Inactive) added a comment -

            Hi Svante,

            Why don't you disable the email in the original instance prior to backing it up?

            When you restore the original one, that should keep you safe.

            I hope that helps.

            Best regards,
            Thiago Bomfim
            Atlassian Support

            ThiagoBomfim (Inactive) added a comment - Hi Svante, Why don't you disable the email in the original instance prior to backing it up? When you restore the original one, that should keep you safe. I hope that helps. Best regards, Thiago Bomfim Atlassian Support

            Svante Gustafsson Björkegren added a comment -

            Hey,
            I am going to setup a staging instance for Stash now and will follow the simplified workflow described here.

            One question:
            I need to ensure NO emails are sent out from this Staging instance and I would like to disable this before I fire up the staging environment. What I can see this has to be done in the database since there are no disable notifications parameters available. (cmp JIRA and Confluence)

            I have found the property key mail.host in the table app_property in the Stash database. Would it work to just clear this property before I startup my Staging environment? If so, you should maybe add this step as well to the workflow.

            Cheers,
            // SVante

            Svante Gustafsson Björkegren added a comment - Hey, I am going to setup a staging instance for Stash now and will follow the simplified workflow described here. One question: I need to ensure NO emails are sent out from this Staging instance and I would like to disable this before I fire up the staging environment. What I can see this has to be done in the database since there are no disable notifications parameters available. (cmp JIRA and Confluence) I have found the property key mail.host in the table app_property in the Stash database. Would it work to just clear this property before I startup my Staging environment? If so, you should maybe add this step as well to the workflow. Cheers, // SVante

              jpaz Paz (Inactive)
              pwatson paulwatson (Inactive)
              Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: