Agile@School – anno quinto, ep. 6

Siamo arrivati al sesto incontro con i ragazzi. La quarantena non ci lascia tregua ma noi siamo più tenaci e non molliamo di certo! Ormai l’incontro su Microsoft Teams è consolidato e sarà il fatto che è ora di colazione o che ci troviamo tutti “insieme” ma a casa, insomma, ci si sente quasi in famiglia.

Ma bando alle ciance, perché oggi tocca al branching su Git, pratica molto utile e consigliata nell’utilizzo quotidiano, ma allo stesso tempo complessa e insidiosa.

[…] il branching risulta essenziale per poter testare l’efficienza di implementazioni differenti o per realizzare dei proof-of-concept in corso d’opera.

Chi sviluppa conosce bene il tema, essendo vita di tutti i giorni. Tuttavia, in certi frangenti, è necessario chiedere aiuto alla documentazione o a chi può esserci di aiuto. Per questo motivo Pier-Paolo, con tanta pazienza, ha preferito mantenere un livello di applicazione piuttosto semplice, portando esempi pratici tratti dalla nostra esperienza lavorativa aziendale, per meglio dimostrare ai ragazzi la reale utilità di questo strumento.

Il branching, il nostro miglior alleato

I vantaggi del branching non si limitano al fatto di poter sviluppare funzionalità differenti in parallelo o da sviluppatori differenti. Infatti, risulta essenziale per poter testare l’efficienza di implementazioni differenti o per realizzare dei proof-of-concept in corso d’opera. Pier-Paolo ha inoltre evidenziato l’eventualità, in realtà fin troppo frequente, del verificarsi di conflitti nel codice al momento del merge dei vari branch su quello principale di sviluppo. E cosa ha deciso di far provare ai ragazzi?

The “git flow” branching model
gitflow, esempio di branching su git

Reazioni dei ragazzi ai primi conflitti

Il caso più semplice che abbiamo sottoposto ai ragazzi si verifica quando due o più sviluppatori modificano il medesimo file in punti differenti. Ma siamo arrivati al caso più critico, quello di un file modificato nello stesso punto. Abbiamo seguito insieme i passi necessari per risolvere i conflitti tramite SmartGit e la condivisione dello schermo (vedi smart learning).

La lezione è stata davvero impegnativa, ma i ragazzi sembrano aver seguito con attenzione e compreso bene, reagendo con prontezza grazie anche alle indicazioni degli strumenti ai quali sono abituati.

Durante la prossima lezione vedremo molto probabilmente qualche risultato tangibile in termini di prodotto. Di certo parleremo di documentazione funzionale destinata all’utente finale, aspetto spesso tralasciato in favore della realizzazione tecnica del software.

Continuate a seguirci, l’esperimento delle lezioni online sta procedendo a gonfie vele e ormai manca poco a vederne i risultati finali.

Stay Tuned!

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 02 – build

In a previous post, we’ve described the “from scratch” approach on the development side. When everything works well there, a push (or check-in) triggers the build engine. We must deal with two SQL Server instances (SSIS Servers hereafter), with an environment for each of them:

The build pipeline

The SSIS Servers keep Vertica‘s test and production mappings as well as test and production connection strings for the SQL Server databases. So we need the right variable mapping for all the scenarios, but this is not in the scope of the post, we will speak about it in the next posts. Anyways, here is how the build pipeline works:

Our build process

You may notice that the task “Copy vertica deploy scripts” is disabled. Well, to be honest, right now we’re waiting for the target integration environment.

Build process explained

In the beginning, the build server gets the source files from the repository and creates the target artifacts folder with a Powershell script. This will be the path from which we will push the artifacts to the release pipeline.

The build server generates the .ispac file for the SQL Server Integration Services packages using the dedicated task. The copy tasks will be executed:

As you can see, we’ve got a set of utilities and transformation tools, that will be executed in the release pipeline as well as the environment script. This one contains the SSISDB variables mapping and the SSIS Project configurations statements. Misc files, .sql files for environments and the .ispac file will be copied to the target artifacts folder.

The tasks above copy our template of the .nuspec file to generate the NuGet file (NuGet pack step). This is what we get using NuGet:

Then, we’re ready to publish the files to the release pipeline. We will see how the release pipeline works in the next posts.

Ehm… you miss Vertica

Yes, you’re right. But, it’ll be just a copy of .sql files to the artifacts folder. We will see how the release manager will execute them, so…

Stay tuned!

Agile@School – Anno quinto, ep. 5

Ed eccoci alla seconda lezione completamente online! L’impatto è stato molto meno forte; la volta scorsa abbiamo avuto un po’ di tensione causata dalla mancanza di esperienza, mentre stavolta la lezione è filata via senza intoppi (tolto qualche problema tecnico iniziale, prontamente risolto dal gentilissimo personale della scuola). È un buon segno. Nonostante tutto, è possibile (addirittura auspicabile?) una forma di educazione online, che nulla ha da invidiare alle classiche lezioni frontali, eccetto il rapporto umano, ovviamente.

Comunque, venendo ai temi della lezione, anche questa volta lo scopo è stato quello di “far parlare” i ragazzi: è piuttosto evidente che la maggior parte di loro non è abituata a interagire più del necessario (per carità, alla loro età…), però una delle cose che vorremmo gli restasse da questa esperienza è proprio quella di imparare i comportamenti tipici del team. In un ambiente lavorativo, dove la comunicazione e il lavoro di squadra sono centrali, infatti, possono fare la differenza.

Pier-Paolo ha iniziato la lezione riprendendo le fila di quella precedente e ha cercato di far comprendere meglio agli studenti la differenza fra un approccio waterfall (a cascata) e uno ad iterazioni, tipico invece dello sviluppo agile, che in questo periodo è addirittura indicato nei decreti ministeriali. Quello che si è notato è la tendenza da parte dei ragazzi di procedere in un modo un po’ “tutto o niente”, poco organizzato nel tempo, per quanto riguarda le implementazioni; in ambito lavorativo ciò non consente di portare un reale valore tangibile al cliente. Infatti, non gli viene fornita una versione coerente del lavorato e non gli si da visibilità dei progressi nel software fino a fine sviluppo. I ragazzi dovrebbero cominciare a lavorare più a “storie”, realizzando parti del loro software, magari piccole, ma funzionanti e “visibili” findai primi momenti (agile e iterazioni).

Le impressioni positive che già avevamo rilevato sono poi state confermate: la modalità totalmente online con cui si svolge la lezione è vincente. Anche questa volta il professore ha chiesto di mostrare l’avanzamento dei progetti ed è evidente che i ragazzi si stiano abituando al backlog e alla creazione e presa in carico dei task. Manca ancora il poter vedere i progetti funzionanti, ma siamo confidenti nelle prossime lezioni.

La lezione è terminata con una breve dimostrazione dell’integrazione fra le push su GitHub e Azure DevOps (impostate la volta precedente). La prossima settimana vedremo se tutto questo avrà portato i voluti risultati. Speriamo anche di poter iniziare a parlare di branching style, ma questo è un argomento ostico anche per i lavoratori, quindi non sarà semplice.

Bene, continuiamo così nonostante le difficoltà che ci stanno mettendo a dura prova. Alla prossima lezione!

Agile@School – Anno quinto, ep. 4

Vista l’emergenza in corso, è passato un po’ di tempo dall’ultimo aggiornamento e di cose ne sono successe: poco dopo l’ultima lezione, infatti, il Coronavirus ha iniziato a diffondersi e sono state prese contromisure sempre più restrittive per arginare il fenomeno. Si è arrivati infine al divieto per tutti i cittadini di uscire di casa, a meno di emergenze e necessità lavorative.

[…] un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Da parte nostra, si può dire che abbiamo avuto “fortuna”, sia perché la nostra attività quotidiana (la programmazione) può essere eseguita anche fuori dall’ufficio via telelavoro, sia perché avevamo già predisposto anche prima del virus gli strumenti per metterla in pratica, per cui siamo stati fra i primi ad adottare l’utilizzo dello smart working che ci permette di lavorare da casa. Engage IT Services nasce in telelavoro, da tre persone che non avevano soldi per un ufficio, e oggi, grazie alla filosofia descritta qui, possiamo dire “ragazzi, da lunedì si lavora da casa” senza nessun problema di sorta. Un problema a dire il vero c’è, il caffè insieme, quello ci manca davvero!

Ma cos’è successo nelle scuole? In quella seguita da noi, in particolare, il professore non si è voluto perdere d’animo e, dopo un paio di lezioni sospese per precauzione, ci ha chiesto disponibilità per tenere una delle nostre lezioni in modalità di meeting online con gli studenti: ovviamente abbiamo accettato con entusiasmo, sia perché ci sarebbe dispiaciuto lasciare indietro i ragazzi sugli argomenti che avevamo preparato, sia perché era un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Ed eccoci qui, tutti pronti da casa con Microsoft Teams configurato e avviato in attesa di essere invitati alla “riunione” della classe. SPOILER: la lezione è andata alla grande e ha guadagnato molto dal fatto di essersi svolta online invece che di persona, e nel seguito vedremo il perché.

Partiamo dallo svolgimento della lezione: cominciamo col dire che questa ha avuto un tono molto da “review”; è stato chiesto ai ragazzi, uno per gruppo, di illustrare ciò che avevano fatto in queste settimane (non crediate che se ne siano stati con le mani in mano, anzi) evidenziando principalmente quale fosse stata l’organizzazione del team negli sviluppi. Dopo ogni presentazione, abbiamo quindi riesaminato le board per capire se i nuovi PBI fossero stati inseriti correttamente e abbiamo fornito consigli su come migliorarne la stesura.

intro-view.png (728×310)

Particolare attenzione è stata posta ancora una volta sulla disciplina necessaria ad adottare una serie di processi. Sebbene in un ambiente scolastico essi possano risultare “pesanti”, a lungo termine non possono che incrementare consapevolezza ed efficienza nel modo di lavorare.

Tutto questo è avvenutotramite schermo condiviso e ciò ha permesso una partecipazione forse più diretta rispetto ad una lezione frontale in cui i ragazzi spesso non riescono a condividere quanto implementato o a interagire direttamente su quanto mostra il professore.
Nonostante molti ragazzi non disponessero di un computer e si fossero collegati con smartphone o tablet, l’impressione è stata che la lezione si trasformasse in qualcosa di più personale. Le distanze “fisiche”, già inevitabili in classe e in questo frangente anche più estese, si sono praticamente annullate. E questo ha portato molta più partecipazione.

[…] essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individuo.

La lezione è terminata con la richiesta di collegare i repository GitHub dei ragazzi alla nostra board Azure, per poter mostrare loro la prossima volta l’integrazione fra i due mondi: abbiamo quindi mostrato la procedura per la creazione dei Personal Access Token, toccando così anche l’argomento sicurezza nella gestione dei repository.

L’aspetto su cui Pier-Paolo insisterà nella prossima lezione è quello della creazione di valore aggiunto ad ogni iterazione: sembra infatti essere presente un po’ di “dispersione” negli sviluppi. Anche il professor Memoli ha richiesto, dal canto suo, che i ragazzi mostrassero qualcosa di funzionante e tangibile per evidenziare tale problematica.

Il primo esperimento si può quindi dire concluso con successo e non vediamo l’ora di proseguire con la prossima lezione per avere conferma delle nostre impressioni! Una cosa che vogliamo sottolineare è che in questo periodo di emergenza, non solo chi sfrutta i nostri servizi cambia. Cambiamo anche noi e questo non fa altro che incrementare la consapevolezza di come essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individio. Questi ragazzi ci hanno dato un insegnamento non piccolo. Si può fare!

Agile@School – Anno quinto, il progetto in remoto

Si sente spesso dire che la scuola non ha tutti gli strumenti per poter fronteggiare formazione in remoto. In generale, il mondo della formazione scolastica è considerato talvolta un po’ arretrato. In realtà, l’istituto che stiamo seguendo, sia con progetti paralleli, sia come alternanza scuola-lavoro è ed è sempre stata all’avanguardia. Forse sono un po’ di parte, visto che si tratta della scuola in cui ho studiato, ma credo che meriti una degna menzione.

Ancor prima che io potessi contattare i professori per tentare il progetto in remoto, ho ricevuto una telefonata dal professor Christian Memoli che, riassumendo, chiedeva: “abbiamo tutto per fare da remoto, abbiamo Teams, abbiamo strumenti di video conferenza, è un problema per la tua azienda? Noi stiamo già facendo didattica a distanza.”. Che cosa posso dire? Prima di tutto, che l’IISS Gadda di Fornovo Taro è pronto, veramente. Poi, nel mondo del lavoro di cui noi informatici siamo parte, non spesso il telelavoro è ben visto, mentre una scuola dimostra un sentimento responsabile e proattivo.

Attenzione, non fraintendetemi, per la nostra azienda, TUTTI e sottolineo TUTTI i clienti e i fornitori hanno condiviso, chiesto e supportato il lavoro da remoto. Però conosco casi in cui, seppure possibile come strada da percorrere, il telelavoro non è ancora ben visto. Per fortuna la nostra realtà aziendale non ha questo tipo di conflitto, anzi! Consapevolezza e responsabilità vanno per la maggiore, unitamente al rispetto per la salute di tutti.

A partire da mercoledì, seguiremo una serie di incontri (purtroppo ancora fino a data da destinarsi) utilizzando Microsoft Teams (strumento già utilizzato dalla scuola regolarmente), connettendosi in Azure DevOps Services e sfruttando GitHub come già indicato nei post precedenti della serie. Il tutto da remoto! Sento che questo progetto, già interessante, non farà altro che diventarlo ancora di più. Dimostreremo le possibilità dell’informatica, terremo comunque i ragazzi interessati e chiuderemo il progetto, senza farci fermare dallo spazio fisico.

Non vedo l’ora, stay tuned!

Agile@School – Anno quinto, ep. 3

Nella seconda lezione abbiamo deciso di iniziare ad affrontare l’integrazione fra Git e Azure DevOps, in particolare per quanto riguarda il collegamento automatico fra i commit/push e i Task. Questa volta, però, abbiamo incontrato non poche difficoltà. I ragazzi, infatti, hanno lavorato su GitHub fino ad oggi, per cui abbiamo ritenuto opportuno effettuare l’importazione dei loro repository sul nostro Azure DevOps, tramite l’apposita funzione integrata.

Agli studenti, comprensibilmente, non erano stati dati permessi sufficienti per effettuare l’importazione in autonomia, per cui un po’ di tempo è andato perso nel far immettere le loro credenziali, uno alla volta. Superato “facilmente” questo primo ostacolo, i repository sono risultati importati con successo e, dopo una prima revisione dei concetti base di source control e del funzionamento di Git, Pier-Paolo ha seguito i ragazzi nell’operazione di cloning con l’ausilio di SmartGit, a cui erano già da tempo abituati.

log-default-coloring-4f58b1c4.png (1596×792)

Si è partiti con i comandi base di Git (checkout, commit, push/pull) intervenendo direttamente sul codice già scritto dai ragazzi, su schermo condiviso, in modo da dimostrare loro le potenzialità dello strumento. Purtroppo, la condivisione su schermo è stata l’unica strada percorribile, anche in questo caso i permessi erano mancanti. Dobbiamo preparare gli ambienti un po’ meglio la prossima volta!

Altra cosa da notare questa volta è che, durante la lezione, abbiamo avuto modo di toccare, seppure superficialmente, questioni di metodologia di sviluppo. Ad esempio abbiamo affrontato le naming convention, modularità e pulizia del codice, leggibilità, e via discorrendo, tutti argomenti che usualmente non vengono trattati nei classici corso di programmazione.

A fronte di tutte queste problematiche introdotte dal tentativo di migrare i progetti su Azure DevOps, è parso evidente che i ragazzi trarranno più benefici continuando ad utilizzare i loro repository su GitHub. Pier-Paolo si è quindi prefissato di sfruttare la funzionalità “GitHub Connections” la prossima volta. La feature di Azure DevOps permette di collegare un repository GitHub ad un progetto interno, permettendo al tempo stesso di sfruttare il meccanismo di associazione fra commit e Task, come descritto qui.

Kanban board shows GitHub links

Stavolta la lezione è stata forse più importante per noi che per i ragazzi e in retrospettiva individuale abbiamo imparato una importante lezione:

L’utilizzo di strumenti già in essere (non ci stancheremo mai di ripeterlo) è fondamentale per non aggiungere ostacoli ad un già difficoltoso percorso di migrazione culturale. Da queste piccole cose, si denota come una consapevolezza dell’ambiente in cui si lavora e dei tool annessi, avvicini tutti al successo del progetto stesso. E questo vale sia nelle aziende, sia nelle scuole.

La prossima volta tocca al branching e a comandi Git più “avanzati”, come le pull request, e il livello di difficoltà aumenterà notevolmente… Vediamo come sapranno affrontarla!

Agile@School – Anno quinto, ep. 2

Eccoci arrivati alla seconda lezione, cominciamo finalmente a fare sul serio!

La volta scorsa avevamo chiesto ai ragazzi di provare a inserire le user story sulle board dei loro progetti. Ora, le board erano lande desolate… Forse la causa è da attribuire al concetto di user story, che può essere in qualche modo complesso e non facile da “digerire”. Oppure il motivo è da ricercare in una gita in Spagna di mezzo?

Nessun problema, è comprensibile che le user story non siano di immediata comprensione, soprattutto per questi ragazzi che sono chiamati ad essere clienti, PO e sviluppatori nello stesso tempo. Soprattutto un portale con così tante feature, non è semplice da navigare, per cui, armati di pazienza, Pier-Paolo ha ripreso i concetti daccapo e li ha approfonditi con esempi concreti.

Questa volta, invertendo di fatto il modus operandi della lezione precedente, ha provato a dare molta più importanza alla pratica, quindi, insieme ai docenti ha seguito i ragazzi nel data entry sulle board.

I gruppi avevano già compilato a inizio corso un elenco di attività da eseguire per sviluppare i loro software: chi salvato su un foglio Excel condiviso sul cloud, ben formattato (soprattutto i gruppi con ragazze, sempre precise), chi invece su un file di testo, copiato per ogni studente, aggiornato via email (questo invece sarà un buon punto di partenza per una delle prossime lezioni, ndr). I ragazzi sono comunque stati veloci ad apprendere e, dopo un primo approccio, hanno iniziato anche ad appassionarsi. Si è vista la crescente curiosità rivola a come si gestiscono gli item e a come dovrebbero essere compilati. Sta crescendo la loro parte proattiva, nulla di più bello da vedere in una classe.

Per terminare rilassandosi un po’, Pier-Paolo ha insegnato poi il poker!

Non quello vero, naturalmente, anche se uno dei progetti è un Casinò virtuale, ma il planning poker. E qui proprio il gruppo che sviluppa il Casinò (sarà un caso?) ha immediatamente trovato un sito per poterlo fare online collaborativamente, che è stato subito utilizzato anche dagli altri. Prima abbiamo visto la proattività dei ragazzi, ora siamo addirittura arrivati alla crescita di team. Si bruciano le tappe quando si capisce il valore di alcune nostre azioni!

La lezione è passata piuttosto in fretta, del resto quando ci si diverte accade spesso. Chiudiamo qui con un compito “facile facile” per la prossima volta, cioè inserire i task nei PBI. Chissà se saranno così bravi da buttare giù anche le stime? Vista la crescita, siamo ottimisti 😊

Stay tuned, la prossima volta tocca a Git!

Agile@School – Anno Quinto (2020)

Anche per l’anno 2020 siamo stati coinvolti per continuare il progetto Agile@School, svolto in collaborazione con la scuola I.I.S.S. Gadda di Fornovo. Questa continuità negli anni è sicuramente un buon segno, perché significa che negli scorsi anni il progetto ha dato i suoi frutti e che l’esperienza sul campo acquisita dagli studenti è stata utile.

Ma, per chi ci segue da poco, descriviamo innanzitutto in cosa consiste il progetto Agile@School.
Questo progetto è nato nel 2016 con l’intento di far conoscere agli studenti il cosiddetto modo di lavorare agile, che consiste nell’adozione di tutta una serie di comportamenti e discipline orientate alla collaborazione, al team working e alla condivisione e rielaborazione di informazioni, che stanno trovando sempre più larga diffusione nel campo dello sviluppo software (ma facilmente applicabili anche in altre professioni). La nostra impressione è che negli ambienti educativi si dia ancora troppa importanza all’insegnamento della programmazione pura (indipendentemente dal linguaggio scelto) a scapito di quanto sta “a contorno”, mentre saper programmare e basta è sempre meno sufficiente affinché gli studenti siano più preparati all’ingresso nel mondo del lavoro.

Edizione 2020

Quest’anno abbiamo delle novità: la prima, l’insegnante! A parte infatti la prima lezione che è stata quasi unicamente “conoscitiva”, di presentazione (sia da parte dei ragazzi, sia da parte nostra), in cui siamo stati presenti in due, le prossime lezioni saranno tenute principalmente da Pier-Paolo Mammi, uno dei nostri nuovi colleghi di lavoro, con il quale seguiremo il progetto direttamente “sul campo”.
Altra novità: mentre nelle edizioni passate gli studenti sono stati guidati dall’inizio alla formazione dei team e alla scelta dei progetti, nell’edizione attuale le squadre sono già formate e ognuna ha già portato avanti lo sviluppo software del progetto assegnato (li vedremo nel seguito). Avremo quindi l’occasione di concentrarci maggiormente sulla parte organizzativa del lavoro “a regime” e di mostrare loro le applicazioni dell’agile development, nonché l’utilizzo di strumenti informatici a supporto, che noi stessi utilizziamo nel nostro lavoro.

Il piano d’attacco

I punti principali sui quali insisteremo saranno principalmente tre:
– Team working: strumenti di collaborazione e condivisione, boards;
– Gestione del progetto in modalità agile: cerimonie, utilizzo di Azure DevOps e gestione degli sprint;
– Controllo del codice sorgente: utilizzo di Git e integrazione con Azure DevOps.

Terremo sicuramente delle spiegazioni più teoriche, ma l’ottica sarà quella di far applicare il più possibile i metodi direttamente ai team di studenti, perché è con la pratica (e la perseveranza) che si fissano meglio i concetti. Proveremo inoltre anche ad “aumentare la posta in gioco”, utilizzando in alcuni casi durante le lezioni una terminologia più aziendale che, se da una parte potrà essere poco gradita dai ragazzi, dall’altra li renderà più preparati all’ambiente professionale.

L’impatto

I ragazzi erano inzialmente un po’ timidi, come è lecito aspettarsi quando incontrano qualcuno di nuovo, ma pian piano si sono un po’ sciolti. Abbiamo poi chiesto ai team di presentare brevemente i loro progetti, descrivendone le funzionalità e indagando in particolar modo sulle funzionalità specifiche che prevedono di implementare, a chi è rivolto il software, con quali modalità sviluppano e come si passano codice e documentazione. Questo per avere un’idea di come hanno impostato il loro lavoro, per esempio se avessero già previsto della documentazione condivisa, piuttosto che un sistema di versioning. Diciamo che qui dovremo lavorare con impegno!

I progetti

La classe è stata suddivisa in quattro team, ciascuno composto da 4/5 studenti, di cui uno di questi durante le presentazioni è stato “eletto all’unanimità” come Leader. E qui va un doveroso ringraziamento al professor Christian Memoli, incaricato di seguire la classe, che si fa costante premura di insegnare ai ragazzi i concetti dell’agile development, al di là della pura e semplice programmazione!

Questi sono i progetti scelti dagli studenti, per i quali è già presente una buona base di codice:

Progetto Casinò
Il progetto consiste nella realizzazione di una serie di tipici giochi da Casinò (Black Jack, Roulette, etc.).

Progetto ClasseViva
Gli studenti realizzeranno una versione alternativa e migliorata dell’attuale sistema di gestione delle presenze in aula, integrandolo con notifiche e messaggistica fra professori e genitori.

Progetto CUP
I ragazzi vogliono realizzare un software per la gestione online completa delle prenotazioni delle visite sanitarie.

Progetto TEP
Il software gestirà la prenotazione, l’emissione e la gestione di biglietti per le linee TEP da parte dei cittadini, comprensivo di parte amministrativa per i dipendenti.

Prossimamente

La prima lezione introduttiva al mondo dell’agile si è poi conclusa con l’assegnazione dei compiti a casa ai team. Dopo aver impostato su AzureDevOps un ambiente TFS dedicato al progetto, comprensivo di repository Git per i quattro progetti, abbiamo chiesto ai ragazzi di caricare il loro codice sorgente sul proprio repository e di cominciare a inserire i Product Backlog Items, compilati con le user stories e le attività.
Da qui partiremo nella prossima lezione per espandere i concetti oggi solo accennati, relativi all’utilizzo di AzureDevOps per la gestione delle attività e di Git come sistema di versioning del codice sorgente.

Stay Tuned.

Display Reporting Services usage statistics with Grafana

Introduction

In this post, we will describe an efficient way of showing the usage statistics of our SQL Server Reporting Services hosted reports. Most of the queries below have been addressed in another article published by Steve Stedman. Even though they are really useful, the article shows their results through SQL Server Management Studio.

The problem

One of the problems that often occur in our organization as well as some of our customers, is to get immediate feedback about usage statistics of reports. Usually, the request of creating reports is out of control and some of them are executed only “that time” and not anymore. In the worst-case scenario, many of them aren’t executed at all and some of them could become even overlapped or duplicated.

Therefore, it is important to know the usage statistics, user by user and report by report, to make the reader aware of them, let him interpreting the values of the same query in multiple ways and graphical layouts. While this is not possible with a tabular format (unless you export the values using any external tools such as Excel) it is simpler when it comes to a dashboard.

Our solution: Grafana

We considered two factors: simplicity and efficiency, in order to make this first-sight dashboard. Grafana enables us to get both of them, as well as being very powerful and immediate. Even though this is not the right definition for it, we can say that “it is a portal to create dashboards using connectors, which support the most famous tools that return data”. We can find them in its marketplace. For instance, tools such as PRTG and Prometheus (monitoring), NewRelic (APM), also SQL and NoSQL data sources are supported:

Obviously, we can find SQL Server. Also, we can contribute to create others, as well as to modify Grafana itself, since it is completely an Open Source project. Examples of possible graphical representations are listed below:

Creating a dashboard is really simple. Just add each panel with a button.

Then, write the query and modify settings to get the desired type of representation.

As mentioned before, the connectors are many. Once selected you can to configure them with parameters:

If you would like to install and configure Grafana you can read the official documentation which also includes a short guide that illustrates how to take your first steps.

That’s it!

Conclusions

With half a day of work (including the setup of the server), we have solved one of the most important problems of our customers, derived from the lack of awareness of reports deployed in production environments. We did it with very little effort and the result, as you can see, is pleasant and effective. Everything is now ready to be published every time we update the dashboards also through a delivery software (Octopus Deploy, Jenkins or Azure DevOps) so all these things fall into the second and third way of DevOps (according to The Phoenix Project): Immediate Feedback and Continuous Improvement.

Stay Tuned!

Reducing the gap between operations and development using Azure DevOps

Intro

As we all know, DevOps is culture. In a company that is going to adopt its practices and principles, everyone should be “on the same side”. Continuous improvement cannot be part of our work in IT if we wouldn’t reduce the gap between development and operations. People like me, that worked in the 90s, know that dev and ops were always isolated in silos and this was “the only” way that everyone followed as a suggestion taken from the market leaders. Ticketing systems and extreme bureaucracy acted as a man-in-the-middle between those silos, transforming each organization in two people-unaware endpoints.

Speaking from a DevOps perspective, in such circumstances, a developer couldn’t know anything about how to deploy, where and how is an environment configured. On the other hand, an operation guy couldn’t get anything from a package in terms of what the application has been made for. Due to this gap we often see performance issues, underestimated hardware stuff and delayed releases. Last but not least, what about the lack of commitment and accountability of the employees working on the solution? In short, reducing such a gap is possible using a combination of DevOps culture and the right tools. We will see hereafter how my organization tries to do so using Azure DevOps.

Scenario

Let’s get started with our team (DevTeam hereafter), which is working with agile methodologies, composed of ten developers and a PO. A quick note, we are using a process decision framework called Disciplined Agile (https://www.disciplinedagileconsortium.org/). Then, we have three operation professionals (OpsTeam hereafter). Build and deploy pipelines already exist. Builds are hosted by Azure DevOps and deploys are managed by Octopus Deploy. Getting this has been a difficult mission.

Everything is related to infrastructure in terms of servers, operative systems, virtual hosts, DNS, firewalls, security and so on, is the responsibility of our OpsTeam. As a result, they do many tasks for managing the environments. Here comes the problem. DevTeams used to create tasks in a dedicated backlog, but OpsTeam didn’t. It’s not just a matter of end-of-pipeline tasks, but also tasks for their daily basis work.

Our solution

Modify the tool, adapting its shape in order to fit in with that real scenario. A piece of cake, when you’re DevOps “inside”. How did we change Azure DevOps? Let’s describe what we did in three parts:

Team on Azure DevOps

To create a team in Azure DevOps is really a piece of cake (according to the latest releases). Just navigate to the options and select Teams:

We can add many teams clicking on New team:

We can set the team’s administrators, the permission set and an area under which every work item will be created. This area will be one of our best friends, especially when we will make our queries for gathering and analyzing the team’s related data. Additionally, also the other teams’ members could create items with this area in order to make the OpsTeam aware of them.

Team’s backlog

Now let’s navigate to Backlogs:

Good! The new backlog has been created. Going on it, we will see the team’s drop-down as well as the one for iterations. Great features!

Once created, we will see the teams’ drop-down:

Work items

Now, let’s create a new work item type. We call it Ops item. Navigate to Process customization page:

Before adding the new work item, we must ensure that the process is already a custom process, otherwise, all the edits will be blocked as shown in the following picture:

We’ve already created a SimplifiedScrum process. let’s add our item now:

Now we are going to modify the fields of the new type. Each team should be able to understand all the item’s properties. We will leave the item as is in this example. Then, we have to map the type to the backlog item list, since only the default work item types are shown initially. To do this, navigate to the Process customization page, Backlog Levels tab:

As we can see, we can also set the default item for our requirements backlog. Moreover, every Sprint backlog, based on iterations, will enable us to add the new Ops item:

Wrapping up

So, we’ve got a backlog for the IT Operations team’s members. Then, we’ve related it to their Azure DevOps team. Additionally, we’ve got a particular work item type (not mandatory, but really useful for querying it or adding it into dashboards) target of IT Operations’ job and a dedicated Area Path. We can make many relationships between items of both our backlogs. Here is an example of how an activity can be managed and organized (extension: Work Item Visualize):

As you can see, the Ops items are Successor of the “development” Product backlog items. Indeed, the Ops Items will be finished after the PBI, typically. Think about creating s DNS or a network path to let the production app work in production.

Conclusions

With this solution, we’re decoupling backlogs. Moreover, we’re isolating the management maintaining the relationships between work items that reside on different boards. At the same time, we’re making a strong synergy between Development and Operations.Then, in a couple of clicks, we can switch teams and backlogs, using Azure DevOps Boards. We can track changes in both the departments, also for audit requirements. In my opinion, this helps the enterprise awareness and facilitates the continuous improvement of all the teams and any member’s skill.