WordPress i git, fent amics: l'impacte de Bedrock en el control de versions

Dins l’univers del desenvolupament web, WordPress és un pilar clau. És el framework que fa funcionar la major part de la web. I tot i ser-ho, són moltes les complicacions relacionades amb el control de versions i les discrepàncies entre entorns que comporta fer servir WordPress. És en el marc d’aquest problema en què Bedrock entra en joc com una eina molt útil per dotar de més ordre i més claredat l’estructura d’unprojecte WordPress.

Mirar enrere no sempre és bo

Els problemes del desenvolupament amb un WordPress tradicional (és a dir, sense Bedrock o algun altre framework de l’estil), tant pel que fa a no tractar correctament els fitxers de vendor en el control de versions com pel que fa a les discrepàncies entre entorns, s’etomen millor amb una eina com Bedrock. La seva estructura no tan sols simplifica el procés de treball amb Git, sinó que també imposa un nou estàndard en el desenvolupament en el marc de WordPress, un en què predominen la claredat i l’eficiència.

En el desenvolupament tradicional de WordPress, sovint s’acaba tenint un repositori ple de fitxers de tercers (vendor), és a dir, fitxers de tercers, com ara WordPress mateix, plugins no modificats descarregats del Repositori de Plugins de WordPress, etc. Això, que és lluny de ser ideal, ocorre a causa de la pràctica d’incorporar directament plugins i temes a la codebase del projecte, que el WordPress tradicional esperona.

Atès que WordPress de partida no té cap mecanisme que permeti gestionar aquestes dependències fora de la instal·lació central i del projecte complet, els desenvolupadors es veuen obligats a incloure manualment aquests plugins i temes en el control de versions, i també les seves actualitzacions, dins del seu sistema de control de versions, o a recórrer a alternatives sovint maldestres. Aquesta pràctica estàndard, tot i ser senzilla i comprensible, malmet el repositori de control de versions, perquè l’omple de molts fitxers necessaris per a fer funcionar el web, però innecessaris dins el repositori git, i molestos.

És aquí on Bedrock destaca, tot millorant moltíssim l’organització i la simplicitat. Mitjançant Composer, Bedrock ofereix una solució ben pensada a aquest problema, que permet la declaració de plugins i temes a mode de dependències. Aquest canvi no només li treu al repositori el pes innecessari d’allotjar els fitxers de tercers (vendor), sinó que a més posa en marxa un procés més eficient per gestionar les actualitzacions. Això facilita que els esforços es puguin centrar en les actualitzacions i la funcionalitat del web, i no en pensar com duu a terme les actualitzacions de plugins i temes.

Composer, el gestor de paquets de PHP, fa, tal com li correspon, de director d’orquestra en l’ecosistema de Bedrock, coordinant els diversos components que donen vida a un projecte. En essència, és una eina de gestió de dependències per a PHP que automatitza la inclusió de paquets de programari i les seves dependències, i té cura que sempre s’usin les versions més recents de les eines necessàries.

Tan sols cal indicar en un fitxer JSON simple els paquets de tercers necessaris per al projecte, i Composer s’encarrega de gestionar tot allò que sigui necessari. A més, Composer permet instal·lar i actualitzar els paquets en processos posteriors d’actualització o manteniment. Aquest procediment millora el flux de treball i minimitza els errors. Per als desenvolupadors de WordPress que volen millorar els seus projectes, Composer és un aliat i una millora clara que comporta pràctiques de desenvolupament més modernes i eficients.

La incorporació de Composer al desenvolupament de WordPress, un afegitó que Bedrock incorpora de manera molt ben engeixada, canvia radicalment la forma en què els desenvolupadors podem interactuar amb Git, i fomenta el compliment de les millors pràctiques en el control de versions. En un entorn tradicional de WordPress, la necessitat d’incorporar al respositori git cada plugin i tema no només incrementa la mida del repositori, sinó que també genera desordre i augmenta la complexitat de gestió. Cada actualització, addició o retirada d’un component de WordPress requereix una gestió manual ad-hoc per tenir content el git, i ni tan sols així s’eviten les incoherències i haver de d’executar una sèrie de tasques feixugues només per mantenir l’ordre.

Utilitzant Composer dins l’enfoc de Bedrock, la inèrcia passa de ser la incorporació manual de cada fitxer de tercers a una gestió més òptima de les dependències. Amb Composer es poden gestionar plugins, temes i fins i tot el propi nucli de WordPress, de manera que el repositori git acaba quedant lliure de codi de tercers. La forma en què això passa és la següent: els plugins i temes es registren al fitxer composer.json, cosa que de retruc permet que qualsevol persona d’un equip pugui desplegar el projecte ràpidament, i només li calgui executar composer install per acpnseguir-ho. I tot això sense haver de tenir els vendor en el repositori, contràriament al que passa amb el WordPress tradicional.

Una millora d’aquestes característiques afavoreix moltíssim la reducció de l’espai en disc que ocupa el repositori i emfatitza el codi propi front al de tercers. Cada actulaització d’un plugin es manifesta en els canvis com un conjunt de poques línies modificades al composer.json, en comptes d’innundar el control de versions de nous canvis i nous fitxers. A més, això va en consonància amb les bones pràctiques de git, cosa que millora les possibilitats de col·laboració i de manteniment del codi, així com els processos de revisió.

WPackagist: plugins i temes de WordPress preparats per a Composer

WPackagist és el recurs indispensable per treballar amb WordPress en entorns gestionats per Composer. El projecte WPackagist, que es va iniciar en una agència de desenvolupament del Regne Unit i no relacionat directament amb Bedrock, replica automàticament el repositori de WordPress plugins i temes de WordPress en un format que Composer pot processar.

Aquesta adaptació permet als desenvolupadors gestionar els components de WordPress d’una forma millor, perquè combina la comoditat de la resolució de dependències de Composer amb la versatilitat de l’extens ecosistema de WordPress. Primer cal especificar WPackagist com a repositori en el composer.json del projecte, i un cop fet això, es pot incloure qualsevol plugin o tema de WordPress com a part de les dependències gestionades per Composer. Això optimitza l’organització i manteniment del projecte en constituir les millors pràctiques en el control de versions.

En el context d’un projecte Bedrock, la integració de temes i plugins de WordPress dels repositoris oficials esdevé així un procés que té més sentit, gràcies a WPackagist. Això s’aconsegueix a través de la comanda ‘composer require’, que cal fer servir conjuntament amb el prefix wpackagist-theme o wpackagist-plugin, segons s’escaigui.

Per posar un exemple, després de trobar un tema en el repositori oficial de WordPress que es vol incorporar al projecte Bedrock, cal fer servir wpackagist-theme/ com a prefix de la comanda composer require, seguit de l’slug del tema en el repositori oficial de WordPress. Aquesta instrucció incorpora directament el tema com una dependència dins el fitxer composer.json i l’insta·la en el directori corresponent dins del teu projecte. El mateix procediment es pot aplicar als plugins, prefixant l’slug del plugin amb wpackagist-plugin/.

La interacció entre WPackagist i Bedrock enriqueix encara més tot el procés. Bedrock configura els projectes de desenvolupament de WordPress perquè sigui fàcil treballar amb Composer, mentre que WPackagist garanteix que els temes i els plugins del repositori de WordPress estiguin disponibles com a paquets Composer.

12 factors que milloren WordPress

Hi ha una intersecció molt interessant entre Bedrock, WPackagist i una cosa anomenada els principis Twelve Factor App, una metodologia de gestió del desenvolupament de programari que Bedrock adopta, que ajuda a avançar cap a pràctiques de desenvolupament de WordPress més sostenibles, eficients i escalables. Vegem amb una mica més detall com es manifesta aquesta intersecció en la pràctica.

En integrar la manera d’estructurar de Bedrock i la manera de gestionar dependències de WPackagist en el desenvolupament WordPress, no només es millora la relació amb git, sinó que també es passa a seguir de manera precisa els preceptes de la metodologia Twelve Factor App. En particular, aquells relacionats amb la codebase, les dependències i la configuració, que són els més relacionats amb la gestió del control de versions.

La manera de treballar de Bedrock permet desplegar una única codebase en diversos entorns amb poca fricció. Això constitueix un principi central de Twelve Factor App, que destaca la importància d’un codi sota control de versions que és coherent en totes les fases del desenvolupament. Mitjançant la gestió de temes i plugins a través de WPackagist i Composer, els desenvolupadors poden passar a considerar WordPress i les seves extensions com una part més de les dependències del projecte, de forma que l’aplicació completa es pot versionar amb precisió.

La forma habitual i tradicional de fer això que és integrar els plugins i temes directament dins del repositori tot sovint resulta en una codebase desbordada i amb què és difícil treballar-hi. Mitjançant Bedrock i WPackagist, les dependències són passen a ser declarades en un fitxer composer.json, i Composer s’encarrega del procés d’instal·lació. Aquest procediment no només ajuda a mantenir el repositori més net, sinó que també garanteix que les dependències estan aïllades i es poden instal·lar de forma coherent en diversos entorns, tal com demana Twelve Factor App per gesitonar les dependències.

A més, el sistema de configuració de Bedrock utilitza variables d’entorn per gestionar credencials sensibles i arranjaments específics per a cada entorn, de manera que estan separats del codi. Això concorda amb la metodologia Twelve Factor, que promou una separació estricta entre la configuració i la codebase. Aquesta separació està pensada per tal que la configuració de l’aplicació sigui adaptable a l’entorn de desplegament, de manera que el mateix codi es pugui fer servir, per exemple, en local i en producció, sense tocar el codi. Aquest enfocament també millora la seguretat, perquè fa més fàcil garantir que els secrets queden fora del control de versions.