Business Continuity and Disaster Recovery
Effective [date of publication]
| App | TuneCraft: Automation & Site Cleanup, a Jira Cloud app built on Atlassian Forge |
|---|---|
| Marketplace listing | Not listed yet. TuneCraft is not on the Atlassian Marketplace yet, and its app key will be added here when it is. |
| Forge app ID | ari:cloud:ecosystem::app/facece90-dfd5-4792-9bff-6a5bd061a341 |
| Vendor | Plugincraft Software Inc., a company incorporated under the laws of Québec, Canada |
The short version
- TuneCraft runs entirely on Atlassian Forge. Atlassian runs the app's functions, stores its data and backs that data up, so most disruptions are Atlassian's to recover from, under Atlassian's own continuity and disaster recovery programs.
- Plugincraft has no servers of its own and holds no copy of customer data.
- Our part is to be able to ship a fix or withdraw a faulty version at any time, and to keep customers informed. Two owners with the same authority can each do that.
What the app depends on
| Dependency | What it does | Who recovers it |
|---|---|---|
| Atlassian Jira Cloud and Forge | Runs the app, stores its data (Forge SQL), runs its scheduled and queued jobs, keeps its logs, receives the automatic scan at the app's web trigger and sells licences. | Atlassian |
| The private source repository and its build pipeline | Holds the code, runs the automated checks and deploys new versions. | Plugincraft |
| The build runners | Run the automated checks for each change. | Plugincraft |
| The plugincraft.ca website | Hosts the manual, the trust pages and the terms. | Plugincraft |
| Keeps us in contact with customers and Atlassian. | Plugincraft, with its provider | |
| A customer's sender, if the customer turned on the automatic scan | A script the customer runs, on its own systems or as a scheduled job in ScriptRunner Cloud, a script app from another publisher that the customer installed, that pushes the redacted scan into the app. If it stops, the app keeps the last scan and says the push is late. | The customer |
Recovery objectives
- Customer data. Atlassian keeps it and backs it up. Atlassian states that Forge SQL databases are backed up periodically, that persistent Forge storage is backed up for disaster recovery, and that data deleted by mistake can be restored when a support ticket is raised within 21 days of the deletion (see Backups and recovery). Recovery times for the platform are Atlassian's.
- Ability to ship a fix. Restored within 1 business day of any disruption on our side, so that a Severity 1 incident can be contained within the time set in Incident Response.
- Customer communication. Kept up throughout, as set out in Incident Response.
Scenarios and what we do
| Scenario | What we do |
|---|---|
| Jira or Forge is down or slow | Follow Atlassian's status page, tell affected customers when the app is affected, and check the app once Atlassian has recovered. |
| App data is lost or damaged on the platform | Raise a support ticket with Atlassian within 21 days of the loss so it can restore the data. A Jira admin can also scan the site's automation again, from a new export or the next automatic scan, to rebuild the latest scan. |
| A release is faulty | Withdraw it by deploying the last good version from the repository, or ship a fix, through the usual review. |
| The source repository or its provider is unavailable | Each owner keeps a full copy of the repository. A version can be built and deployed to Forge from any copy, and the repository can be recreated elsewhere. |
| The build runners are down | Restart them, or run the same checks on the other owner's computer. A fix is never deployed without them. |
| An owner's account or a deploy credential is compromised | Revoke it at once, replace the credential, check recent deploys and changes, and handle it as a security incident. |
| One owner is unavailable | The other owner has the same authority and access, and carries on. |
| The website is down | Redeploy it from its repository. |
Roles
The President of Plugincraft Software Inc. leads recovery, as the incident lead in Incident Response, or names the other owner to do so. Either owner may deploy a fix or withdraw a version.
Review and testing
We review this plan once a year, as part of the yearly security review, and after any significant change or disruption. Once a year we also run a short practice exercise of a disruption and record what we learned.