IT, teams and tests

At the same time I write this post I'm working in a big proyect: API, site, mobile, CRM, backoffice, SSO and other little microservices... And I would like to not repeat some errors I found.


More important than the branch strategy, the cvs you choose, or the people you hire.

Test are the point around everything will turn.

TDD or BDD, choose what matches better for you project and follow it. Be constant, a good test suite could be more important than the code it test.

TDD and BDD will not solve wrong business decisions or poor specifications but will ask you the right questions and will force business to complete this business specs before start the coding process.

Be strict with the code coverage, no less than 80%. Use tools analyse the code, will always give you some help. And last and more important test are inmutable.

Your tests will hold the door! Hoooold the dooooor!

If test fail on your branch don't comment it or change it quickly to commit asap because you break it, every time you do it a white cat die.

Analyse why is failing, there is only few cases when a test can change: a business change, an improvement or an addition.

Keep that on mind.

If a test fail on your branch is your fault, your responsibility, but we use to work on teams, so the responsibility should be shared because...

Code review

Yes it's a really important point.

... the responsibility of the project resides in the team, all the team.

There is no two equal persons, neither the twines. In a team there are people that code slower than other, other know 6 languages other 60. People that solves structural problems with few lines, others with a Bible. But all this people can help and have the same protagonism in the team but just if they are doing what they are really good in, at least the 80% of they working ours.

The code review will help to extract better conclusions about the team members.

It's the key for a healthy team where the knowledge is share and the moral keeps high. Consider a developer as someone that need learn continuously, the code review will help on this task.

But can burn, when someone on the team doesn't responds on time to the expectations and a pull request it's 2 weeks pending and each commit it's a new regressions something is going wrong, maybe someone in the wrong position. Do something don't wait more, follow the common sense.

Automation and infrastructure

Avoid repeat tasks the same way you avoid repeat code. Use a tool, TravisCI, CircleCI, Jenkins, what you prefer, but use it. It's your firewall for bad practices, regressions and misunderstandings.

Test not passing? No merge PR.

Test OK on develop branch? Allowed merge PR and Deploy to staging.

The environment it's always a pain, each environment has his own configuration

A lot of time dealing with that?
Try solutions like vagrant or, even better, docker. And of course automatice the builds on each commit in your CI tool.

Mb_string module compilation fail on this commit? No merge PR.

Ansible, puppet, Docker and docker compose etc will help you to have your infrastructure as a code, make easier deployments and have the full control about what you have on each environment.

I use docker on the company, best solution ever.


It's the best way to propagate an error around the ecosystem and difficulties a lot the debug process, but once you have that on maind and know how to deal with it... Will allow you to:

  • Delegate responsibilities
  • Isolate services and logic
  • Prevent risks
  • Allows you to have smaller projects easier to tests

By the other hand the complexity of the infrastructure goes to the next level and you will need a Discovery Service like consul, k8s or etcd and HAproxy to deal with.

That sounds like a terrible pain but in fact it's not, it's a funny process and you will enjoy the magic you can do.

See Let's bonus in 5 months 5 guys, since 3 weeks 6, made all this staff from scratch without know so much about docker, docker compose, docker engine, docker machine, docker swarm, vagrant, Jenkins, behat... and a long etcetera of things we learn by the way.

From a legacy monolithic application to a micro services architecture with more than 6k tests in total. We are not very disciplined persons, but we have something clear: your code should work.

Micro-services is not a solution to everybody but best practices yes. If your company doesn't let you to go to that direction and prefer spend 2 days making a deploy because everything crash and a week solving bugs... makes you a favour: leave the company