Vermutech #20
Aquesta setmana, poques novetats tècniques però moltes emocions! Són les fires de Girona, i feia temps que no em deixava caure per barraques, però aquest any hi havia un concert que no em podia perdre: Banda Bassotti + Inadaptats. Feia molt que no veia Inadaptats (des del seu concert de comiat el 2005), i la veritat és que va ser igual que en els vells temps. A més, vaig retrobar molta gent d’aquella època amb qui feia temps que no ens vèiem 😊
També comença un nou mes, i aquest any serà l’onzè en què participo al Movember, un moviment que promou la salut masculina. Si vols fer una donació, ho pots fer tant al meu perfil com al grup que tenim muntat alguns de GISCE-TI.
Començo amb algunes recomanacions,
💾 Programari
Autossh:, Potser no descobreixo res de nou, però és una eina tan útil en el dia a dia que si algú encara no la coneix, li solucionarà problemes. A vegades ens compliquem la vida muntant VPNs quan només volem exposar un port, i amb un túnel SSH i autossh això és facilíssim!
🤔 Curiositats
WhenFS: Un sistema de fitxers que ningú necessita, però que utilitza Google Calendar com a backend 🤯. La veritat és que és molt curiós.
📦 Recursos
Slingcode: Una plataforma per crear apps amb un sol fitxer HTML. No necessita servidor; és només simple HTML.
🌟 El concepte
Després d’introduir conceptes essencials com els repositoris de codi (Vermutech #17) i les pull requests (Vermutech #19), avui toca parlar d’una peça clau en el procés de desenvolupament col·laboratiu: la Integració Contínua (CI). Aquesta metodologia busca que cada canvi de codi que es fa en una branca es revisi i es provi de forma automàtica abans d’integrar-lo a la branca principal, de manera similar a la metodologia TDD (Test-Driven Development) (Vermutech #13) que ja vaig comentar. En aquest cas, la CI s’assegura que qualsevol modificació al codi es testi de forma rigorosa, i així, cada nou commit es valida automàticament, cosa que permet detectar errors al moment i evita regressions.
Amb la CI, aconseguim que el codi es mantingui estable mentre altres desenvolupadors fan aportacions simultàniament. Aquesta metodologia ens ofereix grans avantatges:
Reducció de riscos: Cada canvi es prova immediatament, evitant acumulacions de codi sense revisar.
Millora de la col·laboració: Amb les pull requests com a base del procés, tothom pot veure si el codi passa les proves o si hi ha algun error, cosa que fomenta un flux de treball transparent.
Codi de qualitat: Les proves automatitzades detecten regressions, assegurant que el projecte evoluciona sense comprometre l'estabilitat.
La CI també aprofita la cobertura de codi (Vermutech #14), ja que es comprova que el percentatge de cobertura no decau; això ens indica que no afegim codi sense tests, mantenint la qualitat del projecte.
A GISCE-TI, fem servir Github Actions per automatitzar aquests processos de CI. Els fluxos que tenim establerts s’executen en diferents punts del procés de desenvolupament:
Proves unitàries i de cobertura: Quan algú obre una pull request, s’activa un workflow de Github Actions que executa totes les proves unitàries i comprova la cobertura de codi. Així, ens assegurem que els nous canvis no introdueixen errors i que es manté un nivell alt de cobertura, tal com vam comentar a GISCE-TI en parlar de la importància del testing.
Revisió de codi i integració: A més de les proves, integrem una revisió de codi automàtica que verifica la qualitat i assegura que seguim els estàndards definits per al projecte.
Aquest flux ens permet treballar amb més confiança i facilita la col·laboració, ja que tothom té visibilitat de l’estat dels canvis abans que aquests s’integrin a la branca principal. Amb aquesta implementació, aconseguim un codi més robust i minimitzem els riscos de regressions, cosa que ens permet continuar evolucionant el projecte amb estabilitat i qualitat.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.