Don’t dirty my Backlog: flow/no-flow

Si è cominciato a parlare (si veda qui) dell’importanza di preservare la consistenza del proprio Product Backlog, facendo si che esso rispecchi le effettive esigenze di prodotto onde evitare che diventi un “accumulo” di decine e decine di richieste che poi si perdono al suo interno.

Il Basket, proposto come contenitore di “draft item”, è al centro di una precisa strategia:

  • Vengono raccolte le informazioni da ogni fonte disponibile e meritevole di attenzione
  • Viene eseguito il refinement delle informazioni per ottenere degli Item consistenti
  • Vengono spostati gli item nel Product Backlog

3phases

 

La raccolta delle informazionida parte dei diversi stakeholder è un’attività continua che trova nel Product Owner il riferimento operativo e che si può realizzare sfruttando gli strumenti più disparati: dalla comunicazione diretta a soluzioni di change request management

La cosa fondamentale è la capacità di aggregarele richieste guardando oltre la specifica singolarità, in modo da creare featureche portino ad un mutuo beneficio tra le parti, sottoponendole continuamente ad un refinement che consenta di ottenere item lavorabiliche non siano dei banali placeholder. 

Qui nasce la necessità di definire con chiarezza che cosa significhi “item lavorabili”, per il contesto specifico, per l’iniziativa e per il team, stabilendo una specifica Definiton of Ready(DoR) per abilitare il flow/no-flowfunnel che porta un Basket Item ad essere promosso a Product Backlog Item.

flow noflow

Come sempre bisogna fare molta attenzione alla DoR: una sua specifica troppo estremapuò portare ad allungare in modo irragionevole i tempi, perdendo di vista l’importanza applicativa del Cono di Incertezzae provando a rendere “perfetto” qualcosa che “by definition” non può esserlo nei sistemi complessi. Dualmente, una DoR troppo superficialeporta ad avere item che sono tutt’altro che pronti ad entrare nel Product Backlog e che porterebbero solo ad “aumentarne il peso” senza dare un contributo apprezzabile al valore complessivo.

Quando un Basket Item soddisfa la DoR e viene promossoin un Product Backlog Item, entra di diritto nella “lista delle cose da fare”, anche se questo, come è ben noto, non da certezza che verrà realizzato, ma solo che è “meritevole” dell’attenzione dell’intero team. 

Guai a pensarla diversamente: si ricadrebbe nel “tranello” di effettuare una elicitazione completa dei requisiti, perdendo la capacità di operare dinamicamente rispetto ai cambiamenti e di adattarsi alle evidenze piuttosto che seguire un piano.

Stay tuned J

Don’t dirty my Backlog!

Che il Product Backlog sia uno degli elementi cardini per il lavoro dei team Agile è una verità sperimentata da tutti i team che hanno intrapreso un percorso di “Agilità” scegliendo di partire da un riferimento simil-Scrum. Accettando la verità assodata che i “requisiti sono imperfetti by design”, il Product Backlog risponde alla necessità di avere uno strumento più flessibile del tradizionale SRS (System Requirements Specification, o comunque lo chiamate) per gestirli.

Se a prima vista la gestione di un elenco di attività (Storie se preferite J) non sembra un lavoro particolarmente complicato ed oneroso, entrando nel vivo della questione viene fuori, invece, che un Backlog “pulito e parlante” è tutt’altro che facile da creare, manutenere ed evolvere.

Non di rado ci si imbatte in Backlog costituiti esclusivamente da dei “placeholder”, come ad esempio: “fare la login”, senza alcuna altra informazione di dettaglio, a partire dai tanto bistrattati Criteri di Accettazione. Proprio questa situazione da il là ad uno degli aspetti primari che possono vanificare il senso stesso del Backlog: avere al suo interno decine e decine di elementi, inseriti preventivamente stile “waterfall”, che rendono praticamente incomprensibile il Valore che dovrebbe essere espresso dal loro insieme.

salad

In pratica, si prende la cattiva abitudine di buttare ogni richiesta, ogni specifica se si vuole, che arriva, direttamente nel Backlog, assegnandogli ogni volta la priorità più alta senza minimamente preoccuparsi di effettuare un opportuno refinementdell’elemento ne tantomeno degli impatti che avrà sul Valore per il cliente e sulle attività in essere.

Un possibile approccio per limitare tale mescolamentoè quello di creare un Basket in cui raccogliere le richieste provenienti dai diversi stakeholder, e, solo successivamente, procedere alla creazione di un elemento da inserire nel Product Backlog che rappresenti l’item lavorato o, eventualmente, la sintesi delle diverse richieste che incidono su un elemento o un’area specifica.

basket

L’idea è quella di creare un’area flessibile in cui raccogliere tutte le informazioni necessarie a soddisfare una Definition of Readyminimale che evidenzia il livello minimo di dettaglio previsto per poter promuovere effettivamente un’attività da Basket Item Product Backlog Item.

Per quanto possa sembrare inizialmente un’attività che va ad “affaticare” le incombenze tipiche del Product Owner, inserendo di fatto un pre-step nella creazione del Product Backlog, una volta assorbita e adattata al contesto, diventa decisamente funzionale e centrale per avere un cosiddetto Healthy Product Backlog.

Si evita, infatti, di trasformare il Backlog in un “repository” di richieste, allungandolo oltre ogni ragionevole dimensione, solo perché non si sa dove mettere le cose. Inoltre, introducendo il concetto di Aging, ovvero di invecchiamento di una attività, si può evitare di avere Zombie Itemche restano nel Backlog anche per molte iterazioni senza alla fine riuscire mai a trovare spazio di realizzazione concreta.

Torneremo presto a parlare del Basket con alcune idee per gestire la prioritizzazione degli elementi e la personalizzazione di tool per poterne creare una versione digitale.

Stay tuned J

L’inconfutabile momento del “come”

Durante l’evento DevOps Heroes 2018, abbiamo avuto modo di riflettere su DevOpse di come esso sia un volano per la competitività aziendale, partendo dall’assunto che:

            “ogni azienda è un’azienda software, indipendentemente dal settore diapplicazione”

Molti gli spunti di riflessione, tecnici/tecnologici e metodologici.
In particolare voglio sottolineare una pillola emersa durante la round table “Il grande fallimento di DevOps” (titolo chiaramente provocatorio), riguardo al cosiddetto DevOps Engineer

Personalmente sono stato sempre estremamente contrario ad utilizzare questo titolo, o altri similari, all’interno di un’organizzazione che si incammina nel percorso di trasformazione DevOps. Ho ascoltato con attenzione, però, il parere di Scott Ambler(opsite dell’evento) che ha suggerito un approccio più morbido rispetto a questo tema: secondo Ambler, può aver senso avere questo ruolo all’interno dell’organizzazione, purché sia un ruolo temporaneo, ovvero una sorta di “specialist” che supporta i team (e gli operations in particolare, visto che viene generalmente associato a loro) nell’apprendimento delle pratiche di automazione della pipeline di rilascio.

today devops engineer

Si tratta, in sintesi di un Coach tecnicoche, come tale, ha primariamente lo scopo di supportare la crescita tecnicae consentire rapidamente al team di muoversi in autonomia.

In pratica, è il ruolo del Coach ad evolvere ulteriormente, arricchendosi di nuove capacità specialistiche, e, probabilmente, evidenziando ulteriormente come l’idea che sia sufficiente un solo Coach per una trasformazione DevOps sia fortemente limitativa, perché difficilmente è possibile abbracciare i vari aspetti ormai richiesti.

Esiste a questo punto anche un ulteriore aspetto rilevante: la maggiore centralità chel’HR(o People Management) continua ad acquisire. Se dobbiamo portare a bordo nuove persone, l’HR dispone degli strumenti necessari per individuare e scegliere i nuovi profili? Ha la capacità di guardare avanti, settando nuovi percorsi di crescita per le Persone che lavorano nella propria organizzazione? È in grado di comunicare adeguatamente i Valori dell’organizzazione in modo da renderla attrattiva agli occhi dei potenziali candidati?

agile hr

Tutti aspetti che oggi sono sotto la lente di ingrandimento, tanto che nei vari percorsi di trasformazione l’HR è sempre più presente e costantemente ingaggiato. E altre aree organizzative sono alle porte: sales, marketing, PMO, architecture, ecc.

Segno definitivo che non è più tempo di chiedersi “se”avviare una trasformazione Agile (o DevOps se volete), ma l’unica domanda che conta è“come” iniziare il percorso di rinnovamento

 

Stay tuned J

DevOpsHeroes 2018 – Another brick in the wall

Event details

DevOpsHeroes has been a great event, again! We didn’t expect so many people and we could not imagine that the feedback would be so good. Quick facts:

  • Subscription: 244 (150 the past year)
  • Attendees: 122 (94 the past year)
  • drop: 50% (38% the past year)

Attendee’s satisfaction

The following radar chart is about the event date, location, quality of the sessions, quality of the speakers, food, hospitality, event design, and kits:

As we can see, the overall satisfaction is really high (4/5)! The blue line is related to the audience which already has attended our event (40%) and the orange one represents the first-timers (60%).

Indeed, we’ve got a good feedback also for the following questions:

  • will you attend again?
    • Sure, 45%
    • Most likely, 33%
    • Likely, 22%
  • will you suggest the event to other people?
    • Sure, 76%
    • Most likely, 21%
    • Likely, 3%

Conclusions

We’re really proud of the third edition of DevOpsHeroes. Engage IT Services and Xebir did a great job together, and, hopefully, both companies will cooperate in the future in order to provide new formats and events like this one. A special thanks goes to Scott Ambler, and also to Italian Agile Moviment for sponsoring and supporting the organisation.

Download sessions here.

Last but not least, thanks to GetLatestVersion.it and also WindowServer.it which allowed us to get DevOpsHeroes in the best shape possible.

See you next year!

La build YAML

Tra le varie novità di VSTS / Azure Dev Ops, sicuramente la build YAML merita un posto particolare. Sicuramente questa modalità di definire la build diventerà nel futuro la preferita, infatti nell’ultimo update è stata introdotta una nuova funzionalità che permette di creare una build YAML con un semplice wizard e che tra l’altro fa si che la build YAML venga consigliata di default.

image

Il vantaggio principale a mio avviso della definzione dell’integrazione continua nel codice si ha con Git, dove la build segue la branch e quindi viene versionata assieme ai sorgenti. In ottica Dev Ops il concetto di build è fondamentale, perchè il suo scopo è rendere ripetibile la generazione dei pacchetti di installazione, fornire le metriche, validare la qualità delle pull request e quant’altro.

La definizione della build nel codice aiuta a rendere autoconsistente il progetto, spostando il repository tra Azure Dev Ops e GitHub o tra vari account, si ha il vantaggio di avere sempre l’integrazione continua configurata con il codice stesso

Il classico scenario è quello in cui dovete modificare la build per eseguire un nuovo script PowerShell, oppure eseguire la build di una solution nuova. Con il motore standard avete un’unica definizione per tutte le branch, per cui dovete giocare di esecuzione condizionale, facendo si che alcuni task vengano eseguiti solamente se è presente un file su disco etc. Con la build YAML questo problema non esiste più, se in una branch avete una nuova solution, basta modificare il file della build ed il task per compilare la nuova solution sarà presente solamente in quella specifica branch.

Avere la build versionata per branch rende molto semplice evolvere la continuous integration assieme al vostro codice

Il secondo vantaggio è quello di poter avere un reale ambiente di test per le modifiche delle build. Con lo scenario tradizionale potete salvare la build come draft, testarla, e poi promuoverla, ma con una buidl YAML potete avere quante branch volete per tutte le modifiche che volete fare alle build. In pratica è come avere infinite Draft.

Un altro vantaggio è avere la storia completa di come è evoluta la build nel source control, poter effettuare un facile diff per capire cosa è cambiato e poter ripristinare velocemente una vecchia versione o fare un merge tra versioni. Il poter fare un rollback sulla history della definizione è una funzionalità decisamente comoda.

Dato che la build è un file, è chiaramente facilissimo creare copie della build con lievi modifiche, ed è veramente facile spostare la definizione di buidl da un progetto ad un altro (la maggior parte delle volte quando iniziate un progetto avete una serie di task standard, a questo punto basta copiare il file di build da una build preesistente ed il gioco è fatto)

Insomma, se dovete creare una nuova pipeline di build in Azure Dev Ops, vi suggerisco di inizare a guardare la build YAML, perché sicuramente si rivelerà una scelta vantaggiosa.

Gian MAria.

Comments Off on La build YAML  

La difficile equazione dell’introspezione adattiva

Quando penso e parlo di DevOps, il mio focus è sempre rivolto al valore nobile della Continuous Delivery: produrre costantemente (e non velocemente!) valore per gli stakeholder, interni o esterni che siano.

Si tratta di temi fondamentali, in funzione della verità assodata che oggi ogni azienda è una software house, ovvero che nessuna organizzazione può fare a meno di un nucleo IT che sviluppa soluzioni abilitanti per il business.

Durante i vari workshop e le azioni di coaching, prima o poi, salta sempre fuori una domanda: “Ma queste cose a loro [ai Manager] verranno dette?” “Faranno anche loro [i Manager] lo stesso corso?

Sembra quasi che i Dev e gli Ops farebbero tutto (poi “tutto” bisogna capire cosa sia) domattina, ma il loro freno sono sempre i responsabili che non vogliono ragionare e investire sulla trasformazione Culturale che io dico, affermo e riaffermo, essere indispensabile. Se non lo si fa, si condanna l’azienda ad una sopravvivenza forzata e non la si mette nella condizione di innovare e guardare ai nuovi traguardi

Poi, però, quando cominciamo a soffermarci sul ruolo che Dev e Ops devono avere in tutto ciò, le facce cambiano espressione: 

Non dovete più ritenervi coder, ma professionisti in grado di usare tecniche e tecnologie innovative per innovare il Business”.

Molte volte si stenta a capire l’importanza di questa frase, perché significa, in soldoni, assumersi responsabilità guardare oltre il proprio monitor.

Eppure, la realtà è così! 

Non esiste il “DevOps Engineer” (si tratta di un Sistemista che sa usare i tool di automazione per il deploy… chiamiamo le cose con il loro nome per favore), ma esiste una organizzazione che abbraccia DevOps (Lean, Agile, quello che preferite) avendo come obiettivo l’Enterprise Agility, ovvero essere in grado di rispondere prontamente al mercato, guardando al proprio interno, ma al contempo contribuendo a formarlo.

Non si tratta più di trovare il programmatore più bravo nello scrivere codice, si tratta di trovare il professionista che sa dove mettere le mani, ma che è in grado di supportare un cambiamento continuo in relazione alle nuove sfide che si presentano.

nerd vs thinker

Bisogna tornare a PENSARE!

I manager non sono persone generalmente “ottuse” e capiscono bene il valore dei diversi elementi di cui discutiamo, solo che anche loro sono trascinati nell’operatività giornaliera e spesso hanno difficoltà a fare quello che dovrebbe essere il loro obiettivo primario: mettere in atto quanto necessario per le prossime sfide, non quelle attuali, perché se siamo in quest’ultimo caso… è già tardi!

In pratica dobbiamo allontanarci dall’idea di essere “macchine banali” e riappropriarci del nostro essere “macchine non banali”, ovvero un giacimento di risorse inesauribili.

Ricordate sempre: il vero valore è nelle Persone e non nel codice scritto!

Stay tuned J

La rilevanza del Piano B

Si è appena chiusa l’edizione 2018 del Coach Camp Italy

Due giornate condite da spunti, riflessioni e discussioni legate alla tematica del Coaching Agile, nel panorama magnifico di Garda e del suo lago. Una grande agorà in cui è stato possibile confrontarsi con gli esperti italiani e non solo (forte la presenza degli omologhi tedeschi).

In particolare, durante la sessione “Resident Coach, Consultant Coach… DOs and DON’Ts”, si è discusso delle azioni che ci si aspetta da un Coach, soffermandosi in modo specifico sulla domanda: “ma un Coach esterno è un Consulente nella tradizionale accezione dell’esperto che deve fornire risposte?”

acci 2018 1

La questione può sembrare solo “filosofica”, eppure ha generato un’ampia riflessione, sintetizzata dall’ottimo Alessandro Giardinache ha evidenziato come, alla fine, i partecipanti abbiano concordato sul fatto che le azioni di un Coach non dovrebbero dipendere dal suo status di dipendente/consulente. Questo perché le attività sono sostanzialmente le stesse: dalla capacità di guida, a quella di supporto e sprono alla trasformazione. Il bandolo della matassa si è sciolto quando è emerso come il problema, in realtà, sia nell’idea che l’agile Coach è un “consulente esperto di Agile” e non un Coach in senso lato che, per definizione, è qualcuno che aiuta gli altri negli specifici ambiti sfruttando le proprie attitudini e conoscenze.

La discussione si è poi estesa, virtualmente, nel pomeriggio con il panel “Be a Coach” in cui ci si è soffermati sulle pressioni che un Coach “interno” può subire quando è rigidamente inquadrato nell’organigramma, cosa che potrebbe pregiudicarne la libertà d’azione in funzione delle dinamiche di management e di “capi” poco inclini agli aspetti tanto cari al mondo Agile (self-organizing team, continuous improvement, fail fast/fail often, ecc).

acci 2018 2

Quanto emerso è che il Coach deve essere capace di creare una forte Empatia con il contesto interessato, e conquistare la necessaria Fiducia per avere un ruolo di leadership nel percorso di trasformazione e rinnovamento.

Molto interessante l’idea del “Plan B”: avere un piano di riserva se non si è messi nelle condizioni di operare in modo indipendente nel proprio ambito professionale. Bisogna sempre essere alla ricerca del proprio State of Flow.

 

Chiudo ringraziando gli organizzatori del Coach Camp Italy 2018 e tutti i professionisti che hanno reso le giornate fruttifere e di indubbio valore.

Stay tuned J

Posting SQL Server notifications to Slack

Introduction

Automation, proactive monitoring, repeatability, reducing waste of time and technical debt. This is something you should know about when trying to do some DevOps.

Why automation? Because you can reduce technical debt and the number of failures that can happen with a manual interaction. You can create environments using a provisioning procedure without falling in common pitfalls like security misconfigurations, wrong configurations and botched monitoring.

Talking about SQL Server, immediate and proactive notifications represent a great step forward toward automation.

We automate whenever we want to stop doing a bunch of recurring or tedious steps manually. At the same time, we are also improving the overall quality and we are reducing the amount of things that can (and will) go wrong.

We are also optimising on how we use our time, because we can just ignore what the automation is doing for us and focus on that something that really needs our attention.

Finally, in this modern and notification-based world, emails generate too much white noise to deal with. In this article, we will learn how to integrate SQL Server tasks’ notifications with one of the most used collaboration tools: Slack.

Keep in mind that this is not the only way to get this done. This guide would help you to better understand why we’re doing this (eventually why DevOps), and not strictly how to do it, even if we’ll see a real working example.

Minimal requirements

You need to setup an account on slack.com (on a paid plan) and a SQL Server edition. I recommend the free developer edition here.

Note: Don’t use SQL Server Express edition. This version doesn’t support any SQL Server Agent task as well as the Database Mail, which we’ll need hereafter. Also, about slack, you must create a paid account, because the integration described below will not work with a free profile.

In order to send emails, we will use an SMTP sever. It can be either a private Microsoft Exchange, PostFix, or any other on-premises solutions, together with a cloud delivery service, like SendGrid, SendInBlue, MailJet, or Office 365.

The scenario

In a team like mine, which uses chat as a daily communication driver, centralizing every business and technical message could be a great step forward for the members of the team in terms of awareness and knowledge sharing. Business roles can use that tool as well, so we can chat to each other switching topics between tech and functional discussions. It’s just a matter of how Slack (in our case) is configured with channels and naming conventions. A good setup helps us to better organize our meetings, small talks and any other topic related to implementations. This is a cool argument to speak about, but a little bit out of the scope of this guide. We will focus on notification bots instead.

SQL Server is able to send emails with its built-in features out-of-the-box, but we’d like to centralize every notification inside Slack, gaining the following advantages:

  • Instant notification
  • Tailored focus (custom sound instead the same popup for all the incoming emails)
  • Opt-out
  • Quickly involve people that are not following the channel by a mention
  • Relay the problem description within the chat
  • Take actions as soon as the notification is received

The proposed solution

Now, how can we send notifications from SQL Server in an easier way than using custom code or a Slack incoming webhook? Is there any integration or a Slack app?  Yes. And guess what? I think you’ll like it because you don’t need to write a single line of code, and you don’t need to choose between CLR, PowerShell or any other language. It’s ironic, but the integration is called “Email”.

Slack

The purpose of this article is just to describe Slack as a collaboration tool. Further details are provided here. As we said before, the following samples work only if you get a Slack account.

The Slack Email integration

This is the app to work with: Email. Its configuration is based on a four-step wizard:

  • Select the channel (or create a new one).

001.png

  • When added, set the name and a short description of the new contact (bot) in Slack.

002.png

  • Change the avatar (it’s important to recognize the bot at a glance)

003

  • After saving, copy the email address the app created for you.

004

A word about the “Hide this address” checkbox: this is useful if you want to hide the address to any other member of your workspace. You will be the only user able to read it if you check that box.

Type of SQL Server notifications and setup

As a DBA, we’re managing the following types of notifications on a daily basis:

  • SQL Server built-in and custom Alerts
  • Job execution status
  • Integration Services custom emails (within the packages)
  • External monitoring tools (which monitor SQL Instances)

With the exception of SSIS custom emails and external monitoring tools, everything is managed by Database Mail. This is a lightweight layer that allows us to send emails directly from a SQL Server Instance, connecting to a SMTP server.

To setup Database Mail you can follow this guide from Microsoft Documentation.

Once this is up and running, you can manage the notifications using SQL Server Operators. An operator is an alias managed by the SQL Server Agent which you can use to send emails and other types of messages, like pagers and Net Send.

Creating an operator is simple, just invoke the following system stored procedure:

USE msdb; 
GO 

EXEC dbo.sp_add_operator 
    @name = N'<name here>',
    @enabled = 1,
    @email_address = N'<email here>';
GO

If you’re asking what email address you should use, it’s easy to say. You must fill the @email_address parameter with the address returned by the Email app integration for the channel you will send to (j8e4b5t2p4y8g4o2@elysteam.slack.com in the example above). But, what about the name parameter? In my opinion, the best name is the one that helps us to understand where the message will be sent to. Suppose that we’d like to notify something about some index maintenance jobs. We could call the operator Slack Indexes Maintenance, Slack Indexes Maintenance Operator and so on. With such names, you will immediately know what we are going to send to Slack as the topic is related to index maintenance.

Thus, you’ll get the following snippet:

USE msdb; 
GO 

EXEC dbo.sp_add_operator 
    @name = N' Slack Indexes Maintenance Operator',
    @enabled = 1,
    @email_address = N'j8e4b5t2p4y8g4o2@elysteam.slack.com';
GO

 

Slack channels naming considerations

I’d like to share with you my thought about the channel naming conventions. The principles to follow when naming channels, are:

  • Readability (clear for everyone)
  • Awareness (know what)
  • Style and Rules (know how)
  • Repeatability (keep using it from now on)

That being said, if the channel name describes a single action (like indexes maintenance in the above example) the operator which will send notifications should be unique. The reason is simple enough: we know that Indexes Maintenance Operator is sending messages to #sql-idx-maint-alerts (readability) and everyone knows that this is a one-to-one communication between a SQL Server Operator and Slack (awareness). Everyone knows that the “sql” channel prefix indicates SQL Server-related notification and the “alerts” suffix indicates that is an issue to pay attention to (style and rules). At the same time, everyone knows how to do the same with another pipeline of messages in the future (repeatability).

On the other hand, using a general purposes channel, like #sql-maint-alerts, allows us to be ready to future changes. Suppose that index maintenance will not be the only operation we’re executing in our servers (and typically isn’t). Does it make sense to create a new operator called for example, Database Concurrency Check Operator, which sends to a specific purpose channel? Clearly not.

In the end, a generic purpose channel gives the opportunity to hold more than one topic. All the notification sent to that channel should be, let’s say, of the same category to avoid too much generalization.

These solutions (one channel for more operators or a one-to-one solution) work equally well, it’s just a matter of how you’re designing your Slack channels. I suggest to avoid the “one channel to rule them all” pattern, because you’ll get thousands of mixed notifications without any clear idea behind them. After all, a noisy channel with messy content is something that will not be considered for a long time and will be eventually dropped.

Binding alerts

Alerts are triggers that communicate to an operator that something went wrong. This Brent Ozar’s article offers a good list of alerts that need attention. Here you can find their descriptions, based on severity. The binding is straightforward. All you need to do is to link the operator to the alert:

005006

When one of those events occur, an operator is alerted. Then, it sends the message using its setup – in our scenario, an email. If the operator uses the Slack Email app, the email will be sent to the Email app, and the integration will redirect it to Slack.

 

Binding job execution statuses

Let’s see how we can use the notification mechanism to monitor SQL Server Agent Jobs. Each job lets you configure what to do in case of failure, success or completion of its execution. The binding is similar to the alert’s one:

007.png

Once the result is collected, based on the configurations you’ve set up, this job will send an email to the app.

 

Binding custom Integration services email

In order to send an email from a SQL Server Integration Services package (aka .dtsx) you need to configure the SMTP server within the package itself. This is a little out of scope, because it’s not really a SQL Server notification. You can leverage the power of SSIS and prepare a rich HTML-formatted message; the result is nice to read and informative like in these examples:

 


Cool stuff, isn’t it? It’s simply a .NET script in SSIS, which uses the System.Net namespace. Although the SSIS package is executed within a SQL Server Agent job, the default notification message that SQL generates is not easy to read. The message you always get is:

JOB RUN:<name> was run on <date/time> DURATION: x hours, y minutes, z seconds. STATUS: Failed. MESSAGES: The job failed. The Job was invoked by Schedule xyz (<name>). The last step to run was step xyz (<name>)

<

p style=”text-align:justify;”>Decorating the package with a more detailed email will improve the readability and the accuracy of our notifications.

Setup an external monitor for notifications to Slack

SQL Server is often (hopefully) monitored with specific counters. We’re using PRTG monitoring tool to measure them, and when a baseline changes and a threshold is hit, we send notifications to Slack. How? Again, sending to the Email app integration, specifying the right channel to send to and getting this:

010.png

The above report has been truncated. In a complete version of it, you’ll find the complete details of the measures, like the name of the servers, the sensors links, the grid with all the results, and everything you can see inside a PRTG admin portal.

 

Test

Let’s see a more complete example, using a SQL Server alert. We’ll use the Severity 17 alert. Severity 17 is simple to raise and it describes a missing or insufficient resource when executing a command:

USE msdb; 
GO 

EXEC msdb.dbo.sp_add_alert @name=N'Severity 017',
    @message_id=0,
    @severity=17,
    @enabled=1,
    @delay_between_responses=60,
    @include_event_description_in=1,
    @job_id=N'00000000-0000-0000-0000-000000000000';
GO

Set the Response for the Severity 17 alert to “Notify Operator”, via email:

006

Run the following severity 17 based t-sql script:

RAISERROR(N'An error occurred Severity 17:insufficient resources!', 17, 1) 
WITH LOG; --don’t forget to use WITH LOG
GO

Go to your Slack account. If you’ve configured everything correctly, you should see the following:

011.png

Did it work? Great! If not, continue reading.

 

Troubleshooting

If you don’t see the notification try these steps:

  1. Be sure that your Slack account is confirmed (its email too)
  2. Once the Slack account is confirmed, check if the channel still exists (CTRL+K -> name of the channel)
  3. Click on “Customize Slack” in the drop down menu of your Slack client/webpage, then click on Customize App in order to check whether the Email integration is active or not:

012

013.png

  • Verify Database Mail configuration (try to send the test email)
  • Verify the operator configuration (is it enabled?)
  • Verify the alert configuration (did you bind the response with email to the operator? Is it enabled?)
  • Verify the SQL Server Agent email profile configuration (is it enabled? Is it the right one?)

014

Conclusions

There are some disadvantages when using this kind of integration. For example, you cannot customize the message, unless you do it inside a .NET script. The Slack Email Address is publicly available, albeit hard to discover, so anyone can send message to your private slack channel by sending emails to that special address. Again, you cannot send the notification to more than one Slack channel or outside of the Slack world. In reality native SQL email notifications show the same limits, where email addresses of distribution lists are similar to Slack channels.

For our purposes, this is a very-low-effort automation with a high return in terms of value. With a couple of clicks, you can setup an email address representing a Slack channel, and, with little more, you can get notifications in a smart and comprehensive layout.

Everything is kept inside the collaboration chat tool we are using massively, every day. In the end, this example embeds one of the core DevOps principles (automation) and provides huge cross-role and cross-team value, especially when the channels include also network and server teams.

I hope that you’ll give this a try.

ALM DOs & DON’Ts – Definition of done

We all have been in this kind of situation: someone in the team states that a feature is done but in reality there is that little thing to figure out and the coding is completed the day after. Why is that? Because every person has a different definition of done inside his mind.
How can we protect a team from this? Simple! With a Definition of Done.

definition-of-done.png

A good definition of done explicits what activities has to be done before declaring that our coding activites are over.
For example:

  • All unit tests are green
  • Coding style and conventions are respected
  • UI respects the specs validated by the Customer.

Every team and every project will create a different definition of done. The very important thing is that you and your team discuss such a definition to remove wrong expectaions about the status of work in progress.

Spazio… ultima frontiera…

Persone e Interazioni più che Processi e Tool”, il primo Valore è il punto di partenza di qualsiasi cambiamento che si ispiri all’Agile, Lean e DevOps, e sottende esplicitamente la necessità del cambiamento Culturale come aspetto portante.

Spesso però c’è un elemento che viene dimenticato o sottovalutato, ma che rappresenta un aspetto portante se si vuole promuovere la cultura Team basedalla base stessa dell’agilità: lo spazio fisico di lavoro.

Se ci si riflette per un momento, si riesce subito a capire come spazi adeguatisono essenziali per tutta una serie di motivi: dalla comunicazione diretta(come suggerito dai Principi), alla possibilità di avere i necessari Information Radiator, come la classica Kanban/Scrum Baord, che accompagnano il team nella visualizzazione e gestione dell’avanzamento delle attività.

Ogni team dovrebbe avere la propria area sufficientemente aperta, per comunicare trasparenza e disponibilità verso gli altri, e chiusa quanto basta, per garantire una condizione di privacy e generare il senso di appartenenzaal team.

In pratica, solo varcando la sogliadel working space del team possiamo conoscerlo realmente senza però trasformarci in ospiti indesiderati che vanno ad alterarne le dinamiche naturali.

L’importanza degli spazi è ben evidente in Lean, dove la tecnica/tool delle 5S (Seri, Seiton, Seiso, Seiketsu, Shitsuke) è tra quelle primarie, evidenziando come un’area di lavoro ordinata sia abilitante per poter lavorare in modo efficace ed efficiente. 

poster 5s leanproducts

In questo caso, però, la postazione è più intesa come scrivania personale di lavoro che come area del team. La connotazione più “Agile” è, invece, ben esplicitata in Disciplined Agile, rappresentando uno dei Goal della fase di Inceptiondi DAD: Form Work Environment.

dad goal form work environment

L’attenzione, però, non si limita ai soli ambienti fisici, ma si estende anche alla selezione dei tool e la creazione degli ambienti digitali di lavoro, aspetto fondamentale per introdurre un approccio che guarda a DevOps sin dall’inizio, andando ad abbracciarne le principali pratiche abilitanti come la Continuous Integration e Continuous Deploy o la creazione automatizzata di ambienti consistenti per il testing.

Interessante anche il concetto di “Tailor initial process”, recentemente aggiunto, che nella creazione degli ambienti tiene conto dello specifico lifecycle adottato e della relativa incidenza sul resto (principio “Choice is Good”) 

Tornando agli ambienti fisici, è fondamentale affidarsi ad esperti che vadano a studiare effettive soluzioni di riorganizzazione, tenendo anche conto di vincoli come, ad esempio, la sicurezza delle persone e gli spazi minimi individuali previsti per legge. Fondamentale è ricordarsi di creare, oltre alle aree dedicate ai team, le cosiddette Quite Room in cui potersi “ritirare” per fare delle riunioni che richiedono un isolamento completo e massima concentrazione.

Il tutto non deve mai portare alla creazione di enormi “pollai”, ovvero mega open-space con decine di persone in cui il caos comincerà a regnare sovrano non appena si inizierà a lavorare e comunicare.

 

Stay tuned J