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.

Advertisements

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.

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.

Quella sottile linea invisibile

Camminando giusto giusto sul confine tra Italia e Austria nel percorso Water Trail.

Un passo sei di qua e un passo sei di là. Così semplice, quasi banale. Eppure la differenza è enorme. Sarà una fissa mia ma queste cose mi affascinano. E mi chiedo: perché proprio lì la linea di confine e non un metro prima o dopo? Come viene deciso?

Questi confini geografici mi scatenano poi dei pensieri piu generici o astratti. Quanti confini attraversiamo nella nostra vita? E quanti ammettono un tornare indietro?

I nostri confini sono anche ciò che ci caratterizza: i nostri limiti, i nostri princìpi, la nostra confort zone. Cosa facciamo quotidianamente e in modo tangibile per espandere noi stessi, le nostre abilità e le nostre conoscenze?

Detto questo mi fermo qua, potrei cominciare a farneticare e sconfinare in un territorio filosofeggiante che non mi appartiene.

A voi affascinano i limiti, i confini, le situazioni limite?