The 7 levels of continuous integration


Friday, May 20, 2011

I’ve noticed that when other developers talk about “continuous integration” they do not always mean the same thing.
The following is an outline of the seven stages of continuous integration based solely on my own experience:
  1. No Server, no automation - no problems
  2. Have nightly build that run each day – at least we know that the project compiles
  3. Started writing “unit” tests – now running as part of the nightly build
  4. Created a build that runs on each commits – who broke the build?!
  5. Added static code analysis and style checking to the build
  6. Server Build, deploy & run the tests on several environments also used to deploy on testing (and production) environments
  7. Everything is automated – Even Gui tests runs automatically on the latest code, you even got as far as testing the installer. Code is analyzed and results are sent by email. Nothing is done manually unless it is done only once…
These are my stages as I experienced them in several jobs – what are yours?

Happy coding…

QA and Development in Agile 2011

No comments

Tuesday, May 17, 2011

This Thursday (May19th) I’ll take part in a Panel at the “QA and development Agile” conference.

I’ve been asked to talk about unit testing, TDD, SCRUM and anything else agile – topics that you should be familiar with if you’ve been reading this blog.

There would be developer and QA tracks with very interesting sessions two of which by good friends of mine: Gil Zilberfeld and Lior Friedman.


I’ll be there all day long so if you’re there, come and say hi.

Don’t fix invisible bugs

No comments

Saturday, May 07, 2011

Last week I conducted yet another code review. While looking at the code I’ve noticed a lot of lines similar to If(x != null) and if(y < 0) all over the code. These lines were not “business related” but were put in the code to make sure that proper inputs were given to the methods. Usually this is a good practice but further review showed that some of the code was checking for conditions that could not possibly happen. it meant that a lot of effort was given to creating code that checks for things that would never happen.

I’ve asked the developer why he written that code and he answered that it was put there to make sure that he handles a certain scenario properly. I’ve asked him when such conditions would happen and after thought he answered – never!

In that case - I said – please remove this code. At first he insisted that the code should stay there because: You can never know and because it was already written. I didn’t even dignify the 2nd remark with an answer but instead told him to write a unit test that shows that the code was important and could save us from disaster. After a few tries he was convinced that there is no way to cause his methods to fail and that this code is not needed.

This is not a new thing, when I see a fellow developer over thinking some method or class I suggest that first he write a test. I try to make sure that all of teammates practice TDD (Test Driven Development) along other benefits writing the tests before hand guarantee that every lines written is needed. But even if you do not writes your tests first and you find yourself asking whether you need to write “that code” try writing a test before to show that there a problem there that need solving…

It seems that code coverage goes both ways – it’s important to make sure that your code is well tested but if there is a piece of code that is not tested it could be because it would never run – and as such can be removed.

Related Posts Plugin for WordPress, Blogger...