Philippine Ruby Users Group

How to avoid breaking builds

The guy I’m mentoring right now in one of my freelancing gigs is fairly new to software development so I decided to give him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git. Hopefully this should spare me the horrible flashbacks to the days when everyone I was working with was consistently breaking builds everyday.

Best Practices

• Commit often. The more you commit, the easier it is to do stuff like rolling back changes or pinpointing where a change was committed.
• Put a meaningful comment every commit. You’ll be thankful you did that 3-6 months down the line when you’re trying to verify if a certain piece of code is a bug or a feature.
• Push with care. Follow the procedure below to avoid breaking the build i.e. pushing a version of the code which doesn’t work.

Proper Version Control Procedure

Before you push your code to the repository, please follow the following procedure:

• If you still haven’t done it yet, commit your changes to your local repository (git add and/or git commit -a -m).

1. Pull the changes from the remote repository (git pull).
2. In case of conflict, manually edit the conflicting files.
   • You may have to collaborate with the other dev for this.
   • After fixing the conflict, commit the merged changes and go back to step 1 (git pull).
3. Run the DB migrations.
4. Run the RSpec tests.
   • If the specs fail, either fix the code or fix the specs.
   • After fixing the failing specs, commit the fixes and go back to step 1.
5. Run the Cucumber tests.
   • If the specs fail, either fix the code or fix the features.
   • After fixing the failing features, commit the fixes and go back to step 1.
6. Do a simple developer test. Open the server, log in, and open a couple of pages.
   • If the system doesn’t work, find the problem and fix it.
   • After making the system run smoothly again, commit the fixes and go back to step 1.
7. You can now push your changes to the remote repository using git push.

You might notice that we’re using RSpec and Cucumber in our project. I’ll talk more about them in a later post.

This post by Bryan Bibat is from existence, refactored.