There is a direct relation between the three MEMFacts main instances (or environments) and 3 of the branches that we are using in official repository:
- memfacts.org pulls from
stable - memfacts.staging pulls from
master - memfacts.dev pulls from
dev
The reason of stable existence is mainly to have a parallel line with master that delays merges up to 1 day in order to allow reviews and QA to be made first.
master is the branch that we are always looking at for quality control, which means that eyes are putten at memfacts.staging considering that what is shown there today is what the world will see tomorrow.
dev is an example branch of a development line for a specific feature, but it is also a real one in the official repository and has the memfacts.dev instance running in order to dispose an experimental place.
There are other branches set in the official repository, such as bugfix and content that have been reserved in order to keep things ordered as much as possible. At the point of writing this document, changes activity is ceasing, so current branches seems enough for the moment, though any other branch could be created at official repository if there is the need to do so.
In case of a developer working at its own fork, he could work in a custom branch created by him, and, unless previously agreed to do in a different way, his changes would commonly go to the master branch through Pull Requests, meaning that memfacts.staging will be updated once they are merged.
-
A bug has been fixed and needs to be tested before nightly merge:
bugfix->master: manual PR Note over master: memfacts.staging auto-sync Note over master: review: approved master-->stable: nightly pull Note over stable: memfacts.org auto-sync -
A bug has been fixed and there is an urgency to make it live:
bugfix->master: manual PR Note over master: memfacts.staging auto-sync Note over master: quick review: approved master->stable: manual PR Note over stable: memfacts.org auto-sync -
A bug has been fixed and there is a need to merge into the development of a specific feature as well since it's not only stucking it but also affecting production:
bugfix->dev: manual PR Note over dev: memfacts.dev auto-sync Note over dev: feature development continues bugfix->master: manual PR Note over master: memfacts.staging auto-sync Note over master: review: approved master->stable: manual PR if urgent master-->stable: nigthly pull otherwise Note over stable: memfacts.org auto-sync -
Development of a feature has finished and is ready to be deployed if approved:
dev->master: manual PR Note over master: memfacts.staging auto-sync Note over master: review: approved master-->stable: nigthly pull Note over stable: memfacts.org auto-sync -
Feature or bug fix was not approved and we are too close from midnight (Central time):
dev/bugfix->master: manual PR Note over master: memfacts.staging auto-sync Note over master: didn't review or dissapproved master->dev/bugfix: manual revert Note right of stable: memfacts.org remains the same
Initially, caching API results was an approach to speed up the process and respond faster to visitors, which actually worked very well. But now its dumps are being stored as historic backups that can avoid breaking pages when data sources can't be found or there is a problem with current API results. The solution consist in making use of the last working version for a problematic data source.
This behavior, as well as cache, is only running on the production side in order to avoid missunderstandings during reviews and development because of cache disabling to see a real full run of the query. This is also the reason of why the application responds way much faster from production.
By the other hand, instead of cache, memfacts.staging and memfacts.dev have a higher debug level, which is disabled in production.
Repository admins