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…
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 to6. Be happy. You are a good human being.
blame share your future bugs with.