AdStack Update Process and Rollout

## **AdStack Process:**

The process to raise an Adsatck update and rollout across all products.

| **Steps** | **Action** | **Responsible** | **Sign off** |

| --- | --- | --- | --- |

| 1 | The marketing/Monetisation team will raise a request with Delivery and product when a new update is required and timeline. | Monetisation Team | Adsatck Slack channel |

| 2 | Delivery team will get back with a tentative timeline. | Delivery Team | Adstack Slack channel |

| 3 | Monetisation team to agree or negotiate | Moetisation Team | Adstack Slack channel |

| 4 | Once agreed, the Monetisation team will reach out to each SDK provider and get this google doc completed with the details including confirmation of a stable build number with known issues and expected Revenue Uplift. | Moetisation Team | Adstack Slack channel |

| 4 | Delivery team will create a Adsatck rollout page in confluence | Delivery Team | Confluence Pgae |

| 5 | When Monetisation confirms the list is complete and signed off, only a developer from the reactor team will update the sdk versions from the google sheet to confluence page for the relevant Adtack rollout (for example, [Version 10.1](/wiki/spaces/AD/pages/2645426182/Version+10.1) ) No changes or updates to the version can be made unless there’s stability issue without agreeing with Monetisation team and Delivery team | Reactor Team | Confluence Page |

| 6 | Delivery team will update the release log of the Adstack rollout page and communicate to Monetisation team in Slack group | Delivery Team | Confluence Page |

| 7 | Deliovery team will ensure all products include the Adstack updates in the release plan and create relevant tickets in Jira | Delivery Team | Jira/Confluence Page |

| 8 | Delivery team will communicate to Reactor team when the first custombuild is required based on rollout plan | Delivery Team | Reactor request Slack Channel |

| 9 | Reactor team will make the first custom build using the signed off sdk versions from the Adstack page | Reactor Team | Product Slack Channel |

| 10 | The first custom build will be given to the relevant product Client team and the developer will attend the stand up to ensure the hadnover or answer any questions from the team. | Reactor Team | Product Slack Channel |

| 11 | Client Team will QA the build and release it | Client Team | Product Slack Channel |

| 12 | During the rollout Delivery Team will ensure any issues or rollout updates are captured in Adstack rollout confluence page (for example, [Version 10.1](/wiki/spaces/AD/pages/2645426182/Version+10.1) ). | Delivery Team | Confluence Page |

| 13 | After the Batch 1 Delivery team will seek sign off from Monetisation and product before starting rollout of Batch 2 | Delivery Team | Confluence Page |

**AdStack Batch Rollout Process:**

To aim for an expedited process that still allows us to check and verify the sanity of AdStack updates, we will be moving to a batch rollout process as follows:

**Batch 1 - Solitaire Scapes and Spider**

As Solitaire Scapes has a fair amount of users but is also a relatively secured product, we can use this as our space monkey product to ensure the AdStack update is stable and without issue.

Batch 1 will always need to be:

- An isolated update - the only change in this release is the AdStack update.

- Rolled out initially on Android and then iOS after a sanity check on Android data.

We may or may not decide to update AdStack on:

1. Sudoku

2. Puzzle Time

3. Black Jack

Batch 1 will need to have sign off given from both Monetisation AND Scapes Product Manager - to confirm stability and sanity for Batch 2

**Batch 2 - Solitaire Classic & Woodoku**

The glass babies of TDS - once Batch 2 have been completed with Product/Monetisation sanity confirmation we will push forward with the last two products.

Batch 2 SHOULD:

- Syncronised - Woo & Classic to be delivered/tested/released simultaneously.

- Be an isolated updated.