Archivi categoria: DevOps

Come fare un daily stand-up meeting efficiente in “stile kanban”

Gli standup meeting sono un elemento comune dei processi di sviluppo Agile.

Meeting con kanban
Meeting con kanban

Di solito si fanno al mattino primo di iniziare il lavoro e hanno un formato standard. Uno standup meeting tipico consiste nel chiedere a turno ai partecipanti le tre fatidiche domande:

  1. Cosa hai fatto ieri?
  2. Cosa farai oggi?
  3. Sei bloccato con qualcosa e hai bisogno di aiuto?

Ogni membro del team risponde a queste domande e così il team è coordinato per le attività della giornata.

Con l’adozione di una kanban board le cose si svolgono diversamente.

Non c’è bisogno di chiedere a turno ai partecipanti le tre domande perché la loro risposta è implicita dalla posizione dei kanban sulla lavagna. La lavagna contiene tutte le informazioni su chi sta lavorando a cosa. Chi partecipa regolarmente ai meeting si accorge anche di cosa è cambiato e se qualcosa è bloccato o meno è visivamente evidente.

Perciò il processo è leggermente diverso in ambito kanban rispetto a daily meeting tradizionale. Il facilitatore, di soluto un PM, “attraversa la board”. Per rinforzare il concetto di sistema in tirare/pull, convenzione vuole che la kanban board si legga da destra versa sinistra (al contrario del processo di produzione del valore). Questo perché non ha senso spendere tempo ed energie su cose “a monte” quando “a valle” ci sono problemi che ostacolano il flusso del lavoro. Inoltre, questo aiuta a far rispettare i WIP limit per cui nuove attività non possono iniziare se quelle incorso non liberano il loro posto.

Il moderatore del meeting pone enfasi sugli elementi bloccati (visivamente evidenti per delle convenzioni sui colori). Vengono poste domande sul perché questi elementi sono bloccati e si adotta un approccio proattivo per cercare di sbloccarli il prima possibile.

Dopo aver discusso gli elementi problematici, il team può passare in rapida rassegna gli elementi in lavorazione, ma i team più maturi in questo ambito non ne hanno bisogno.

Questo meccanismo consente di ridurre di molto la durata di meeting, considerando che si parlerà solo di cui c’è bisogno in maniera puntuale. La kanban board per sua natura funge da radiatore di informazioni che, con un minimo di pratica, a colpo d’occhio possiamo interpretare e capire lo stato dell’arte con un semplice sguardo.

Video

In questo video una dimostrazione su come fare! 🙂

Libri di riferimento

Kanban, Succeful Evolutionary Changes for Your Technlogy Business | David J. Anderson | Su Amazon

Personal Kanban: Mapping Work, Navigating Life | Tonianne DeMaria Barry, Jim Benson | Su Amazon

(I link ad Amazon sono link affiliati, il che significa che se vengono acquistati gli articoli tramite quel link ricevo una piccola percentuale da Amazon. Per te non cambia niente.)

Azure Pipelines YAML hidden UI for parameters as input

The Azure Pipelines is the feature of Azure DevOps that allows you to automate your build and release processes, to unleash the full potential of CI/CD practices.

Pipelines can be simple or complicated but, it’s very likely that you need to specify some kind of input to a Pipeline just before starting it.

Classic Pipelines

This is where variables come to help when you’re using the classic version of Azure Pipelines. Inside the Variable tab you write variables and then you can set if it’s “settable at queue time”. This way, when you start the pipeline, a slice of UI will provide a prompt to complete. The input is treated as a string and you can’t do much more.

Option to set a variable at queue time.

YAML Pipelines – This is where magic happens!

If you’re trying to achieve the same thing with YAML pipelines you can rely on the power of parameters. Actually, you can achieve more with YAML pipelines!

Runtime parameters let you have more control over what values can be passed to a pipeline. With runtime parameters you can:
– Supply different values to scripts and tasks at runtime
– Control parameter types, ranges allowed, and defaults
– Dynamically select jobs and stages with template expressions

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/runtime-parameters

Because parameters are explicitly typed you can create a better user experience for users of your pipelines with a fully featured UI with check-boxes, radio-buttons and text areas. You can do this in 3 easy steps. Open your YAML definition and for each one of the inputs that you need:

  1. Create a parameter
  2. Specify a default value
  3. Specify allowed values

This an example of a YAML Pipeline definition that accepts a string as an input to complete the famous “Hello World” greeting but, within a set of specific allowed values. Also, the default value is set to world.

parameters:
  - name: myString
    displayName: string
    type: string
    default: 'world'
    values:
    - world
    - mondo

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, ${{ parameters.myString }}!
  displayName: 'Run a one-line script'

When you Run the pipeline the UI shows specific fields to collect your input (greetings in our example).

The Run Pipeline dialog with additional parameters.

I suggest you to try with all the parameters type that the YAML schema provides. This is a complete example showing all the available options:

parameters:
  - name: myParameter
    displayName: greetings
    type: string
    default: 'world'
    values:
    - world
    - mondo
  - name: myNumber
    displayName: 'Number'
    type: number
    default: '1'
    values:
    - 1
    - 2
    - 3
  - name: myBoolean
    type: boolean
    default: true
  - name: myObject
    type: object
    default:
      foo: FOO
      bar: BAR
      things:
      - one
      - two
      - three
      nested:
        one: apple
        two: pear
        count: 3
  - name: myStep
    type: step
    default:
      script: echo my step
  - name: mySteplist
    type: stepList
    default:
      - script: echo step one
      - script: echo step two

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, ${{ parameters.myParameter }}!
  displayName: 'Run a one-line script'


The resulting UI is:

Isn’t this awesome?

The power of the community

Thanks to my friend Giulio Vian of getlatestversion.it for the heads-up about this feature. The official Microsoft doc lacks a detailed explanation of this specific usage of YAML Pipelines parameters!

How to share an Azure DevOps Artifact feed with the entire organization

Azure Feeds used to be scoped to an organization. However, to enable public feeds and to become more consistent with the rest of Azure DevOps, feeds created through the new create feed UI are now project-scoped.

The only way to create an org-scoped Azure Artifact Feed is through API calls and it’s not reccomended.

If we want to share a feed with an entire organization this is what we need to do.

Continua a leggere How to share an Azure DevOps Artifact feed with the entire organization

How to fix 8000000A error when building VDPROJ

The Microsoft Visual Studio Setup Project is an old technology to create installer developed by Microsoft. It is out of support from nearly a decade and not present in Visual Studio anymore but when I visit customer sites I find legacy technologies and I need to deal with it on the short-term.

A couple of days ago I was working on an automated CI build on Azure DevOps and we hit an issue when trying to compile an old VDPROJ (migration to Wix in progress, btw ☺). We encountered an HRESULT 8000000A error.

Continua a leggere How to fix 8000000A error when building VDPROJ

Reduce your build time with parallelism in Azure DevOps

Your team works with a project in Azure DevOps. Your build time starts to increase as the project’s complexity grows but you want your CI build to deliver results as quickly as possible. How can you do that? With parallelism, of course!

Let’s do this together.

Prerequisites

Before we start to design a build pipeline with parallelism we must be aware of how Azure DevOps orchestrate parallelism and how many parallel jobs we can start. I recommend to read the official Microsoft Docs page about this.

Designing the build

The following example shows how to design a build with:

  1. A first “initialization” job.
  2. The proper build jobs: build 1 and build 2 that we want to run in parallel after the step 1.
  3. A final step that we want to execute after that build 1 and build 2 are completed.

We start with configuring the build to look like the following picture:

To orchestrate the jobs as we specified before we use the “Dependencies” feature. For the first job we have no dependencies so leave the field blank.

For the Build 1 job we set the value to Init. This way we’re instructing Azure DevOps to start the Build 1 job only after that Init has completed.

We do the same thing with the Build 2 job.

For the final step we set Build 1 and Build 2 as dependencies so this phase will wait for the 2 previous builds to complete before starting.

Here we can see the build pipeline while it’s executing.

TL;DR

With this brief tutorial we learned how to design a build pipeline with dependencies and parallelism that can reduce the delay of our CI processes. A fast and reliable CI process is always a good practice because we must strive to gather feedback as quickly as possible from our processes and tools. This way we can resolve issues in the early stages of our ALM, keeping the costs down and avoiding problems with customers.

GLV OnAir Febbraio 2019 – Video Link

Qualche settimana fa GLV ha trasmesso il suo episodio di GLV OnAir di febbraio 2019. La puntata è andata in onda col solito formato di 3 sessioni da 30 minuti ciascuna che elenco qui di seguito:

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.

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

VSTS for beginners: release your web-app to Azure

In the previous post of this series dedicated to VSTS we talked about continuous integration. Now we’ll talk about publishing our Web-App hosted on Azure with the release management tools provided by VSTS. With this kind of tools we can deploy the latest version of our web-app to Azure in complete automation removing manual procedures and human errors. The setup of Azure will be covered in another blog post.

 

Continua a leggere VSTS for beginners: release your web-app to Azure

Improve leadtime and workflow with WIP limits on VSTS

A powerful method to keep or make a customer happy is to satisfy his needs quickly. In our typical very busy day we do a lot of things and this hurts our ability to concentrate and focus. This is true for us individually but this is also true as a team.

Little’s Law

We can improve the response time to our customer by leveraging the Little’s Law:

It is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system. – Wikipedia

L = λ W

For example if our team completes 2 user stories every day (𝜆 = 2) and every user story takes 4 days to be developed (W = 4) we have a system with L = 8 ongoing activities.

If we write Little’s Law like this

W = L / λ

we discover that wait time (W) can be reduced if we reduce L, the amount of ongoing activities at the same time.

VSTS boards and WIP-limits

If you manage your team activities with Visual Studio Team Services (VSTS) you can improve the flow and reduce lead-time by limiting the amount of work in progress in your kanban board.

You can setup the WIP-limits in the board of your Backlogs. Go to Work -> Backlogs and then click on Board.

2.png

As you can see VSTS has the default value of 5 for the Active and Resolved statuses. It means that your team cannot drag more than 5 PBIs in the Active or Resolved column otherwise the number of activities turns red, indicating that your team is doing too much work at the same time.

1.png
Default settings of VSTS

3.png
Too much activities!

You can change the values for to better fit the needs and size of your team by clicking the gear icon in the board and access the settings and then click save.
Of course you can also change the column names and add other statuses as well but we’ll cover this in another blog post.

4.png

Where do I start?

A very low WIP-limit can freeze the activities of your team and it may be very hard to respect. Don’t spend lots of time to calculate or debate about WIP limit: start with number that gives flexibility, plan a meetings two week later and discuss it again. You and your team will find the right balance.

TL;DR

Limiting the work in progress is a powerful way to improve the lead-time of our activities and it’s very cheap, too! It’s a team discipline activity and at the beginning it can be counter-intuitive and hard to respect. When a team is doing too much activities at the same time the quality goes down and the lead-time goes up and rework will be required. If the WIP limits block you from starting a new user story you can pair programming with a colleague or reply to that old e-mail that’s waiting so long.

Picture1.gif