Wrong version of ISDeploymentWizard in SSMS 17.8.1

The problem

Years ago, with SQL Server 2016 release, Microsoft came up with a separated brand new version of SQL Server Management Studio. It’s been a happy day for the SQL Server community and database developers.

Shortly afterwards, our company started to migrate every instances from older version of SQL Server to the 2016, using SSMS 17.*. Developers have already jumped into Visual Studio 2017 and everything seemed to work like a charm, until we started deploying integration services via the new SSMS, after we converted them to 2016 TargetServerVersion (which is NOT the Project Version).

The TargetServerVersion is the SSIS version, also for the deploy operations, while the Project Version setting tells to Visual Studio how to open projects based on .dtproj specifications on the XML projects definitions.

Some days ago I’ve realized that after updating to the latest build of SSMS (17.8.1), the .ispac deployment is actually executing the latest build of the Integration Services Deployment wizard (aka ISDeploymentWizard.exe). As a result every deploy of .ispac files, regardless trying double click or deploying directly from the Integration Services Catalog, the SSISDB, failed with one of the most scaring error message ever:

“[…] The Script Task <unique_name> uses version 15.0 script that is not supported in this release of Integration Services […]

What? Why? I’ve a workstation with SQL Server 2016 and the related Integration Services 13.0:

blog_ssis_error_001

The computer I’m speaking of has the same build of mine, nobody has installed any other Integration Services versions anywhere. Andy Leonard explained this behavior in this blog post. Unfortunately, in my scenario, I cannot solve the problem.

Let’s try to explain better.

Scenario

The workstation I’m working on has SQL Server 2016 (build 13.0.5149.0) and Integration Services 13.0 on Windows 10 Pro. I’ve got a simple package with a single script task which does literally anything:
blog_ssis_error_002bAs Andy suggested us, I’ve changed the TargetServerVersion to SQL Server 2016, so I’ve got C# 2015 compiler for scripts:


First execution and deploy

Executing it locally, nothing happens, but it happens in a green way (success):

blog_ssis_error_002a.PNG

Ok, now we’re going to deploy to the other machine, generating the .ispac file and double clickin on it. It’s important to make sure that you’re double-cliking the .ispac file. Do not right click on the Integration Service Catalog project folders because SSMS will execute the latest build of ISDeploymentWizard.exe by design.

blog_ssis_error_008b

deploy from SSMS 17.8.1

 

When double clicking, the app selector should use the version related to the TargetServerVersion setting of the .ispac. This works for many of my other computers. But for one of them, here is the screen:

blog_ssis_error_005

double click on .ispac file

Hey! This is 2017 also when clicking on .ispac file. Let’s try to deploy using the new tool. The deploy succeeded.

blog_ssis_error_006.PNG

And now, let’s try to validate the package execution via SSISDB, right clicking on the project itself and selecting “Validate…”. This is the result of the empty script package validation:

blog_ssis_error_007.PNG

I’ve tried on six different machines, five ran successfully and ONLY ONE returned the above error message. Still stuck in the middle.

What have we changed?

Just the setup of SSMS (17.8.1) updating the 17.7 one. Once again, the same setup on all six machines. Five by six worked, this one is trying to kill me.

For some strange reason, something (I assure you all, not someone) has changed the registry in the .ispac application association, maybe when double clicking for the first time the file in a pending reboot (?). We’re still investigating, since we used to avoid any change in production without permissions and processes. That said, it’s weird. And it was so difficult to get.

Solution

Easy to say, now that we’ve figured out the root consequence. Not so good, but changing the registry on the key HKEY_CLASSES_ROOT.ispac with the 130 executable (IntegrationServices.ProjectDeploymentFile.130) fixed the unwanted behavior. The key has been set to IntegrationServices.ProjectDeploymentFile.140 right after the update from 17.7 and 17.8.1.

Instead of changing it via regedit, you can try an “open with…” with “use default” checked in order to force the association between .ispac file and the right ISDeploymentWizard.exe version. But this time, in this machine, it didn’t work. This is the reason why I tried the regedit action.

Conclusions

I have to say a big thanks to Andrea Amantini, one of my peer, which is well known for his ability to find out “a needle in a haystack.”. Strange things happened here. A combination of Murphy’s law, a sort of “black” friday and a pending reboot. Hopefully this helps someone, at least.

How to release a hotfix with pull-request inside VSTS in 3 steps

We all know the situation: the customer finds a critical bug in the latest release and he wants us to release a new version of our application with a fix. How do we handle this situation without breaking our team policies? How to release a specific fix to avoid regression problems?

First we need to fix that bug with the classical approach of feature-branches. We create a branch, fix the bug, create a pull-request and the team approves. These activities are set at the highest priority because a customer is in trouble and we must help.

Now we are in a situation where we have a specific commit that solves a specific problem with only the necessary lines of code modified.

commit-with-fix.png

Our target is to ship that specific commit that fixes that specific bug with a standard pull-request, without all the other work done in the development branch since the latest release. So we write down (in our clipboard for example) the id of the commit.

shaid

What can we do now to release?

1. New branch

We create a new branch.

git checkout -b my-hotifx

Now we fetch the latest updates from the remote repo.

git fetch origin

Then we set our branch my-hotfix to point to the latest commit of the remote release branch.

git reset --hard origin/release

branch-release.png

2. Cherry-pick

Now we cherry-pick the specific commit we want to apply to the release branch without commiting (–no-commit option). We choose the no-commit option to carefully inspect what is going on in our files. It’s here where we use the commit id we saved early.

git cherry-pick <commit-hash> --no-commit

We verify that everything is fine (where fine depends on your specific project). Now we can commit and push to VSTS.

git add .
git commit -m "Hotfix"
git push origin mybranch:mybranch

final-situation-1

3. Open pull-request

Our branch is now on the remote repo and we can open the pull-request with VSTS.

pull-request.png

From here the team can approve the PR and fire up our automated release process that activates our automated test and if everything is fine we deploy safely.

TL; DR

With this blog post we explored the critical situation to release a hotfix without breaking the rules or taking shortcuts to avoid our release pipeline. As engineers we must maintain a cold approach even in hot situation and rely on our best practices. Human errors are always possible in particular when we’re stressed and a customer is making our phones hot.

ALM DOs and DON’Ts – Unit test

A unit test is a runnable piece of code that verifies that another piece of code (called production code) does what it is supposed to do.

A unit test has many characteristics and one of the most important is that a single unit test must verify one and only one thing.
If a unit test specifies more than one behavior things became harder to mantain. One a tests fail it has to be easy to understand what is going wrong and which section of our production code is behaving badly.

unit-test-one-thing.png

As a best practice we make each test independent to all the others: any given behaviour should be specified in one and only one test. Otherwise if you later change that behaviour, you’ll have to change multiple tests.

 

ALM DOs & DON’Ts – Database source control

Every application needs to store its data. A (relational) database is the most common choice in many situations. Like every other component of our software project, a database schema must be managed with a version control system. We will never work without source control for our source code files and we must use the same mindset when dealing with a db.

database-source-control.png

The database is a critical part of our application. If we deploy version 2.0 of our application against version 1.0 of our database, what do we get? A broken application. And that’s why our database should always be under source control right next to our application code.

Advertisements

ALM DOs & DON’Ts – Database source control

Every application needs to store its data. A (relational) database is the most common choice in many situations. Like every other component of our software project, a database schema must be managed with a version control system. We will never work without source control for our source code files and we must use the same mindset when dealing with a db.

database-source-control.png

The database is a critical part of our application. If we deploy version 2.0 of our application against version 1.0 of our database, what do we get? A broken application. And that’s why our database should always be under source control right next to our application code.

Advertisements

ALM DOs and DON’Ts – CI builds status

We all know the practice of continuos integration.

One of the common pitfalls about CI is that the build status is not monitored and not treated as one of the top priorities for the team.

build-ci-status

A healty/green status of our CI process means that ore code is in a good shape for what our automated tests can tell. Fixing the build status ASAP is easier than leave it red and fix later because the recent changes of the codebase are vivid in the team members’ memory.

Un Leader non è per sempre… meglio non essere Chief di se stessi

Devo ammetterlo: non riesco a trattenermi dal sospirare ogni qual volta, in una organizzazione che si ispira all’Agile, incontro qualcuno che aggiunge ai ruoli specifici il suffisso “Chief”, trasformando di fatto quel ruolo in una posizione di implicito comando.
Se ho la fortuna di lavorare con persone che amano mettersi in gioco, e sono predisposte nello sfruttare l’ironia come strumento di crescita, spesso scherzo evidenziando come “Chief” mi ricordi il noto detersivo,

cif spruzzatore

e di come, tale suffisso, potrebbe indicare, in chiave Lean (DevOps), una persona che ispirandosi alle 5S e al concetto di Servant Leader, si occupi di pulire la scrivania dei propri colleghi per aiutarli a migliorare la propria organizzazione locale. Di certo non è il “capo”!

poster 5s leanproducts

Le 5S di Lean

Al di la del “suffisso” (che potrebbe essere anche “chief”, vista l’implicita accettazione che ormai gli si associa), è innegabile che una visione complessiva di un’azienda in chiave Lean/Agile richieda l’aggiunta di diversi ruoli di coordinamento, ma la loro “istituzione”, se avviene a freddo e senza coinvolgimento dal basso, rischia di trasformarsi in una nuova piramide organizzativain cui c’è un “capo” che da degli “ordini” espliciti ai subalterni, piuttosto che un Leaderin grado di ascoltare, risolvere le problematiche e guidare, quando necessario, le Persone con autorevolezza e raramente (se dicessi “mai” sarei poco realista) con autorità.

La questione, chiaramente, è riuscire a coltivare delle Persone che sviluppino le caratteristiche primarie di un Leader, riassunte nell’esplicita infografica di Alessandro Ferrari, andando al di là del titolo assegnato e dell’atteggiamento di aver raggiunto una “posizione” di comando sugli altri.

leader infografica

Un’azienda che ha la bravura, e un pizzico di fortuna, di far crescere i propri Leader, non ha bisogno di assegnargli titoli che richiamino il “comando”, perché queste Persone sono implicitamente riconosciute al suo interno come “trascinatori”, contemplando il fatto che ogni membro dell’organizzazione può diventare Leader in qualsiasi momento, catalizzando l’attenzione dei propri colleghi.  

Ciò, ovviamente, implica che un “Leader non è per sempre” solo perché è un “chief”, ma deve guadagnarsi tale riconoscimento giornalmente sul campo per non trasformarsi, nella migliore delle ipotesi, in “chief di se stessi”.

Stay tuned J

Power is nothing without control

You can’t control (leave alone improve) what you can’t see – Me

Power is nothing without control – Pirelli

Why a dashboard?

When we drive our car we have everything under control: speed, revs, oil and water temperatures and fuel level. We need a dashboard in our car because we have to know our current speed to respect speed limits, to know how much petrol we have in our fuel-tank to decide if we can go to work without a trip to the gas station etc. All this data to do the simple job of driving! This is necessary because we need to take informed decisions.

white motorcycle cluster gauge

Photo by Mikes Photos on Pexels.com

What does it mean for our daily activities in a software department? We need our dashboard, too! How can we do our job of deliveing (not only writing!) a working software with the lowest bug count as possibile, quickly, on a budget and coordinating with other people? It’s a huge task compared to drive a car alone and yet many of us rely on instinct and guts to make decisions for an entire software team.

A dashboard for the software Engineer

Which indicators and gauges do we need as software engineers? I think there are a few things we Always need to know about our team.

  1. Team Cycle time: how much time/days does a unit of work take to go from started to completed? And with completed we mean delivered to the customer.
  2. Team Lead time: how much time/days dows a unit of work take to go from a created to completed?
  3. How fast are we going? How many story points we deliver every fixed amount of time? (sprint, week… name your favorite).
  4. Bug count. How many known defects (bugs) have we? Is the count increasing or decreasing?

Here we can see a dashboard created with Microsoft VSTS where the team can get an immediate report of the situation.

2018-08-03_13-46-49.png

Create a dashboard

Every team is different and needs specific/custom dashboard. To create a dashboard with Microsoft VSTS we can go to

https://THE_DOMAIN/THE_PROJECT/_dashboards/

and then we expand the dashboard list with the arrow button (1) and click New Dashboard (2).

2018-08-03_14-02-31.pngWe give our dashboard a name and hit Create.

2018-08-03_14-09-48.pngWe can add widgets picking from the right-side list, search or browse the Marketplace to add something extra to our VSTS.

2018-08-03_14-11-55.png

When we’ve finished to create our dashboard we click “Done editing”.

TL; DR

A dashboard is a must have to control or improve our team and our process. It enables us to understand our current indicators and shows if a new way to work improves or worsen the situation. With a dashboard we can take informed decisions about many arugments: current velocity of the team, quality of the software, lead time and so on. We’ve seen how to create and configure a dashboard with Microsoft VSTS.

Reference

Microsoft VSTS Docs: https://docs.microsoft.com/en-us/vsts/report/dashboards/?view=vsts

Asciughiamo il Lago dei Difetti, aka Lake of Defects

Build-in Quaility è uno dei principi fondamentali di Lean, base del pillar Jidokadella famosa House of Lean. Il concetto di per sé rasenta il “banale”: ogni prodotto realizzato deve incorporare e abbracciare strutturalmente gli aspetti di qualità. La questione, però, è che il significato specifico di “qualità” e le azioniche concorrono al suo raggiungimento sono elementi tutt’altro che univoci e definibili in modo predefinito e/o predittivo. In fondo, siamo nel modo dei sistemi complessi, dove dobbiamo costantemente validare le nostre assunzioni per trovare la soluzione migliore adatta al prodotto e al contesto. 

Strumentipraticheprocessitoolci consentono di validare gli aspetti realizzativi e funzionali del prodotto, ma essere opportunamente innestatiall’interno del ciclo di sviluppo, dando dignità soprattutto alle Persone che ne sono i veri detentori, operativi e di know-how.

Nel mondo del software è comune associare l’idea di qualità al testing (anche se è un pelino riduttivo) ma spesso non si ha un approccio strutturato relativo, andando a fare “azioni artigianali” che finiscono per concentrarsi soprattutto alla fine delle attività di coding. Paradossalmente, questo modo di procedere genera uno dei più grandi Waste (Muda, Sprechi) che si possano incontrare lungo la filiera di Delivery, creando a valle del flusso di lavoro un Lake of Defects in cui i tester devono improvvisarsi sommozzatoriper poter individuare le deficienze del nostro prodotto e comunicarle in qualche modo agli sviluppatori. 

lake of defects

Lake of Defects

Si intuisce come tale azione sia estremamente lunga e costosa, aumentando notevolmente il Lead Time (che, lo ricordiamo, è il tempo totale di realizzazione di una funzionalità, da quando viene inserita nel Product Backlog a quando viene rilasciata) e diminuisce la capacità di avere feedback rapidi il più vicino possibile la cellula(o team) che fattivamente sta realizzando la specifica attività. 

L’approccio che mi capita spesso di utilizzare per cominciare a “drenare il lago” è quello di introdurre il noto modello della Piramide di Testing(Testing Pyramid, rif Mike Cohn), facendo attenzione sempre ad evidenziare che, appunto, si tratta di un modello e che, in perfetta chiave Agile, lo stesso va contestualizzato e validato operativamente sul campo.

testing pyramid

Testing Pyramid

Lo scopo è quello di spalmareil testing, ma più in generale tutte le attività annesse al raggiungimento dell’obiettivo build-in quality, lungo l’intera filiera di delivery. Si tratta di un approccio fondamentale e portante per avviare una “vera” trasformazione in chiave DevOps

Facciamo un esempio: se non ho un insieme valido di unit testall’atto della Continuous Integration, non sto facendo Continuous Integration (CI), ma semplicemente merge del codice! Ricordo che l’obiettivo della CI è quello di fornire rapidamente un feedback su quanto realizzato, non quello di generare la build!

Con un approccio strutturato alla qualità (o al testing, se preferite leggerlo in tal modo), si riesce ad asciugare il lago, trasformandolo progressivamente in una pozzanghera (Puddle of Defects) e, idealmente, facendolo scomparire del tutto.

puddle of defects

Puddle of Defects

Migliorando costantemente il proprio approccio alla qualità, la necessità di avere un “team di testing” viene tendenzialmente meno e le Persone che prima si comportavano da sommozzatori, possono dedicarsi a portare un reale e costante valore aggiunto, mettendo al centro il cliente in chiave Customer centric.

Stay tuned J

La Teoria della Scarpa a Rovescio

Più si cresce e più si tende ad amalgamarsi alle regole che tipicamente condizionano il nostro ambienteil nostrostile di vita. Si tratta di un processo che ci accompagna in modo silente, non accorgendoci nemmeno del fatto che esso sia in atto e di come limiti, in modo crescente, la capacità di guardare oltre gli schemi, così come quella di trovare modi ed atteggiamenti che riescano ancora a stupirci in risposta alla condizione di appiattimento generale.

Una metafora che “calza a pennello” è quella dei bambini che provano a camminare con le scarpe dei genitori: incoscientemente, e divertendosi, provano a indossarle in tutti i modi possibili, fin anche mettendola a rovesciorispetto al piede e provare a fare qualche passo.

scarpa rovescio

Ecco la magia! I bambini sperimentano per apprendere, senza nessuno che debba dirglielo o insegnarglielo… è così e basta.

Eppure, più si diventa grandi, meno possiamo mettere la “Scarpa a Rovescio”, non fosse altro che “fisicamente” non riusciamo a farlo: anche se prendessimo una scarpa della taglia doppia rispetto alla nostra, la cosa è probabilmente impossibile.

Riportando la metafora al nostro contesto, ciò significa che più ci amalgamiamoal contesto operativo a cui apparteniamo, più ne diventiamo contaminati, e più diventa difficile provare a guardare fuori dagli schemi.

Assimiliamo un modo di fare che ci porta in una comfort zone, trasformandoci in “pigroni” che provano a galleggiare sulle attività giornaliere, riducendo, se non perdendo del tutto, lo spirito disperimentazione della Scarpa a Rovescio.

Più cadiamo in questo limbo, meno siamo soddisfatti di quanto facciamo e, cosa che spesso sfugge alle organizzazioni, meno facciamo l’interesse per il contesto in cui operiamo: un manager che non sbaglia mai, non prova ad innovare, trovare nuove strade, non si ferma a riflettere, è, con molta probabilità, un cattivo manager che non sta guardando al futuro dell’organizzazione essendo “soffocato” dal quotidiano. Stesso discorso per tecnici, operativi, e tutte gli altri ruoli aziendali che possono venirci in mente.

Ma come reagiamo a questa condizione? Dobbiamo tornare un po’ bambini, andando a riscoprire la soddisfazione intrinseca nello sperimentare, nel porsi fuori dalla propria area di sicurezza, in modo da reinventarsi e reinventare la propria professione e professionalità.

Dobbiamo continuamente rincorrere l’effetto “WOW!”, rilassandoci ed imparando a guardare le questioni da una moltitudine di angolazioni, cercando lo spazio che gli altri ignorano e che ci permetterà di fare la differenza.

effetto wow 

Certo, per fare questo, è necessario che la nostra azienda abbia una cultura orientata alla sperimentazione ed all’apprendimento (la terza via di DevOps e uno dei pilastri di Lean), creando una safety-netin cui muoverci con la certezza che qualsiasi sarà il risultato della nostra azione, avremo comunque raggiunto un risultato apprezzato in quanto tale.

Chiudiamo con una frase resa famosa da Steve Jobs che sembra fatta a pennello: Stay Hungry, Stay Foolish!

Stay tuned J