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; } } }

Your Sandbox strategy and workflows

Artem Taranenko

Hi everyone,

Following last month's announcement regarding ability to deploy multiple sandboxes, I became curious if anyone has taken advantage of this change.

The last environment I've managed had JSM, Confluence and Jira sandboxes that were refreshed monthly, and sometimes before updates / major changes.

Curios about:

Are you using multiple sandboxes for same product?
Do you follow the recommended workflow for promoting changes?
How do you decide what changes can be introduced direct-to-prod vs sandbox-first? Is there a policy or best practice you follow?

In my latest engagement I've made many types of changes directly in prod. Arguably things like context selection changes, making fields optional / mandatory or hidden / visible, permissions changes and probably a few more common change types are harmless enough for a direct-to-prod. I've done a lot of workflow changes in prod too, usually when I know I have a back-up in sandbox for reference and a change is simple enough.

I can't only think of one instance where I relied on a Confluence sandbox, and that's to propose page tree changes to content / space owners.

Please share your use cases and workflows involving sandboxes!

Comments

Joao Zampa

As far as I can tell, only Enterprise plans have multiple Sandboxes included on the plan, while Premium just get one or the option to Buy more.

Therefore, as much I believe that a secondary Sandbox would be beneficial, I don't think it is worth 10K per apps.

Another useful feature that is behind a paywall that impacts adoption, IMO.

David Cowley

We were part of the beta, so we had 10 sandboxes per app available (briefly), and we did get up to using 10 of them total. Long term, I'm not sure what we're going to do, probably try to get down to 5 per app, but we did take full advantage of them historically.

Cases where we used multiple sandboxes for the same App & Site:

Testing migrations: either Cloud to Cloud migrations as we consolidate and split to our optimum configurations given the ability to split into multiple sites; or we have still not completely migrated all our server products within the organization, so we're still merging/migrating on premise Apps to the Cloud as well
Evaluating new add-ons and integrations: we like to evaluate new add-ons and integrations in isolated sandboxes and not ones which are being used as part of our normal change management process, so that those add-ons don't impact that process. Evaluation of add-ons can be time consuming for us, as in addition to the technical and functionality review, we may require additional privacy and security sign-off on them before they can be incorporated into our environment

I think otherwise the sandboxes that we're using are for different sites, rather than a dev-staging-prod or test-staging-prod or equivalent workflow.

Shawn Stevens

I agree with David. We were also on the Beta testing out the process for sandboxes. As David mentioned we were using sandboxes to Test JSM and JSM OPS changes before enabling them in production. We also used sandboxes for App integrations and App Testing and Cloud to Cloud migrations.

We also thought about the dev-staging-prod setup but have been mainly using them just as isolated testing environments from production.

We have run into issues with what data is or is not copied to a sandbox so at times it has limited our ability to fully test some items without some manual intervention.

David Cowley

The Cloud Enterprise feature list still lists 150 Sites as being included as part of the license. I'd be supportive of them changing that to 155 Sites/Sandboxes combined. Part of Atlassian's reasoning for capping Sandboxes is the cost and amount of resources that they use. I expect that we're not alone in only using around 10/150 of the sites we're licensed for, but that we would prefer to have more sandboxes to support those 10 sites.

The integration between a sandbox and the associated site makes it easier to do that than to use a real site as a sandbox environment (and cheaper generally as you shouldn't need to get additional marketplace App licenses for the sandbox, but would for the site).

But for some use cases we would likely use a new site instead of a sandbox in situations where licensing the marketplace apps is cheaper.

Welcome!

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

Quick Links

Find more posts tagged with

confluence

jira

jira-cloud

sandbox