Archive

Posts Tagged ‘Practices’

Continuous Integration with Jenkins

July 22, 2011 Leave a comment

I have been practicing and preaching about Continuous Integration for the last 5 years and I plan to utilize it for years to come.  I am a strong believer in small, frequent code changes, integrating those changes with others, and testing that code base ASAP.  The best way to automate and manage this practice is through a CI Server. I highly recommend Jenkins to fill that role.

I used Cruise Control for 2 years, then switched to Hudson for 2 years, and followed the fork to Jenkins the day it came out.  I love the modularity (plugin architecture) that Jenkins provides, their delivery cycle, and the prompt responses from the community.  I strongly believe the reason it’s so popular is because the core team has made it extremely easy to contribute. They have very good documentation and getting a plugin created, built, deployed, and delivered is all done via a few maven commands. This is a whole lesson in itself on how to build a community and welcome contributors.

Every project/product we work on at Sentry is hooked into our Jenkins instance, which utilizes several slave nodes for balancing the work.  We have projects written in PHP, Ruby, C++, Java, and Clojure all running under Jenkins, pulled from either SVN or Git, alerting us (IM and/or Email) whenever something breaks.  We also have our Selenium tests (via Fitnesse) being executed from Jenkins as well.

Our builds consist of static analysis code checks, execution of automated unit and integration tests, generating code coverage reports and API documentation.

Building on the CI practice, I am preparing to move several of our products to a Continuous Deployment approach with the goal of Jenkins managing that as well.

Advertisements
Categories: Uncategorized Tags:

Small Frequent Commits

July 16, 2010 Leave a comment

Recently I’ve been thinking about commit sizes and frequency and after several good conversations with my co-workers I decided to write this down.

It seems like some developers are stuck in a mindset that they have to commit large chunks of code all at once (when they’re “done”).  Part of this could be due to your VCS, if it doesn’t support local commits (like GIT).  The other, more important part, is that tasks aren’t broken down into smaller, more manageable pieces that could be completed independently from one another.

Here’s a good Coding Horror blog that explains what I’m after:
http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html

Here’s a few examples of small independent operations that should be committed immediately and separately from other work.

1) Renaming or moving a file.
2) Formatting a file so it’s easier to read.
3) Refactoring a method.
4) Adding a new test method to an existing test class.

If you had to perform each of those steps, plus the actual fix/feature work, I would expect to see 5+ commits for that task.  Don’t be afraid to commit more than once, your (D)VCS can handle it.

Smaller changes mean less risk is introduced to the code base, bugs are easier to identify, and code reviews are simplified.

Categories: Uncategorized Tags:

Pair Programming Blog

May 10, 2010 1 comment

I wanted to share this blog article I found over the weekend. I think it does a great job describing the types of pair programming, when they can/should be used, and what pit falls to avoid.

http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/

Categories: Uncategorized Tags:

Refactor Mercilessly

April 7, 2009 Leave a comment

One of the montras of Extreme Programming (XP) is Refactor Mercilessly and that is something all good software developers must do.

Here’s a couple paragraphs from http://www.extremeprogramming.org/rules/refactor.html

“We computer programmers hold onto our software designs long after they have become unwieldy. We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. But is it really cost effective to do so? Extreme Programming (XP) takes the stance that it is not. When we remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs we are refactoring. Refactoring throughout the entire project life cycle saves time and increases quality.”

“Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed.”

Categories: Uncategorized Tags: