Infrastructure Guidelines


We use 3 environments: development, testing and production.

Application will know which database to connect to, which resources to use, etc from a configuration file, or better, environment variables (

Application code always lives in Git. It is deployed to the various environments either as a Git checkout, or using a specialized tool (Jenkins + rsync or such).


Typically, this is the localhost of each of the developers. This is the only environment where code changes are allowed. It’s possible for the database structure or resources configuration to get temporarily out of sync with the code base.

Testing & Production

Testing serves to allow testers (internal or external with customer) to try out changes in the application before it hits the production. The purpose of production is probably clear :)

One important rule: application changes should (must) be deployed atomically. This means that if I change some code that needs an updated database schema, I must upgrade the schema at the same time (atomically) as I deploy the updated code – otherwise the application could crash or even corrupt data.

Of course, never deploy to production anything that was not previously verified on testing.

Upgrade procedure

  1. Take the application down – redirect to static server, other instance, …
  2. Upgrade the database (execute the SQL patch).
  3. Upgrade the code base (git pull or rsync or whatever).
  4. Start the application.