Infraestructura tècnica
La infraestructura tècnica necessària per a allotjar un projecte de programari lliure consta típicament de diferents elements i eines, molts cops vinculades entre sí de maneres complexes. En aquest capítol recomanem algunes eines i pràctiques d’ús comú en el sector.
Un principi general que es veu concretat en les mesures d’aquest capítol és que les persones que participen en un projecte mai s’han de veure obligades a instal·lar programari privatiu a les seves màquines.
Llocs web associats al projecte
Un projecte de programari pot tenir típicament dos tipus de lloc web:
Una web de desenvolupament, orientada a persones que contribueixen al projecte amb codi o documentació tècnica, contractades per l’Ajuntament o no.
Una web orientada a persones usuàries i participants en general. Això inclou a persones o entitats que puguin voler instal·lar i usar el programari fora de l’Ajuntament, però també a gent interessada en el projecte encara que no siguin usuàries directes del programari. En aquesta web s’ha de facilitar i incentivar a participar en el projecte amb contribucions menys (o gens) tècniques: finançament, documentació d’usuària, test de pre-releases, difusió, traduccions, etcètera.
Normalment els dos tipus de contingut son necessaris, però no sempre cal que es trobin en dos llocs separats, amb noms de domini diferents. En cada projecte que lideri, l’Ajuntament haurà de valorar fins a quin punt les necessitats i mentalitats dels dos conjunts de persona son diferents i resulta per tant impossible que un únic model de web s’adeqüi als dos grups.
A l’apartat Repositori de codi i control de versions s’explica com crear la web de desenvolupament, que és l’única que es necessita des de bon començament. A mida que el projecte creix, es pot valorar si cal també un lloc orientat a d’altres perfils de participant.
El que sí és interessant tenir des del principi és un nom de domini propi (o una URL permanent sota algun domini de l’Ajuntament), que si cal es pugui redirigir cap a on es trobi inicialment la web del projecte (possiblement un lloc com GitHub).
Repositori de codi i control de versions
Un element central de la web de desenvolupament d’un projecte és un repositori de codi (públic i sota control de versions) que serveixi de base per centralitzar les modificacions que han de formar part de cada nova entrega release del producte.
En l’escenari NouProducte o Plugin l’Ajuntament haurà de crear aquest
repositori. En el cas d’una Integració o Adaptació, l’Ajuntament tindrà la
seva pròpia còpia (clone o fork) del repositori original (upstream), on
centralitzarà els treballs corresponents a les modificacions del seu
interès. A aquest repositori que crea l’Ajuntament i que serveix, o bé per
realitzar les entregues d’un producte original, o bé per centralitzar les
contribucions a un projecte extern, en direm repositori principal. Poden
existir moltes altres còpies públiques i privades del codi.
|
L’Ajuntament està reconsiderant la plataforma que s’utilitzarà per allotjar coses com els repositoris de codi públics o els gestors d’incidències de cada projecte. Els primers projectes de programari lliure de l’Ajuntament han utilitzat GitHub, però ara volem passar a una plataforma que:
Les nombroses referències a GitHub en les següents seccions seran substituïdes quan es prengui una decisió. Cal tenir en compte les avantatges de GitHub que s’indiquen a continuació per triar una alternativa. Qualsevol alternativa ha d’oferir garanties similars quant a durabilitat i sostenibilitat. Una possibilitat viable és una instal·lació autogestionada de Gitlab. Hi ha un cas d’ús reeixit per a l’administració pública a França. |
Com s’indica en les mesures de més avall, el repositori principal s’allotjarà a GitHub, un servei que utilitza Git com a sistema de control de versions distribuït. El vocabulari i conceptes fonamentals per entendre el seu funcionament es pot trobar a Version Control Vocabulary.
Hi ha moltes alternatives viables i raonables a GitHub, i fins i tot algunes alternatives viables a Git com a programari de control de versions, però GitHub ofereix prous avantatges com per què sigui la opció per defecte:
-
La majoria de desenvolupadores la coneixen i no han d’aprendre noves eines i procediments ad-hoc per al projecte.
-
Llança el missatge de que el projecte està obert a col·laboració.
-
Ofereix una bona integració amb la resta d’infraestructura tècnica i social d’un projecte: gestió d’incidències, integració contínua, canals de comunicació per a desenvolupament, etc.
-
Permet també guardar i mostrar (part de) la documentació d’un projecte, que pot ser una wiki. La presentació de la informació és suficientment agradable com per permetre aplaçar la construcció d’una web orientada a persones usuàries i participants en general del projecte.
-
És la plataforma més utilitzada per projectes de codi obert, dóna molta visibilitat.
|
Inconvenient: GitHub no és 100% codi obert. Tot i ser un servei gratuït per un gran ventall de possibles usos, no tot el codi de la infraestructura que hi ha darrera de GitHub és lliure, i en darrera instància s’està establint una dependència amb una empresa que no sabem com evolucionarà en el futur. Més endavant poden aparèixer opcions que facin reconsiderar aquesta recomanació de fer servir GitHub com a opció per defecte. |
Gestor d’incidències
Una eina que tots els projectes de codi obert necessiten és un gestor d’incidències. Als projectes de l’Ajuntament li assignarem les següents funcions:
-
Notificar els defectes detectats (bug tracker) per part tant d’usuaris com de desenvolupadors. També fer-ne transparent el tractament, evolució i eventual solució. És important que els commit que resolen un defecte o assenyalin en el seu missatge. GitHub té una sintaxi especial per fer això.
-
Fer seguiment de les tasques pendents. Això permet després vincular un o més commit amb el tancament d’una tasca. També poder veure a qui s’assignen les tasques i com es prioritzen. Opcionalment s’hi poden especificar dates estimades de realització. Tot plegat contribueix a la transparència i traçabilitat del procés de desenvolupament.
-
Fer seguiment de com es gestionen les contribucions de diferents parts, mitjançant el mecanisme de pull request. Fins i tot es pot obrir el gestor d’incidències a peticions de funcionalitats (feature request) i es pot utilitzar l’espai de GitHub com a lloc on es prioritzen i gestionen de manera pública.
S’ha de tenir en compte que el gestor d’incidències no és només important per al dia a dia dels desenvolupadors, sinó que molts observadors del projecte també el fan servir com a mesura de fins a quin punt estan davant d’un projecte seriós.
Aquest gestor d’incidències ha d’estar operatiu i públic durant tota la vida útil del producte, més enllà de la duració que tinguin els contractes amb l’Ajuntament.
Canals de comunicació interns i externs
Els primers canals de comunicació entre desenvolupadors son els missatges de commit del repositori i els fils del gestor d’incidències. Moltes decisions tècniques es prenen en aquests fils, però convé que les discussions que s’hi duen a terme siguin sempre molt focalitzades i estrictament tècniques. Quan l’àmbit de la discussió s’eixampla, cal recórrer a d’altres canals.
Tots els projectes nous han de crear inicialment una llista de correu o fòrum de discussió per a desenvolupament, amb arxius públics. En aquest canal és on es demana la opinió a les diferents parts o persones que participen en el projecte, i on es prenen les decisions estratègiques.
Inicialment hi haurà poca distància en quant a inquietuds i llenguatge entre els desenvolupadors i els primers usuaris (early adopters), que acostumen a estar molt motivats. Per això, en molts casos podran compartir el mateix canal. Més endavant pot ser necessari crear canals de comunicació especialitzats pels diferents tipus de participant.
Depenent de la naturalesa i composició de l’equip, pot resultar convenient disposar també d’un xat que permeti una comunicació més immediata. De tota manera el xat és complementari amb la llista o fòrum, mai l’ha de substituir. La llista o fòrum és on queda registrada de forma referenciable tota la història del projecte (debats, decisions, etcètera), que és un actiu molt valuós per a tota la comunitat present i futura del projecte.