Andrzej is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. View Full User Profile

Small, deployable commits

01.12.2012
| 5398 views |
  • submit to reddit

We've had an interesting discussion at our stand-up today. The discussion was triggered by Jan Filipowski post on "early commiting in TDD".

The main questions are:

  • Should I refactor before every commit?
  • Should a commit pass all tests?
  • What units of code should be code-reviewed?
It got me thinking about my current approach and about my "ideal world" approach. I'm a big fan of the idea of continuous deployment. It means that every commit, after passing all tests, can be automatically deployed. 
I'm not there yet. I try to work with very short commits, often it's only 2-line changes. However, I still miss an infrastructure which could automatically push this commit, test it and deploy. It's not that it's difficult to prepare, it's just some kind of a psychological bareer. It's definitely something I want to improve as soon as possible.
Sometimes it's hard to have deployable commits. Recently we've been upgrading our app to Rails 3.1 and it's not something that can be done in one commit. 
Going back to questions:
Should I refactor before every commit?
Refactoring is part of a workflow, but I wouldn't say it should part of every commit. Sometimes a commit can be just the red-green part, and it's the next commit that does the "refactor" part.
Should a commit pass all tests?
This is a tricky one. In my ideal world - yes, because it should be deployable. Is it hard to achieve in practice? I'm wondering if there's a conflict between a deployable commit and one that fails on some tests.  Maybe it's fine to have some tests failing, if they are not part of the code that is being used in production?
 What units of code should be code-reviewed?
We tend to make code reviews using GitHub commit comments. They're fine, but sometimes I comment on something that was changed 3 commits later, which makes my comment irrelevant. 
Obviously it all depends on a project. In most cases I think we shouldn't be too serious with the code reviews comments. In my opinion code reviews should help us triggering some coding/architecture discussions, they shouldn't be too formal. I don't like proceses which require code reviews before the code goes into production - we should trust each other that nothing stupid gets deployed. If we treat a code review as a tool for better communication then it's not that important if a comment is about a code that changed later or not.
How about you? How often do you commit?

 

From http://andrzejonsoftware.blogspot.com/2011/12/small-deployable-commits.html

Published at DZone with permission of Andrzej Krzywda, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Afandi Merathi replied on Sun, 2012/03/18 - 7:11am

As often as possible - my main reasoning being that having a finer granularity of changes lets me revert a commit much easier in case of something going awry.

We've experimented with pre-commit code reviews with SVN a while ago, and that has worked okay. Our process at the moment uses reviewboard with a branch-per-feature approach - eg. a feature is started, reviewed and finished within a branch, and only then merged into a branch that is later deployed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.