.. _info-v2-upgrade:

===============
Upgrading to v2
===============

Upgrading to |automation| v2 is done on an Adjust account basis. If a client has
multiple accounts they can use different versions of |automation| API with each
Adjust account.

URL Changes
~~~~~~~~~~~

The |automation| is served from new URL: https://settings.adjust.com/api/

All the paths are the same as they were on V1.


API Changes
~~~~~~~~~~~

While working on |automation| v2 API we decided to keep the API same as v1 as
much as possible in order to provide smoother transition to stand-alone service.

Main differences:
 * :term:`Bundle ID` is now mandatory fields
 * :term:`App Name` is now a mandatory field
 * New naming for :ref:`info-override-settings`

So the full request could look something like this now

.. code-block:: bash

    $ curl \
    --header "AdjustAuthorization: Token <Adjust API Token>" \
    --header "Content-Type: application/json" \
    --data '{
        "name":"Test App Name",
        "bundle_id":"test.bundle.app",
        "store_id":"test.bundle.app",
        "platform":"android",
    }' \
    -X POST https://settings.adjust.com/api/app


Version 1 did not require ``"name"`` and ``"bundle_id"`` to be present in request body.
If you already use ``"name"`` and ``"bundle_id"`` there is nothing to change.


.. _info-v2-upgrade-workflow:

Upgrade workflow
~~~~~~~~~~~~~~~~

In the |automation| service we keep small amount of data about the app in the database,
for example override settings and channel setup data.

Before starting to use |automation| v2 we need to copy the client data over from v1.
For testing it is not mandatory to copy the data from v1 but it can be done if client
wants to verify that existing apps are working properly.

Migration should be done in two phases:
 * :ref:`info-v2-upgrade-testing-phase`
 * :ref:`info-v2-upgrade-production-phase`


.. _info-v2-upgrade-testing-phase:

Testing phase
=============

.. warning::
    In the testing phase, the client should only create new testing apps and run tests on those apps;
    Updating production apps could lead to loss of settings data once we refresh the v2 database;
    before putting it in production.

In testing phase client should verify that all the API calls they make work against
|automation| v2 as they did against v1.

Steps:
 * In cooperation with the client we set the date when to transfer the data from v1 to v2;
 * we transfer the data and inform the client to start testing;
 * clients creates **new** testing apps and tests settings migrations on them using v2 API.
 * clients update the override settings names if they use them to work with v2 API

.. note::
    All the :ref:`info-override-settings` existing in v1 will automatically be transfered with
    new names to v2


.. _info-v2-upgrade-production-phase:

Production phase
================

In production phase we need to update the |automation| v2 with current production data.
After this point the client should start to use v2 API only.

Production phase:
 * once the client is satisfied with test results we copy the fresh version of data from v1;
 * we disable automation for that account on v1;
 * from that point on client only uses v2.