Tuesday 20 September 2011

The Check-In Procedure for my team


This is an email I sent out to my team yesterday. What do you do before checking in code?
---
Hello rose petals,
I’ve put a stuff to do before you check-in procedure on the wall.
In case you do not look on the wall (even though you should try to each day), here is a summary of the summary…
1. Merge all your code locally by doing a Get Latest Version from TFS;
a. Resolve any conflicts by trusting what is on the server and moving your changes in to that code. If anything can’t auto merge or conflicts seriously with your code then find the dev who wrote it and have a chat about how to make it work. This is a life skill, grasshopper.
2. Run all the tests (not just your own) and make sure they are all still working. This process is regression testing and stops you introducing a bug that causes something else with a dependency to fail;
a. Functional, Integration and Unit tests should be run.
b. If you do break something and fix it then write a test around that area because it seems fragile and may happen to someone else. Tests are security blankets. I’ve always wanted a teddy bear called CI.
3. Ensure all compiler errors and warnings are fixed;
a. Warnings exist for a reason. They speak of great tales of possible performance errors and sagas of linking and runtime optimisation. They are not there for the entertainment of the devs who wrote Visual Studio or .NET, they are for us.
b. Use ReSharper to make the little green box at the right top of each code file green. Ask me what I mean by this if you aren’t sure.
c. Use fxcop to ensure static analysis rules are complied with. Yes, even the ones you don’t love but we have decided are standard for our project.
d. Retro Steve will cry if you check in without these warnings resolved. I will look disappointed. Puppies will die.
4. Check it in!
5. Show another developer your code for review and check out the code and run the tests on their machine;
a. This means you have someone else to blame share your future bugs with.
6. Be happy. You are a good human being.
This is why I should not take pseudoephedrine during work hours. Damn cold or hayfever or something.

2 comments:

Buddha Buck said...

Out of curiosity, what ReSharper warnings and errors do you pay attention to with the little green box?

Damana Madden said...

Hi Blaise, my resharper settings match the All-In-One coding framework from Microsoft with a few resharper defaults thrown in.

Nothing new. Pretty standard. It is more the warnings and hints that matter in this case though.

Acknowledge Me

Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...