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:
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.
A good definition of done explicits what activities has to be done before declaring that our coding activites are over.
- 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.
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.
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.
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.
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.
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.
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.
In the last post about VSTS (Visual Studio Team Services) we setup the foundations for a project.
In this we install a private agent to build and deploy our project.
VSTS provides hosted agents to build and deploy. When we use a hosted agent, Microsoft takes care of the maintenance and upgrades. So for many teams this is the simplest way. Every agent has a set of capabilities that indicate what it can do. Capabilities are name-value pairs that are either automatically discovered by the agent software, in which case they are called system capabilities, or those that you define, in which case they are called user capabilities.
If the hosted agents do not suit our needs we can setup our dedicated agent and that’s the topic of this post.