Requirements for build, test, a deployment process

[FedericoCeratto]

This issue is meant to gather requirement and ideas around building, testing, deploying and configuring OONI components.

• Deploy and run with limited CPU/RAM overheads
• Run integration testing
  • More easily: e.g. simpler configuration, less moving parts, running on external buildbot
  • On limited hardware: e.g. use small VMs, shared VMs, external buildbots, workstations
  • Encourage catching more errors before deploying on prod
• Quickly build and deploy on testbeds
• Prevent unexpected changes from reaching prod
• Test re-deploying a product or a whole host with little manual effort
  • To restore a broken host
  • To ensure the infra is redeployable
• Allow 3rd parties to deploy [part of?] our infrastructure with minimal cognitive overhead
  • Without whole rebuilds
  • Allowing configuring different domains / hostnames
• Reduce cognitive overhead and complexity in general
• Reduce attack surface
• Limit entry bar for contributors
  • Support osx and Linux workstation
  • Allow simple modifications without local build / test infra

[hellais]

Another thing to consider in this is the ability to do rollback if a deployment was not successful (for example with Docker images you can just rollback to another image version).

[hellais]

This may also be relevant to look at: https://github.com/ooni/sysadmin/issues/381

[FedericoCeratto]

Investigate DNS management with github actions: https://github.com/marketplace/actions/dnscontrol-action

[FedericoCeratto]

Investigate delivering probe updates from multiple domain including ooni.org After further discussion it has been decided to investigate CircleCI and Bintray for building and delivering packages. (See https://github.com/ooni/pipeline/pull/253 )

[hellais]

Related: https://github.com/ooni/sysadmin/issues/364

[FedericoCeratto]

Investigate Btrfs to allow resetting VMs and implement green/blue deployment

[hellais]

xref: https://github.com/ooni/sysadmin/issues/412