=============================== Your production environment(s) =============================== You'll probably have a dev environment and at least one production(-like) environment. Spynl helps you to: * keep the code consistent between deploys to each of them * Make sure test do not affect real users and unfinished things are turned off in production * allow a third party to control your prodcution pipeline Docker --------------- We use Docker to ship Spynl. You can be sure there that you look at the same code in dev and production. (`/about/versions` can help you to look up precisely which code is in there). `/about/build` helps you to see when the Image was made (built on Jenkins) and when it was started. The image is Ubuntu-based. Custom pre-install and post-install hooks are possible in `setup.sh` (also works for `dev.install`) `prepare-docker-run.sh` can influence `production.ini` or other relevant things in the Docker container right before it is run. Possibilities to turn off endpoints and whole resources on production ----------------------------------------------------------------------- (TODO: add issue about a more generic approach) Do not send emails to real addresses from non-production environments ---------------------------------------------------------------------- TODO: link to the email section Using different container registries for dev and for production ----------------------------------------------------------------- Useful if you keeo them separated or a thrid party manages your production pipeline (e.g. when using a DTAP approach).