Best practice for staging environment for jira cloud

Jira Development Jira Cloud
, ,
1

I would like to ask what is the best practice to have nicely working staging environment.
I have a development environment that I can start locally using provided in the instroction scripts. This works fine.
I also would like to have a staging version of the app that I could run all the automated tests against it (also set up on heroku just made of free dynos etc.).

What is the best practice to do it?

  1. Is it better to keep everything in one listing on marketplace and just make the staging a private version that is newer released?
  2. Make a separate marketplace listing for the staging app? Is something like this even allowed by the licenses?
  3. Manually deploy on some account(s) the atlassian-connect.json file with the staging area address in it?

Should the application key be different for development, staging and release versions?

I’ve read several posts here about staging area and ‘The app could not be installed as a local app as it has previously been installed from Atlassian Marketplace.’ problem.

I’ve also read this: How do you create and operate your staging/testing JIRA and Confluence instances? - Atlassian Developer Tools - The Atlassian Developer Community but it looks like it’s around jira server versions and actually no ther is no answer :frowning:

Looks like there is no perfect solution.
Any recommendations or article links for someone starting with it?

2

After spending some time on it, I have my configuration. I’ll share what I did, maybe someone will find it useful.

So first I made few changes in the config.json file. Among others that are 2 variables that I used specifically for this: “localBaseUrl” and “appKey”.
In the “production” and “development” section I have now entry like:

"appKey": "$APP_KEY_ENV_VAR",

Additionally in the “production” section I have:

"localBaseUrl": "$LOCAL_BASE_URL",

In atlassian-connect.json, among others I have following entries:

"key": "{{appKey}}",
"baseUrl": "{{localBaseUrl}}",

Development environment
Now on my development machine I have environment variable declared like:

APP_KEY_ENV_VAR=appKey-dev

Now running npm start command, the app is registered in Jira with appKey-dev key and everything works from my local machine.

Staging environment
I have a staging app created on heroku, for that app I’ve set two environment variables:

APP_KEY_ENV_VAR=appKey-staging
LOCAL_BASE_URL=myapp-staging.herokuapp.com #[url of the staging app on heroku]

This runs on heroku using free dynos. This staging app doesn’t have any atlassian listing. I’ve manually installed it on jira by providing the atlassian-connect.js file address of heroku staging app.

Production environmet
Slightly similar to staging env. Also app on heroku just with APP_KEY_ENV_VAR set to proper application key. Runs on paid dynos.
For this app there is listing created on Atlassian Marketplace (private for now). Currently it’s installed on my account using private token.

Few minor changes to tests and tests run automatically on staging area whenever new code is pushed to github and also I can run the easily using the development environment.

For now it works for me.
Though I’m open to suggestions.

3

@ZbigniewPiecuch - I don’t know what the best practice for this is, but we do something similar to you.

  • separate app keys for dev vs staging vs production, mainly so we don’t have to deal with the mess that happens when someone accidentally installs the wrong version in an instance
  • we have a staging server that we deploy to regularly
  • we have a separate marketplace account for the staging apps.
    – all of the staging apps are thus in the marketplace, and we can use license tokens for testing the licensing functionality
    – keeping the staging apps in a separate account means you can give your devs access to it, without having to grant access to your production marketplace account
    – de-clutters your production marketplace account.

As an additional bonus, we inject the environment string into the titles of the various sections our app shows up in. For example, a glance in Jira might say “My Awesome App-staging”, etc. thus making it easier to identify what’s installed.

4

Yes.

And make sure you are aware of Change notice - Changes to installation of a local app on Atlassian Cloud products - Announcements - The Atlassian Developer Community

5

We do not use separate app keys or marketplace accounts. We do have separate GCP projects (our apps run on Firebase) and separate domains (acc.domain.com). We also use environment variables to set the base URL per environment.

The benefit of using the same key is that it makes it easier to upgrade from dev to acc to prod. We have an additional interface that allows us to copy specific data from prod for testing (for instance if we want to reproduce an issue from a customer support request)

We actually never install from the Atlassian Marketplace. Neither for dev, staging or production. We simply always directly upload the descriptor as it has the same effect. We have licensing disabled for dev and staging (based on environment variable) which allows us to develop/test without private listing tokens.

The dev and staging environments can only be installed into a whitelisted set of instances which we check in the installation lifecycle events. This is how we prevent others from using the unlicensed staging environment.

6

Thanks for all the answers and tips. Lot of good info to process now.
Inject env. variable to name - good point.
Thanks or the link - I’ll read it.
I didn’t thought earlier about whitelists for intallation lifycecle and license check based on env. variable.