Build Jamming

Posted by Conrad Benham on July 23, 2008

Builds are a fundamental part of any project. They are the bedrock of a project. Done well they make development and maintenance of a project easier. Done poorly and they can increase the time it takes to develop and maintain a project and even make development difficult. A well structured build will even help reduce defects by making continuous integration easier and by ensuring tests are run during each integration cycle. A good build will also aid in the deployment of a system.

In our next Jam we’ll look at build systems. Identify what makes a good build system, looking at how they might be structured for best practice. We’ll also look at various tools that support builds. Specifically we’ll look at tools that support continuous integration, prevent code duplication, bug detection and style checking amongst other tools. This Jam will include both a theoretical and a practical part. Some of the practices introduced in this session will form the basis to some future code jams.

So, dust your laptops off and come along. If you don’t have a laptop (or it doesn’t work) then come along anyway, we’ll work in pairs so there should be every opportunity for you to team up with someone. Don’t forget your laptop charger!

Drinks will be provided.

When: 7:30pm, Tuesday 29th of July 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

CI is a Software Development Practice 2

Posted by Conrad Benham on July 21, 2008

A big thank you to Chris Stevenson for giving an “Introduction to Continuous Integration with a brief introduction to Cruise Control”. Chris works for ThoughtWorks. He has worked in many of the offices, most recently in Beijing and is en route to San Francisco where he will be lead developer of Cruise Control Enterprise.

Chris presented a solid introduction to continuous integration (CI) citing Martin Fowler’s work on CI. According to Chris, CI is about ensuring we have working, compiling code that passes unit tests. While many consider CI to be a tool, Chris made it clear that CI is actually a software development practice that is often supported by a tool, but does not have to be. As a result CI is a practice that is used by the team. Automated CI tools are important on projects that have larger teams. CI is the practice of continually integrating code changes made by members of a team with the code base, ensuring these changes don’t break the build in any way. This is verified by running an automated build (as distinguished from a CI tool) that compiles, tests and creates deployable artifacts.

Automated builds must include automated tests: both unit and behavioural tests. Chris introduced the practice of behaviour driven development (BDD), with specific reference to the tools RSpec (for Ruby) and JBehave (for Java). Chris also introduced a number of tools used for user interface testing: Selenium, WebTest, Sahi, Frankenstein, White, Abbot.

Chris spoke of the importance of small continuous commits to the code base. Small changes limit the amount of merge conflicts that occur when checking code into source code control systems and therefore minimising the pain that is associated with conflicts. It is therefore common for people to check code in many times a day. Chris highlighted the importance of a short build, discussing the implications of a build that takes a long time to complete.

Chris ended his presentation with a sneak preview of Cruise Control Enterprise which is to be released in the next week or so.

Interestingly, Eric Minick recently wrote a blog entitled “Continuous Integration: Was Fowler Wrong?“. Eric’s premise is that CI is about tests, not builds. Given the controversial nature of this, a discussion has commenced on The ServerSide.

A Code Jam will be announced in the next day or so which will provide a practical introduction to Continuous Integration tools and how to use them. So, stay tuned…

Continuous Integration with Chris Stevenson 3

Posted by Conrad Benham on July 09, 2008

Core to any serious software project is the build environment and source code repository. When developers write code they must check that code into a source code repository that allows developers to share their code changes with other developers on the project. But how can one be sure that changes checked in by one developer will work with changes introduced by another developer? The key development practice used to support this is Continuous Integration (CI). Integrating small changes often leads to a system that is always in a working state. Tools have been developed over the years to support this practice.

To talk about CI, we have Chris Stevenson. Chris is a senior Agile dude at ThoughtWorks who has worked on many different projects employing CI successfully. He will discuss what the practice of CI is and why an organisation serious about software quality should adopt it. Specifically, Chris will talk about the team dynamic required to adopt CI covering how it should be used and what to do when things go wrong. Topics will include the cost benefit of introducing a CI environment to an existing build process. He will also give a demonstration of tools supporting CI the practice of using Cruise Control.

When: 7:30pm, Tuesday 15th of July 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Lean Thinking with Richard Durnall 1

Posted by Conrad Benham on July 06, 2008

At our last gathering, guest speaker Richard Durnall gave a very interesting presentation on Lean Thinking in IT. In his presentation, Richard covered a large spectrum of the Lean Thinking space. From a solid background of applying Lean in the Automotive industry (where Lean grew from) Richard spoke with authority on the history of Lean and its application. He then drew from that experience to explain how Lean thinking can be applied in IT.

Lean Manufacturing has had a major influence from Japan where Toyota used it to great effect. This influence means that many Japanese words can be found in Lean to describe various components of it. One of those words, muda, for example is used to describe waste. Another word, jidoka, as Richard explained it, is about autonomation or automation with a human touch. It focuses on introducing technology to people in a structured and considered manner such that those people will adopt the technology being built for them. A system that is built that dismisses jidoka could be considered muda, particularly if the users it is built for do not adopt it.

Amongst the topics presented, he spoke briefly on the differences between Agile and Lean. In a recent blog post, Richard compares Agile and Lean. Martin Fowler has also weighed into the conversation with his own ideas.

Richard also made reference to a couple of books during his presentation:
•    Learning to See by John Shook
•    The Toyota Way by Jeffrey Liker

I’d like to thank Richard for presenting at our last meeting and for making his presentation available, which can be found in PDF form. I want to wish him well on the rest of his world tour in which he will continue to present on Lean Thinking.