Skip to main content

Test apps

Once you have prepared a Towerfile and changed your app code to receive secrets and parameters, you are ready to test the app. We recommend starting with a python run, then a local Tower run, and then a run in the Tower cloud.

Run your main script in python​

Make sure your main script runs in python successfully.

python mainscript.py

Run app locally​

Tower offers a local execution mode. Use this mode to verify that your app is compatible with the Tower remote execution environment.

tower run --local

Deploy the app to Tower​

Now that you've tested the app locally, you can deploy the app to Tower and run it there. By default, tower deploy creates a new version of your app and pins it to the default environment only — other environments (like production) keep whatever version they were already running. That makes it safe to iterate without touching production.

tower deploy

Run in a test Tower environment​

If you have a separate testing environment that you use to test your apps before promoting them to production, you can set up Tower to mirror this process.

Using multiple environments in Tower means two things:

  1. Different secrets per environment — so your app can connect to different databases, buckets, etc.
  2. Different versions per environment — so you can let a new version "soak" in test before promoting it to production.

You can set different values for secrets that you want to differ from environment to environment.

tower secrets create --name=snowflake_url \
   --value=https://abc123-prod.snowflake.com \
   --environment=test

To deploy a new version of your code to a specific environment, pass --environment to tower deploy. This pins the new version to that environment only — other environments are not affected.

tower deploy --environment=test

Later, you can run an app in an environment that you specify on the command line. Tower will inject the correct value of the secret and run the version that's deployed to that environment, so you don't have to have special processing logic to handle different environments.

tower run --environment=test

Promoting from test to production​

Once a version has proven itself in your test environment, you can promote or deploy the same version to production. You can do this two ways:

  • From the Tower UI: open the app's Changelog, find the version you want to promote, and click Promote → choose production. The exact version that was running in test gets deployed to production without rebuilding the package.
  • From the CLI: run tower deploy --environment=production from the same source tree. This builds a fresh version and pins it to production. (The version number will differ from the one in test, but the code is the same if your source hasn't changed.)

If a problem turns up in production, you can roll back to any earlier version from the Changelog using Rollback. See Versions, environments, and promotion for more.

However, if your app code does need to know which environment the app is running in — e.g. so that you can pick different database engines depending on the environment — you can do this via the TOWER_ENVIRONMENT variable.

tower_env = os.getenv("TOWER_ENVIRONMENT")

Get app status and logs from Tower​

Once you initiate your first run in Tower, you can get the app status and run logs.

Execute “tower apps show” command to get a list of all app runs.

tower apps show <app-name>

Execute “tower apps logs” command to get logs of the specified run​

tower apps logs <app-name>#<run-number>