History: The twelve-factor app

            ''"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. Co~np~~/np~debase
__One co~np~~/np~debase 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 co~np~~/np~debase 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 [https://gitlab.com/tikiwiki/tiki/-/blob/master/vendor_bundled/composer.json|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 [https://gitlab.com/tikiwiki/tiki/-/blob/master/console.php|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 co~np~~/np~debase and config as any process run against that release. The admin code is included in the version control system.