=================== Deployment Protocol =================== ------ Wallet ------ .. code-block:: none $ cd wallet-webex # check dependencies $ ./configure # edit version and version_name $ $EDITOR manifest.json $ make package-stable The built wallet is now ready in `taler-wallet-stable-${version_name}${version}.zip`. FIXME: here, we should do some semi-automated testing with selenium, to see that everything works against `demo.taler.net`. The package can now be uploaded to https://chrome.google.com/webstore/developer/dashboard FIXME: include asset links and descriptions we use in the webstore in this document FIXME: include instructions for other app stores -------------------- Deploying to stable -------------------- First, make sure that the deployment *AND* the deployment scripts work on the `test.taler.net` deployment. For all repositories that have a separate stable branch (currently exchange.git, merchant.git, merchant-frontends.git, bank.git, landing.git) do: .. code-block:: none $ cd $REPO $ git pull origin master stable $ git checkout stable # option a: resolve conflicts resulting from hotfixes $ git merge master $ ... # option b: force stable to master $ git update-ref refs/heads/stable master $ git push # possibly with --force # continue development $ git checkout master Log into taler.net with the account that is *not* active by looking at the `sockets` symlink of the `demo` account. The following instructions wipe out the old deployment completely. .. code-block:: none $ ls -l ~demo/sockets [...] sockets -> /home/demo-green/sockets/ In this case, `demo-green` is the active deployment, and `demo-blue` should be updated. After the update is over, the `/home/demo/sockets` symlink will be pointed to `demo-blue`. .. code-block:: none # Remove all existing files $ find $HOME -exec rm -fr {} \; $ git clone /var/git/deployment.git $ ./deployment/bootstrap-bluegreen demo # set environment appropriately $ . activate $ taler-deployment-build # upgrade the database! this # process depends on the specific version $ taler-deployment-start # look at the logs, verify that everything is okay Now the symlink can be updated. ------------------ Database upgrades ------------------ The exchange db can be re-initialized with .. code-block:: none $ taler-exchange-dbinit -r CAUTION: YOU WILL LOSE ALL DATA WITH THIS! --------------------- Standalone deployment --------------------- This tecnique aims to set a thorough Taler installation up on a machine whose nginx configuration is configured by config files from https://git.taler.net/deployment.git/tree/etc/nginx. This installation assumes that all the steps are run with ``$HOME`` as ``$CWD``. The first step is to fetch the `deployment` repository, which hosts all the needed scripts. .. code-block:: none # Adapt the repository's URI to your needs. $ git clone /var/git/deployment.git/ The next step is to fetch all the codebases from all the components. .. code-block:: none $ ./deployment/bootstrap-standalone If the previous step succeeded, a file named ``activate`` should be now in the ``$CWD``. It contains environmental definitions for ``$PATH`` and database names. .. note:: Please *ignore* the output from the previous script when it succeeds, which is .. code-block:: none WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using: /usr/lib/postgresql/9.5/bin/pg_ctl -D talerdb -l logfile start The reason is that this message is generated by Postgresql's utilities and you never need to start your database manually; it will be started by the init script that launches all the Taler processes. Now we need to compile and install all the downloaded codebases. .. code-block:: none # We first update ``$PATH``, in order to make all the compilation and configuration utilities available. $ source activate # Double check if the previous step worked: $PATH should # contain $HOME/local/bin. $ echo $PATH # The actual compilation: $ taler-deployment-build The following step will generate config files for all the components. Please **note** that although a default currency will be picked up by the script, it is possible to have a custom currency by setting the environment variable ``TALER_CONFIG_CURRENCY`` to the wanted currency, and then runing the config generator. .. code-block:: none $ taler-deployment-config-generate whereas the following one will place signatures inside wireformat JSON files. .. code-block:: none $ taler-deployment-config-sign The next step is to generate `signkeys` and `denomkeys`. .. code-block:: none $ taler-deployment-keyup .. An error of "invalid currency name" might be related to the current policy of 12-chars limit for currency names; which is likely going to be changed. It may be necessary to define database tables for the exchange. The following command does that. .. code-block:: none # Erase all the data! $ taler-exchange-dbinit -r As of the merchant backend, it creates tables at launch time, so it is not required to define tables before launching it. `However`, if some table's definition changed over the time, and there is a need to force a redefinition of tables, then the following command accomplishes that for the merchant: .. code-block:: none # Erase all the data! $ taler-merchant-dbinit -r If all previous steps succeeded, it is now possible to launch all the processes. That is accomplished by the following command: .. code-block:: none $ taler-deployment-start .. note:: Please make sure your nginx works correctly with its configuration at ``/etc/nginx``.