Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager.
A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest.
If the app needs to shell out to a system tool, that tool should be vendored into the app.
Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.
The twelve-factor app stores config in environment variables (often shortened to env vars or env).
The code for a twelve-factor app makes no distinction between local and third party services.
The twelve-factor app uses strict separation between the build, release, and run stages.
Releases are an append-only ledger and a release cannot be mutated once it is created.
Execute the app as one or more stateless processes.
Twelve-factor processes are stateless and share-nothing.
Export services via port binding.
The twelve-factor app is completely self-contained.
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown.
Keep development, staging, and production as similar as possible.
The twelve-factor developer resists the urge to use different backing services between development and production.
Treat logs as event streams.
A twelve-factor app never concerns itself with routing or storage of its output stream.
Run admin/management tasks as one-off processes.