Category Archives: alm

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!

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:

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.

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 & 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.

ALM DOs and DON’Ts – CI builds status

We all know the practice of continuous 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 our 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.