Travis CI
02 / 02

Deployment, Debugging & Choosing a CI Provider

Deployment, Debugging & Choosing a CI Provider

Deploy Configuration

deploy:
  provider: heroku
  api_key: $HEROKU_API_KEY
  app: my-app
  on:
    branch: main

Declarative deploy integrations for common providers avoid hand-rolled deployment scripting for a straightforward "deploy on successful main-branch build" workflow.

Debugging Failures

after_failure:
  - cat ./test-results/*.log
  - ./scripts/upload-screenshots.sh

after_failure captures diagnostic context (logs, screenshots) right when it's most available — the ephemeral build environment before it's torn down. A build badge in the README gives visitors an at-a-glance health signal for the default branch.

Env Vars + Matrix

env:
  - DATABASE_URL=postgres://localhost/test_pg
  - DATABASE_URL=mysql://localhost/test_mysql

Combining env with a language-version matrix expands coverage across meaningfully different runtime configurations, not just versions.

Travis CI vs. GitHub Actions

Many open-source projects migrated to GitHub Actions after Travis CI's free tier for open source became more restricted — GitHub Actions offers generous free minutes for public repos and integrates natively into GitHub, with no separate connected third-party service needed. Both share the same broad YAML-config-as-code philosophy, so core concepts (build steps, caching, matrices, deploy gates) transfer between them.

Keep your own version of these notes — editable, searchable, and organised by your stack.

Start free