nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How would you use multiple sandboxes for managing change?

Matt Tse

Hi everyone, we hope you've all had a good 2021 so far.

We’re exploring the desirability of providing multiple sandbox environments for Jira and Confluence Cloud and would love to hear from you. Specifically, how would you use multiple sandboxes for managing change?

Feel free to comment directly on this discussion. You may also email me directly at mtse[at]atlassian.com if you prefer.

Comments

Kristin Lyons

One use case I can think of - we have 1 sandbox for testing Jira modifications to schemes and another sandbox for merging multiple instances of Jira. I could provide more insight if requested, but I'm doing something similar right now.

Fabrice Huart - NSI

Hi,

In general in our implementations with "on-premise" versions of Jira / Confluence, we work with at least two environments but sometimes more.

A concrete example :
- a development environment to develop new features and test them by developers;
- an UAT environment for tests by business users in order to prevent their tests from being impacted by ongoing developments;
- a production environment

The deployment cycle is always DEV - UAT - PROD
And this for all configurations, updates of main software or extensions from the Marketplace.

We must be able to find the same functional level in the sandboxes.

It is therefore necessary to be able to simply transfer the configurations (of Jira or Confluence and associated extensions) between the sandboxes.

Best regards,

Fabrice

Helene Lund Engebø

We have more or less the same setup as described by Fabrice above: dev - staging - production.

We have instances with several custom-built apps and integrations with other systems, in which case having access to several sandboxes is essential:

The dev environment is for everyday testing, both automated and manual/ad-hoc. This could be testing of configuration changes, or during development of new functionality in apps or integrations
The staging environment is for release testing, business testing, also both automated and manual/structured - to ensure the changes are safe for production.

The staging environment has to be identical to the production environment, both in terms of configuration, apps and integrations.

Completely agree with Fabrice in that it has to be easy to deploy configuration changes between sandboxes, and between a sandbox and production.

Regards,

Helene

(app vendor and solution partner)

[A9] William Kennedy

We're managing change in two domains; Jira Application release changes and discrete changes to the application configuration.

We need to test them in tandem.

Sandbox instances using certain release tracks are critical to this validation and promotion process, but there is no method available today that enables me to deploy a Project from Prod on a Release Track sandbox. This is an absolute show stopper.

Colen Shields

I would like to have one or two sandboxes to be able to test things before go-live in my production Jira environment. If I could use prod data but with dev environment changes to test before go-live or interactive with real issues, that'd be incredibly helpful. Along those lines, if we could log in as users in dev without emailing them, we could do user experience testing without even having to engage them or impact their prod work, which would be helpful. A dev environment that would be a copy of the main environment that I could push ad-hoc would be a godsend. Even better if we could make changes in dev, test them out, and push back prod at a granular level (project-level perhaps).

That said, one place I'd specifically like that functionality now is for trying to redo how we manage changes in our business. With the improvements with pipelines, services, the ITSM Service Management project type, automation, bitbucket, and the like I'd like to be able to spin up a new system but with real user and custom field data to be able to mock up the entire lifecycle of a change and be able to design, build, test, and document before going live for the organization.

Matt Tse

Thanks Kristin! I have a few follow up questions:

Could you tell us more about why you need to perform these two tasks in separate sandbox environments?
What are you trying to accomplish by merging multiple instances of Jira?
Who needs access to these multiple sandboxes? Is the same set of users who perform these tasks?

Thanks!
Matt

Matt Tse

@Fabrice Huart - NSI , thanks for the detailed response. This sounds like the most common use case we've seen (going from DEV -> UAT -> PROD).

I'm interested in better understanding your process for transferring changes between the sandboxes. Can you tell me more about this? Some specific questions I have:

What is the process you take for transferring changes from one environment to another?
How often are you repeating this task of transferring configuration?
Who is responsible for performing this task? It sounds like you have a different set of users who use the DEV/UAT environments, but is there a person/group that's in charge of executing the change?

Cheers,

Matt

Matt Tse

Thank you @Helene Lund Engebø I have a few follow up questions.

I'm interested in learning more about these custom-built apps and integrations with other systems. I presume these are things that your team has built, and not something purchased from the Atlassian Marketplace? Can you share any examples?

You also mention the need for the staging environment to be identical to the production environment. I understand the configuration aspect, but can you tell me more about the apps and integrations? Which parts of those need to be identical?

Lastly, can you walk me through the actual process you take to deploy a change between Dev -> Staging -> Production?

Feel free to email me directly (mtse@atlassian.com) if there's anything you don't want to disclose here.

Cheers,

Matt

Matt Tse

Thank you for your insight as always @_A9_ William Kennedy.

Sandbox instances using certain release tracks are critical to this validation and promotion process, but there is no method available today that enables me to deploy a Project from Prod on a Release Track sandbox. This is an absolute show stopper.

It sounds like the work we're doing with sandbox data copying and our preview tracks will address this need. Please let me know if otherwise though.

Could you clarify the differences between Jira Application release changes and discrete changes to the application configuration? The former sounds like the changes that we (as Atlassian) make to our cloud products, whereas the latter sounds like the changes that you (as the customer) are making. Is that correct?

Kristin Lyons

I like to keep them separate as we need to keep the instance used for testing the merges limited, we do not want any changes to occur when we are testing.
I often see companies merging or being bought by other companies. Both companies have their own Jira and Confluence instance and want to consolidate. This is typically just a one and done process, so I do not see the need to have 2 sandbox instances all the time, perhaps a special request can be submitted.
For the regular sandbox instance, all users should have access to this. For the sandbox instance testing merging of multiple instances, just a few selected users will have access to this - users who are performing the merge and users who are testing the data.

[A9] William Kennedy

Hi @Matt Tse - you nailed it.

It's pretty easy to map out a scenario where a Sandbox is on an advance release track and periodically synced with Production for evaluation.

What's missing is a method to manage application-level changes across Sandbox and Prod or from Dev instance to Sandbox or Prod.

Project Configurator looks promising, but the roadmap seems to indicate technical limitations on Atlassian's side.

Until something from the ecosystem matures or Atlassian introduce their own, I'm proposing teams investigate building (vs buying) a tool for managing state within Cloud Jira (and Confluence) using the REST APIs.

Helene Lund Engebø

Hi @Matt Tse ,

So sorry that I missed your reply and didn't get back until now. Need to adjust my notificaton settings...

Regarding the custom-built apps and integrations:

Although it's been a while, this Summit talk from 2017 gives a fairly good overview of what we've built based on Jira Server, and that we're now starting to map out for Cloud: https://youtu.be/OImUwiZHaKA
One of our apps is listed on the Marketplace (Mapit), the rest are custom-built apps provided directly to our customers.
Integrations: yes, these are custom-built by us or by our customers' integration teams. These integrate other systems with Jira for issue creation, updates and trigger transitions.

So when something in this value chain needs to change - either a new version of an app, configuration changes or changes in the integration layer - we want to be able to do end-to-end testing in an identical environment to production. This in order to capture any problems in any part of the chain.

Regarding the proces between dev > staging > production: we haven't got this process up and running in Cloud yet, as we are just getting started. But we're happy to walk you through this once we've gotten a bit further.

Hope that gives you a bit more detail - but do let me know if you'd like to set up a meeting with my team and we'll be happy to do that.

Thanks,

Helene

MarcSch

Hi @Matt Tse , are there any news on multiple sandboxes? Our use cases are:

like already mentioned DEV - UAT - PROD
internal sandbox <> external sandbox (e. g. for service providers who should not access all data)

Matt Tse

Hi @[deleted],

Thank you for your interest! Multiple sandboxes are on our roadmap and we plan on starting some early explorations in the second half of 2022. You're welcome to also follow our public Jira ticket for updates: https://jira.atlassian.com/browse/CLOUD-11118.

I'd love to also better understand how your service providers would be using your external sandbox? What type of data would you store in your internal vs external sandbox? Feel free to email me directly if you'd prefer at mtse[at]atlassian.com.

Cheers,

Matt

Suresh

Now that we have this https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Multiple-Sandboxes-Now-Generally-Available/ba-p/3150480

can we start looking into how to port the configurations across sandboxes. For example a screen/field/workflow/ designed or updated in one Sandbox, can that be ported (there by over-writing as a option) easily into another Sandbox?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

confluence-cloud

cloud-migration

sandbox