Home > LinkedIn, Release Engineering, software engineering > Questioni di releng…

Questioni di releng…

Salve a tutti.

Il mio lavoro quotidiano, sviluppo del software parte, comprende anche tutte le fasi che vanno dalla creazione di versioni fino alla delivery/deployment diretta al cliente.

Queste “tappe”, costituiscono parte del cosiddetto “build and release cycle” che a sua volta appartiene alla (sotto)disciplina nota come “release engineering“.

Da Wikipedia:

“Release engineering, frequently abbreviated as “releng“, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. An associated term is software release life cycle.”

Di fatto qualunque sviluppatore che produca o abbia comunque a che fare con software da compilare, controllare e distribuire di fatto svolge funzioni anche di build/release engineer.

Nel caso di aziende di dimensioni medio/ragguardevoli spesso i release engineer sono figure specializzate in quell’ambito e lo svolgono come loro mansione unica e principale (e mi riferirò a loro nel prosieguo, estendendo un poco il discorso e includendo anche i “build-engineer”).

In ogni caso lo scopo ultimo di questa sottodisciplina è provare a portare “consistency, reproducibility, and verifiability to the build and release cycle” ossia applicare scrupolosamente metodologie che garantiscano un determinato grado di certezza per il software che verrà poi distribuito.

La releng ha quindi a che fare con la software quality assurance (SQA): chi se ne occupa in modo dedicato non ha la responsabilità di testare/debuggare il codice ma piuttosto provare a compilarlo per trovare imperfezioni o difetti tali da poter bloccare o ritardare la distribuzione del software.

Scusate se è poco.

Compilare… e basta?

Quello che però passa in secondo piano è il rapporto della releng con l’automazione: le attività di compilazione sono un qualcosa di estremamente ripetitivo ma, come già detto, sono indispensabili e possono fornire informazioni molto importanti sulla solidità del codice.

Per questo un release engineer non si limita a compilare il codice ma sviluppa procedure automatizzate (cfr. build automation) per scovare i problemi e poterli segnalare tramite opportuni report a chi di dovere.

Per dirla alla Wikipedia:

“Producing or improving automation in software production is usually a goal of the release engineer.”

Le cosiddette nightly build sono un esempio tipico di questo genere di automazione: si tratta di software generato/ricompilato automaticamente quando gli uffici sono chiusi per essere disponibili il giorno successivo, alla riapertura degli uffici. Apposite procedure automatizzate, raccolto tutto il codice (sottoposto a revision control e contenuto quindi in appositi “repository”), provano a compilarlo e preparano dei report dettagliati dei difetti riscontrati (cfr., ad esempio, questo post su Microsoft).

Le offerte di lavoro in campo releng non mancano. Vedere ad esempio questa offerta di lavoro presso Mozilla. Mi permetto di evidenziare quel “Automate, Automate, Automate” nonchè il “Double Bonus” per chi conosce strumenti come BuildBot e Tinderbox.

Insomma non si tratta solamente di qualcuno che compila per conto terzi (in questo caso altri sviluppatori), ma piuttosto di qualcuno che crea gli strumenti adatti a farlo e, contestualmente, produrre un sempre maggior numero di informazioni utili agli sviluppatori.

Libri?

Spinto da curiosità nonchè da una sana volontà di automiglioramento, ho prima scandagliato la Rete per cercare documentazione su quel topic ma alla fine non ho trovato granchè: tolti gli innumerevoli libri di software engineering che trattano anche di releng, i libri orientati principalmente su quel tema si contano sulle dita di una mano.

Ho avuto conferma di questa mia impressione leggendo le risposte alla mia domanda “Release engineering: what books?” su Stackoverflow: se non altro ho avuto qualche indicazione per qualche libro, che spero di riuscire a leggere (e, se meritano, anche recensire).

Avete suggerimenti?

Ciau! ^^

  1. 29 Aprile 2009 alle 14:30 | #1

    Posso consigliare “Ship It!”, se non altro perché è l’unico che ho letto … :)

    In ogni caso credo che la formazione base di ogni programmatore che si rispetti lo metta in grado di fare anche da ‘build/release engineer’ con risultati più che dignitosi. Poi si tratta sempre di avere un pò di metodo, buon senso ed esperienza.

    Non ho mai lavorato in organizzazioni gigantesche ma, nei progetti che ho gestito, il build engineer era sempre uno dei programmatori che sfruttava parte del suo tempo in questa attività. Inoltre il testing, automatizzato e non, spesso andava a seguire direttamente la generazione della release: nei casi che ho seguito si è sempre trattato di build+test+release.

  2. jp
    29 Aprile 2009 alle 16:52 | #2

    Come ho detto, qualunque programmatore quando pigia il pulsante “compile” è un <build-engineer. Se poi prepara e distribuisce versioni fa anche da release-engineer.

    Diciamo il mio post aveva il duplice scopo di parlare della figura professionale (ossia chi lo è/lo fa come mansione principale) e quello di recuperare materiale utile su quel campo. :)

    Direi che ho raggiunto entrambi gli scopi: grazie per il consiglio sul libro! :D

    Ciau! ^^

  1. 21 Ottobre 2009 alle 12:01 | #1