Building Planet 4: from tech team to software.
The right resources and the right tools to develop the prototype of an engagement platform (not always the right words to explain it all).
Since April, when Lilian majestically summed up the preparatory work and described the architecture of each Planet 4 website, many exciting things happened on the tech side. In the words of my Italian editor, “in parallel with the design track, the technical work stream has continued its investigation and started implementing workflows and methodologies to ensure that the transition Concept-Development-Deployment will happen smoothly”.
Building the right team for an engagement platform
The specialists composing the technical squad are not newborns, but it took 9 months to find them and complete the team, which is now ready to rock and to evolve in the years to come.
Starting from the Development team, 3 new code-wizards recently started rocking Planet 4: Angelos, Ashish and Sagar, respectively PHP, Frontend and PHP developers. These gents’ first order of business is to analyse each requirement, and identify if it exists as functionality in the Wordpress core. If it exists, they have to write tests for it. If the functionality, on the other hand, does not exist in core, they will have to search among the available 3rd party plugins and perform functional fit and security analysis on any suitable ones found. As a last option, if no 3rd party plugins suitable enough to do the job are found, the developers will have to build the functionality (two examples can be seen at https://github.com/greenpeace/planet4-plugin-engagingnetworks/ and https://github.com/greenpeace/planet4-plugin-action-content-type) following our coding standards.
In parallel, extensive work is required to create the P4 theme and to “dress up” any 3rd party or new custom plugins by our FrontEnd developer.
Being at the end of the design phase, and having identified the full requirements and the scope of the 40+ migrations in the pipeline, it has become obvious that 3 developers cannot deliver all the work. Therefore, like the musketeers, those three Developers will become four.
In close collaboration with them, a highly specialised gang of System Operators will operate, to ensure the Planet 4 infrastructure will support all the custom development and the insane amount of traffic it will (hopefully) get. These are Simon, Larry, Alen and Ray, spread out in three different continents (because too much awesomeness in the same place would probably create a singularity, and the cosmos has enough problems already).
By the end of this month, though, 2 awesome guys will leave the team to follow their paths to happiness and infinite knowledge. To Diego and Rémy goes all our gratitude for the great work done so far, what you did is amazing. May the Force be with you.
One service to integrate and deploy them all. One service to test them.
As previously announced, the Planet 4 Jenkins Continuous Integration (CI) server is up and running and successfully performing automated jobs, such as creating the development and staging environment and running the selenium tests. To configure the jobs needed to automate the deployments and run the tests, our developers will simply have to commit their code to git, and Jenkins will do the rest.
On the testing side, the final choice has been made. Selenium has been setup as the official testing server, and the initial tests (using phpunit) have been written to test both Wordpress core and newly developed functionalities .
Deploying the Greenpeace registry and the first plugins (while documenting the review process)
Following the approach shaped in the Discovery Phase, we have been (and still are) fine tuning and documenting the full process to deploy custom or 3rd party plugins in Planet 4 core and instances. Even though each P4 will have its own Wordpress instance, to maintain high standards of security, site administrators will not be able to install or update plugins from the administration on local live production sites. They will have to follow instead the predefined and documented process:
For deployment, the Tech team has identified the possible best tools’ suite for Planet 4 needs: Composer, wp-cli and a Greenpeace plugins registry.
Such tools’ trinity will be used following two simple rules to deploy plugins who will pass the review check:
- Custom made (or 3rd party) plugins with code in github will be directly added to the Greenpeace registry (by a GP developer)
- 3rd party plugins without code on github will have a custom repository created by the P4 Development team. Those repositories need only to contain a composer file, pointing to the location where the plugin lives.
( even though this specific plugin won’t be used, you can see an example at https://github.com/greenpeace/planet4-plugin-mappress-google-maps-for-wordpress ).
Following this approach, the structure of the first Planet 4 custom plugins has been created. You can check the full list or the Engaging Networks specific one, which is currently being iterated.
Establishing P4 git workflow, security audits and coding standards
Learning from our past mistakes (because, sometimes, we are too stubborn to learn from others, and we have to make our own mistakes) we have established and are following specific steps and methodologies, especially when coming to coding, git workflow, security auditing and site theming.
- A Git workflow (gitflow), will ensure that features get published to the live site when they will be ready.
- The (continuously evolving) Planet 4 coding standards will guarantee that the whole team will be able to read each other’s code, while theming frameworks ensure that code will be maintainable and extendable.
- Independent code security audits will be crucial not only to ensure that visitors’ data are treated with the highest respect, but as well that the team avoids security breaches when modifying or introducing new code.
Next: integrations and development of user stories
Planet 4 will drive people to action, and those actions may be either taken through Wordpress plugins (or functionalities) or 3rd parties systems, like petition and advocacy tools, for example. Each Greenpeace office has its own “engagement systems suite”, normally composed by advocacy, email marketing, volunteer management, database, mobile / tablet apps, insights tracking and open campaigning tools, in all sorts of combinations and subsets.
The Planet 4 “Minimum Loveable Product” (MLP) will not be able to ensure integrations with all existing systems. The Technical team, therefore, will focus on the most widely used and globally endorsed tools to develop the first integrations, and, at prototype launch, will deliver the following solutions:
- Engaging Networks integration for advocacy and donations;
- The (Google) Analytics 360 integration, following the vision of the KPI track (mostly involving Tag Manager and Analytics tracking codes);
- ElasticSearch integration as main Search technology (this is not 100% official yet. Multiple variables are affecting the delivery of this tool’s integration with the MLP, first and foremost whether Google will offer this as a service by October) (UPDATE: we were just informed today that it started getting offered as Beta, so we jump in to test it!);
The main area of focus in the next 2 months will be, however, the development of the MLP user stories. In collaboration with the rest of the Planet 4 team, we will connect all the dots from the tracks (Design, KPIs, GPI migration project..) and release all the functionalities to make Planet 4 a revolutionary tool to change the way people do online activism.
Not too long before you see the first Planet 4, but in the meantime, feel free to comment, ask your questions or offer your help by commenting below.
Be well and misbehave.
