I took advantage of the updating of our environment for taking the time to write a few words about our technical environment...
Platform Triple Performance is built around two software components : Mediawiki on the one hand (the software that runs Wikipedia), and a brick "back-office" developed from a framework Laravel.
All of our software environment running with Docker, which allows you to isolate each software component. Thanks to Docker, we can perfectly reproduce the production environment on the position of each developer, whether it be Windows or Linux. In addition, Docker allows you to finely configure each component of the environment (for example, the version of PHP or MySQL) configuration. Thus, we can test the installed version, by changing a number in a file.
Our stack docker is composed of a dozen of containers, each of which plays its own role : Traefik in proxy for all inbound connections, also manages the updating of certificates for HTTPS (thanks to the extension ACME), the software components are each served by their own container (PHP-FPM, Nginx), and we then containers for MySQL, Redis, ElasticSearch, as well as some services like software Parsoid, which allows the conversion of HTML files to wikitext, and vice versa.
If you're curious, all of our configuration Docker is on github. An interesting point, our platform is designed from the ground up to allow updates " on the fly ", the images Docker is generated automatically on Github and as additions functional. Thank you Michel Roca to Huytéza for his assistance and advice on these subjects !
We operate according to the principle of " document by configuration ", which means that the whole of the update process, instance creation, migration, etc... are to be executed by a single command.
Brick back-office is developed in TDD (Test Driven Development) : for each new feature, we first created a test, and the feature is deemed to be complete when the test " passes ". In reality, this mode of development requires an organization of the software and partitioning very own of each layer (implementation, model, controllers, views, storage). Thank you Guillaume Cozic for that, his expertise has been invaluable !
A word finally on Github : to the extent that we believe that knowledge should be a mutual, we believe that the software code must be open and open source. The choice of Github has established itself quickly. Github allows us to not only share and work collaboratively with the various technical stakeholders (source code, bug management, notifications, integration with Slack, etc...), but also allows the connection with systems of continuous integration and the validation of the quality of the code, which are pretty fantastic. We are thus alerted if one of our dependency no longer up to date and if there are new security alerts which require action on our part. For developers who work on our project, this opening serves to faith as a demonstration of their experience, but also requires them to maintain a quality of code and process, knowing that the whole of what they do remains visible of all.
A little story about the awesome power of open source : in a test update, we have had a weird problem (CSS not generated). The CSS file then displayed an error "SCSS compile error" :
- I allowed myself to open up, to 13h09, a bug at the project level MediaWiki that allows the building of our skin.
- To 13h50 I had a first response.
- To 15h37 a bug is then opened by the last person in the library causing the problem.
- To 17h32, there were three people in the discussion, and the decision was taken to make a new release of this library with the patch.
- Two days later this release was available – without touching anything in our code all to get back to work. Hard to do better ! (Thank you to the contributors, it should be noted that they are widely europeans !).
