Forge deploy sandbox enviroment

[José Torres]

Hello, community!

I'm deploying Forge applications in Jira Cloud, but I have a question: how can I use a Sandbox environment to replicate deployments using the same code without having to duplicate the solution with new IDs? How have you handled this process?

[Thomas Blevins · Accepted solution]

Hey, I do not work for Atlassian, so I could be wrong here.  I although, think I am going through the same scenario, and below is my understanding on the best way to set up an environmental workflow.

I think the Environments documentation describes what to do here, in the first three paragraphs.  So, I will have three total sites, accomplished with the Cloud Developer Bundle, as per the instructions on the Build a Jira hello world app.

• The production site (company.atlassian.net), where my team collaborates with VERY REAL data
• The staging site (staging-company.atlassian.net), where I proof my changes to my team/management before sending them to "production"
• The development site (development-company.atlassian.net), where I actively develop changes on, with the usage of `forge tunnel`.

From there, each site installs an environment of my deployed application.

[Thomas Blevins]

As a side-note, the Cloud Developer Bundle is proving to be difficult in removing, and I have to wait for 30 days to get the organization shut down.

There may be something in using a Sandbox site up within your existing organization, which is offered on Enterprise and Premium Plans.

[José Torres]

Thanks, Thomas,
I'll check what you mentioned. I see that it's not enabled, but I'm not sure if that's because of my plan. Regards

[Tomislav Tobijas · Accepted solution]

Might not be 100% relevant here, but I know scenarios where folks are strugling when it comes to field IDs (which kind of relates to Forge as well) and that there's this suggestion that would support sync between prod and sandbox when it comes to such entities: CLOUD-12399: Enhance the consistency of custom field IDs between production and sandbox environments in Jira Cloud 

[José Torres]

Thanks Tomislav Tobijas

[Himanshu Tiwary]

Hi @José Torres ,

You do not need to duplicate the Forge app or create new app IDs just because you want to use a Jira Sandbox site.

In Forge, the important distinction is:

Forge environments = development / staging / production

Atlassian Sandbox = a separate Jira/Confluence site used for testing

So the usual approach is to keep one Forge app and one app ID, then deploy the same code to the Forge environment you want and install that app on different Atlassian sites.

A common setup is:

install development or staging on the Sandbox Jira site

install production on the production Jira site

That lets you use the same codebase without cloning the app or changing IDs.

In practice, teams usually handle it like this:

Keep a single Forge app

Use Forge environments to separate testing vs live deployments

Install the app in your Jira Sandbox site for validation

Promote the same app to production when ready

So if your question is “can I use the same Forge app in sandbox and production without duplicating the solution?” — the answer is yes.

The only time people usually create a second app ID is when they want a completely separate app lifecycle, not just a test site.

One thing to keep in mind: the Jira Sandbox is only the site copy. Forge storage, app versions, and environment management are still handled through Forge itself, so the clean model is usually:

Sandbox site + Forge development/staging

Production site + Forge production

You could reply with something like this:

You don’t need to duplicate the Forge app or create a new app ID just to use a Jira Sandbox. The better approach is to keep one Forge app and use Forge environments properly. Normally, I install the development or staging environment in the Sandbox site, and the production environment in the production site. That way, I can use the same codebase and same app ID without cloning the solution. I’d only create a separate app ID if I wanted a completely independent app lifecycle, not just a test deployment path.

If this better explains the solution please mark this answer :P 

[José Torres]

As you mentioned, it’s not necessary—the Forge environments are sufficient—but when I try to access Forge development/staging development-misitio.atlassian.net, it tells me the site is down. So I’m not sure if it’s an issue with my plan; I’ll check with our provider. Thank you very much for the clarification; it gave me another perspective to verify my configuration.
Regards