Continuous Integration Refcard

This week DZone publishes a new refcard on Continuous Integration patterns and anti-patterns. Paul Duvall of Stelligent, also co-author of Continuous Integration: Improving Software Quality and Reducing Risk, presents a set of tried and tested patterns that can help avoid the pitfalls of CI in the enterprise.

From the DZone website:

Continuous Integration is the process of building software with every change committed to a project’s version control repository. This DZone Refcard will walk you through 40 different Patterns and Anti-patterns associated with CI and expands the notion of CI to include concepts such as Deployment and Provisioning. The end result is learning whether you are capable of delivering working software with every source change.

One of the things I like about the DZone refcards is how much information they can pack in such a small package. Whenever I find myself looking for some piece of quick information it is always easy to reach to a refcard before picking up the big book. And the best feature? These puppies are free. I can’t believe DZone is not charging for this information.

Deployment Automation Webinar from XebiaLabs

The guys over at XebiaLabs are hosting a webinar on how to automate the deployment of J2EE applications down to a few mouse clicks.


Date: January 21th, 2010
Time: 10:00 AM EDT
16:00 PM CET
URL: http://www.xebialabs.com/do-you-want-deploy-your-enterprise-java-ee-applications-no-more-a-few-clicks

XebiaLabs provides the new generation intelligent deployment automation software solution for your mission critical applications. Deployit offers end to end deployment automation for IBM WebSphere,Oracle WebLogic, JBoss and Apache.

In this 45 minute webinar you will discover how system administrators and developers can speed up deployments, eliminate configuration errors and gain a complete overview and full control over the middleware environment.
Save costs, reduce errors and improve quality.

CI in a Box

Unless you’ve spent the last several years in a cocoon you have noticed the trend of everything IT-related moving to the cloud. It’s the new SOA. No, it is the new black. Whatever it is, it is creating a fertile environment for traditional tools and techniques to find new homes in the cloud. And it is cheap.

Here is a good example: Continuous Integration. Yes, it is that “box” in Bob’s office that spams your mailbox with stack traces every day. And yes, it is “easy” to stand-up. Of course after the equipment requisition form, the turf war, the operating system, the users, JDKs, the home and backup folders, the CI server software… you get the picture.

And that’s where the cloud shines. One can create and remove instances of pretty much any environment in (almost) an instant - cool! For an effective CI environment what’s needed is the prepackaging of a CI server and the backend wiring to the cloud. Using a tool such as CI in a Box dramatically shortens the time needed to stand-up a CI instance. Currently it uses Hudson, which also happens to be my server of choice, despite recent outages of hudson.dev.java.net.

Being fairly new, the CI in a Box website has good documentation to get anyone started, although a more detailed knowledge of the principles of CI may be required for effective project setup and management.

I am excited about this promising project and I’ll be following their updates in the weeks ahead.

Agile and Documentation

Someone asked a question about how an Agile book recommended bare minimum documentation and how the idea of the index cards as means of documentation felt a bit “weird”.

I couldn’t agree more. Index cards as the only or primary way for documentation is a recipe for disaster. The Agile manifesto, as outdated as it is, emphasizes working code over documentation. People have misinterpreted it repeatedly for minimal or no documentation. The latter takes away the power of things written down and agreed upon by everyone.

As a SCRUM Master and Agile coach, I manage multiple teams with 60-70 stories per iteration and 5-7 iterations per release. There is no way in the world that I, or anyone else on my team, will spend time digging a cabinet of index cards to find out about the details of a story that happened 3-4 months ago. It just won’t happen.

Instead, we’ve been gradually transitioning to using a modern WIKI, like Confluence to capture and manage requirements. Among other things, Confluence provides excellent traceability and version control through a very usable diff utility. Requirements and stories captured in Confluence are always current and open to the entire team. This includes people that may not be interested, aware or involved with the creation of index cards, but whose knowledge of the requirements is nevertheless critical for the success of the project. Combined with SCM labels and release notes, any person on the team is always 100% sure what’s in Production, what’s in Testing and what’s currently being developed.

Interaction Patterns: Tester finds bug!

Consider the following scenario, which probably happens hundred of times every day: Tester finds a bug! That’s great, or really bad, depending on where you look at it, but that’s not the focus of this blog entry. We’re interested in what happens next.

In the less-optimized team, the following sequence, with some variations, may start happening:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements document before I write the ticket.
4. Tester navigates to the root of the version-controlled documentation folder.
5. Tester is savvy, so she gets the latest documentation from the repository. This takes a while. She takes a coffee break.
6. Tester comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
7. Tester: Argh, this requirement document is a joke! Will these guys ever get it right?
8. Tester: It really does not say much about this thing, so I am going to write the ticket anyway. At least someone will take a look at it.
9. Analyst (next morning): QC found a bug, let’s triage it so it gets assigned to someone quickly.
10. Dev Manager: OK, let’s assign it to Developer.
11. Developer (after a day, two): Umm, something looks fishy…This might not be a bug.
12. Developer: Let me check the requirements document.
13. Developer navigates to the root of the version-controlled documentation folder.
14. Developer is savvy, so he gets the latest documentation from the repository. This takes a while. He takes a coffee break.
15. Developer comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
16. Developer: Argh, this requirement document is a joke! Will these guys ever get it right?
17. Developer: OK, here it is - says nothing about this thing. So, it is not a bug.
18. Developer: I am going to reject it and add the comment “Coded per requirements”.
19. Tester (next morning): My bug got rejected!
20. Dev Manager: Can three of you get together and talk?
21. Tester, Developer, Analyst (analysts’ desk, the next day): Let’s open the document.
22. Analyst navigates to the root of the version-controlled documentation folder.
23. Analyst is savvy, so she gets the latest documentation from the repository. This takes a while. All take a coffee break.
24. Everybody come back from the coffee break. Open the requirements document in Microsoft Word and look-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
25. Analyst: Is this the right version? I remember deleting these several lines.
26. Analyst: Let’s get version history. Yes, looks like it was updated six weeks ago. So, where are my changes?
27. Analyst: Oops, I forgot to export it from DOORS/ClearCase and check in to the version control system. What’s coded and tested is really not what the business needs right now.
28. Everybody: Rinse and repeat.

Does this ever happen in your project? I’ve seen it more often than I care to remember and despite that it seems trivial, changing behaviors takes time and perseverance.

What would a highly-effective team do in this situation? Let me attempt to construct an non-exhaustive list of things. This is just one way of achieving efficiency; there are probably infinite number of ways.

First, the team starts with a long-term vision and focus on people, practices and tools. Hire the best people, train them in cross-functional environments and create a reward structure which takes into account individual contributions in addition to team achievements.

Second, [over time] the team accumulated a list of practices and follows them.

Third, it uses tools that support the team practices.

So here is a version of the same sequence in a highly-efficient team, and somewhat shorter:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements WIKI page before I write the ticket.
4. Tester navigates to the root of team WIKI server. Performs a search and the requirements page comes-up first.
5. Tester: Himm, this requirement page has changed 134 times since last year. I wonder which one I am testing.
6. Tester performs another search, this time for the release notes. The search is based on the SCM label dropped to the QC environment. The release notes has an automatically-generated list of requirement numbers along with versions. Cool!
7. Tester: OK, so I am looking at the right version. Still, the requirement sounds ambiguous.
8. Tester chats with analyst in the hallway. Analyst stops by her desk and takes a read at the open WIKI page.
9. Analyst: Yes, this requirement stinks, I am sorry. Let’s edit it together here to add the clarification.
10. Analyst edits the page. Saves it in a new version with the comment: “Adding more clarity to BR:982. No coding required”. Analyst maks this as “Minor change”, so no new version of the page is created.
11. Tester: Thank you for the clarification. This is not a bug.

Now, does this happen in your project? Are there ways to optimize this even further? Probably yes.

What’s Test-Driven Development, anyway?

It still amuses me, after such a long time, to listen to people equating TDD to unit testing. But wait - in conversations and public forums, I’ve seen TDD and JUnit used interchangeably. Nothing wrong w/ the framework, of course. Plus, we know Kent Beck is working hard on v 4.7, so many new cool features are in the pipeline. But, whatever happened to the “other” tests - acceptance, functional, integration, database, performance, security and the myriad of special testing methods? From a value point, one can make the argument that automated acceptance tests are more effective in some cases than unit tests. Or, that functional tests can provide a better overall warm and fuzzy, if you need a little confidence before a release. Maybe, one [all-inclusive] test method is what we need to clear up the confusion

Agile 103: Continuous Integration and Agile Development

Compared to other disciplines, software engineering is still in its infancy and as such, it is undergoing significant transformations. This is a challenge because of the relentless innovation and ever changing standards; it is an opportunity because the low barriers of entry make it possible for virtually anyone with a computer to actively participate in the revolution and change course in significant ways.

Let’s take development methodologies for example. In the beginning of the century few people had heard of Agile development. Today, it is growing in popularity and adoption numbers suggest its value and effectiveness.

The Agile movement started largely out of necessity by looking at ways to increasing efficiency by reexamining the way people communicate and create software. The Agile model was explained as a collection of simple principles and practices. One of these practices is Continuous Integration (CI).

Continuous Integration (CI) is the practice of executing series of build steps in a scheduled or automated fashion. The build scripts may be run by a computer or a human; they can be automated or manual. The important thing is to run them often and provide the team with valuable feedback as soon as they need it.

CI can be defined as an umbrella practice enclosing sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the solution. Agile teams can rely not only on the time-saving nature of automated builds, but also on the timely and accurate feedback. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue or suspend further operation until the failure is taken care of.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage usually cause the CI cycle to fail and the system to notify the submitter or the entire team of the failure. Once the problems are fixed the CI server recompiles the source code and moves on to executing any Data Definition Language (DDL) and/or Data Manipulation Language (DML) scripts as part of the database integration step. This ensures the database gets synced with the source code and that any unit and functional tests that rely on the database changes execute properly. Depending on the server configuration unit test failures may or may not fail the CI cycle. If the application requires packaging and deployment, the CI server packages and deploys the archive into a container. After functional tests pass the CI server labels the source code with an automatically generated label. Finally, it generates a report of the integration cycle and notifies a list of recipients.

CI is an important practice for the Agile team. The CI system can provide feedback to all parties immediately after a problem is discovered. It can also generate valuable deployment artifacts and reports for various roles within the Agile team. Finally, the CI system brings teams closer to having the ability to plan faster and more frequent releases at the end of each iteration.

Agile 102: Continuous Integration Explained

One of the points in What is Continuous Integration (CI)? was the importance of having reliable automated build scripts and executing them often. CI can be seen as a natural extension of the Automated Builds practice since in most cases it relies on the presence of a set of ABS. A well-designed CI system encapsulates other sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the problem solution. Agile teams can rely not only on the time-saving nature of automated asynchronous builds, but also on the timely and accurate feedback as a result of this type of CI.

Continuous Integration (CI) is an umbrella practice enclosing a sequence of logically related steps. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue with the remaining steps or suspend any further operation until the failing step is fixed.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage will usually fail the CI cycle and the system will notify the submitter of the entire team of the failure. Once the problems are fixed the CI server will recompile and mode on to executing DDL and/or DML scripts as part of the database integration. This will ensure that the database will be up to date for the unit and functional tests that will follow. Assuming there are automated unit tests, the system will make sure to create test data and execute the unit tests in the suite. Depending on the server configuration unit test failures may or may not fail the CI cycle. In the next two steps the CI server will package and deploy the application. After all functional tests successfully pass, the CI server will label the code with an automatically generated label, it will notify a list of recipients and will generate a report of the integration cycle.

An Agile team can benefit from such a system in multiple ways. For one, the system can provide an immediate feedback to all parties shortly after a problem is discovered. Secondly, it can create valuable deployment artifacts and reports targeting different audiences within the Agile team.

One variation of the above diagram is if the CI server is configured to run code inspection tools as part of the CI cycle. Static analysis tools run from the CI server can generate reports on code metrics such as lines of code, test coverage, cyclomatic complexity, package coupling and dependencies, and can provide important data points for the entire team as to where the system stands in terms of code quality and architectural integrity.

A second variation of the diagram can happen when successful completion of the functional tests triggers a second deployment to another machine. Since the CI server knows it is a good build, this time it deploys to a user acceptance machine, targeting the customer directly. The advantage of redundant deploys is that semi-independent teams such the User Experience (UE) have a machine that always runs the latest good build.

Reference: This blog entry is derived from author’s own real-world experiences building CI systems and industry best practices. One of the leading sources for CI best practices is Addison-Wesley’s recently published Continuous Integration, a Martin Fowler Signature Series title, authored by Paul M. Duvall with Steve Matyas and Andy Glover.

ROI of Agile Development

Scott Sehlhorst at Tyner Blain has added an excellent article on ROI in Agile. Take a read!

Agile 101: What is Continuous Integration?

What is Continuous Integration (CI)?

Continuous Integration (CI) is the practice of periodically executing Automated Build Scripts (ABS), preferably in short intervals. There are two flavors of this practice. The first flavor, mostly applied by early XP practitioners states that the system is built by one developer at any given time. The teams have adopted various physical tokens signifying the builders’ "right of build". In this flavor of CI Automated Build Scripts are still required, albeit the kicking off the build happens manually. Since this version relies heavily on the entire team to be colocated, it does not scale well in distributed Agile projects.

The second flavor of CI relies on a computer background process to poll the code repository in short intervals and automatically trigger the build process if it detects any changes since the last build. In this version of CI, the developer is only responsible to build locally and check-in the code. This model is better suited for highly scalable Agile teams because of its reliance on automated asynchronous processes to trigger the build. This gives distributed teams an early feedback on the status of the system and therefore it enables dislocated team members and managers to have the same quick feedback as the team itself.