"In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps. . . ." — https://12factor.net/
I. Codebase
One codebase tracked in revision control, many deploys
Tiki Wiki CMS Groupware ("Tiki") is tracked in two version control systems: Git and SVN (deprecated), currently Git is the default.
Tiki uses the same codebase with different releases. A major branch is done only once per major version (4.x, 5.x, 6.x, etc.) about 4-6 weeks before the planned official release of x.0. For minor versions, the work is done in the current branch.
II. Dependencies
Explicitly declare and isolate dependencies
Tiki uses Composer to manage the dependencies. All dependencies are declared in vendor_bundled/composer.json and to extend some Tiki features it is possible to install via Packages using the UI, these additional dependencies are also managed by composer.
III. Config
Store config in the environment
Tiki does not store config as constants in the code and uses different environment files.
The db/local.php file stores some config settings but, it's also possible to extend configurations between environments, see System Configuration for more information.
IV. Backing services
Treat backing services as attached resources
Tiki makes no distinction between local and third-party services. Tiki is able to swap out, for instance, SMTP service without code changes and local MySQL database by a third party using configuration files.
V. Build, release, run
Strictly separate build and run stages
Tiki strictly separates build and run stages storing new releases as <number>.x, for example, 22.x.
VI. Processes
Execute the app as one or more stateless processes
Tiki has data that needs to be persistent; however, that data is stored in a stateful backing service like database, Memcached or expiring sessions.
VII. Port binding
Export services via port binding
Because Tiki uses PHP, probably the code is being executed using PHP-FPM which exposes a binding port to communicate with Apache/NginX.
VIII. Concurrency
Scale out via the process model
Tiki does not rely on daemonize processes or write PID files, in fact it uses system processes to handle the requests and background tasks.
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
For a web application like Tiki, this factor is achieved automatically, since PHP-FPM handles system signals like SIGTERM or QUIT out-of-the-box closing existing connections and refusing newer ones when the process stops.
X. Dev/prod parity
Keep development, staging, and production as similar as possible
Tiki uses continuous deployment, making the code being pushed and the production code almost identical and available to use by other developers. See: Sync Dev-Prod Servers
XI. Logs
Treat logs as event streams
Tiki does not have a single log file that can be used as a stream, but depending on some tasks log files are created (like index rebuild) or other operations/actions are logged in the database as action logs, used to track user activity on the basis of a single user or multiple users, groups or categories.
XII. Admin processes
Run admin/management tasks as one-off processes
Tiki offers administrative and maintenance tasks (see console.php), such as:
- Running database migrations
- Running a console command
- Running one-time scripts
The admin processes run in an identical environment as the regular long-running processes of the app, and they run against a release, using the same codebase and config as any process run against that release. The admin code is included in the version control system.