Chapter 4. Task-based development – Agile ALM: Lightweight tools and Agile strategies

Chapter 4. Task-based development

 

This chapter covers

  • Approaches and different tools for implementing task-based development
  • Lightweight tools for planning and tracking tasks
  • Example toolchains, including JIRA/GreenHopper, Bamboo, Eclipse, FishEye, Mylyn, Trac, for planning and tracking tasks

 

Traditionally, work items (or tasks) are spread across artifact types and tools. Tasks are an abstraction level for coping with the general information overload and the challenges of parsing information from many different sources. A task is a fine-grained, measurable unit of work, extracted from a broader scope, like a use case or a feature. Leffingwell states “for more detailed tracking of the activities involved in delivering stories, teams typically decompose stories into tasks that must be accomplished by individual team members in order to complete the story.”[1]

1 Dean Leffingwell, Agile Software Requirements (Addison-Wesley, 2011), pg. 38.

With a task-based (or task-focused) approach, the task is the unit of interaction and the base of work. Task-based development is the technique of linking work items (issues, defects, tasks, and so on) to the specific set of changes (such as an atomic changeset) made to complete the work described in the work item. For example, if you’re fixing a defect that’s listed as defect 4711 in JIRA, task-based development requires that you link the exact set of changes to defect 4711 in JIRA.

Task-based development is powerful and significantly improves your productivity by making it easy to track changes to the approved change request that authorized the modification. Working in a task-based way, the functional and technical consistency of releases is improved.

This chapter will examine task-based development by providing numerous compelling examples. Tools aggregate knowledge and improve traceability and visibility. They aggregate content and provide views to improve the release process. I will describe toolchains consisting of JIRA/GreenHopper, Bamboo, Eclipse, FishEye, Mylyn, and a product called Trac, which provides much of the same functionality. You might be using a different set of tools in your organization, but you’ll likely find that the functionality described is similar.

First, let’s discuss a few basic prerequisites that are commonly found in task-based development.

4.1. Prerequisites for task-based development

Every set of changes should be documented with a brief comment that explains the reason for the change when you check changes into the VCS. I recommend that you use change comments to explain why you made the changes to the code base. Merely describing what you have done doesn’t usually add any value. For example, comments such as “checked changes in” aren’t helpful; “fixed defect #136—date calculation error” is more useful.

In Agile, it’s also essential that you commit your changes frequently so that you’re continuously integrating your code. Before you commit your changes, always refresh your sandbox to ensure that your changes won’t break the build for someone else. Basic quality gates are also important for analyzing static code, testing, and ensuring that the code can successfully compile.

There’s more, but these are the basics we’ll focus on now. Here are more details about the practices.

4.1.1. Coordinating changes

Task-based development is valuable when you’re coordinating the changes of a large team of developers who may be located in one place or distributed across several locations. Managing the changes of a group involves handling complex dependencies, and it demonstrates the value of continuous integration.

For example, suppose you want to commit your changes to the Subversion (SVN) repository. Before you do so, you should update your sandbox (your workspace) with incoming changes. Afterward, you need to ensure that your classes compile and your tests run successfully (including all of the required quality gates, such as static code analysis). Other developers are also refreshing their sandboxes and committing their changes to the repository at the same time. Each commit causes the Subversion repository revision number to be incremented by one and the changes to be documented in the log.

Once all specified features are implemented, the release is finished, and the changes from each member of the team are successfully integrated, one developer (often the lead developer) should tag the revision of the code, which creates a baseline. This is often done in the code freeze phase, as you learned in the previous chapter. Some teams use branches to help organize their work (especially when they’re close to a release). Your colleagues can always see what you have changed, and by browsing the changelog, they can see the set of changes that was committed to fix a particular bug or implement a feature.

You should commit your changes to the VCS often and continuously. A general rule of thumb is to synchronize with the central repository and commit your own changes at least twice a day, perhaps in the morning and evening. This doesn’t mean you must close tickets in your bug tracking system twice a day. Instead, tasks can be updated and be “in progress.” Therefore, one task could lead to multiple check-ins, although one commit for one small-grained task is even better.

The VCS system should be used to track different changes as frequently as possible. Additionally, issue management systems should track tasks with different changes; one task could be related to several changesets (check-ins), and each changeset could link to several files. But keep in mind that your commits should be aligned to tasks, so you need to slice your tasks accordingly. Fine-grained, focused tasks will give you greater confidence and are easier to track. If tasks take days or weeks to implement, they’re too coarse-grained and the approach definitely needs to be improved.

4.1.2. Using changesets

Modifications that are dependent on each other because they implement the same task should be grouped in one atomic VCS commit. This enables the VCS and other tools that connect to the VCS (like an IDE) to track these changes as a single changeset.

Matthew B. Doar states that a changeset is “a group of related changes to a set of files; the changes are applied all together or not at all.”[2] This changeset can be propagated as needed and contains all the modifications that lead to a new revision in the VCS. On the other hand, by doing atomic, bulk commits aligned with tasks (rather than committing separate, single files), you assign one change commit to the full batch. This allows you and others to track the impacts and results much better. Change-sets allow a technical view on an entire group of changes.

2 Matthew B. Doar, Practical Development Environments (O’Reilly, 2005), pg. 42.

Allow me to provide an example: You’re working on a bug fix that requires you to modify a couple of files. After you finish your work, you commit the changeset to a VCS (for example, Subversion). In Subversion, this single transactional commit will increase the revision number by one. Your colleagues can see what you have changed and, by browsing the change log, they can confirm that these changes belong together. You (and others) can easily reproduce the different software versions—the one version from before the changes and the resulting one after applying them. By accessing the Subversion revision number, you can do this even without using Subversion tags.

If you use a VCS that doesn’t handle commits in a transactional way, such as Concurrent Versions System (CVS), mistakes or problems can occur because of incomplete transactions. Consider using a continuous integration infrastructure where a new build is triggered after a developer commits changes in order to integrate the change-sets with the central repository and with the work of your peers. You can also use the task management system (for example, JIRA) to trigger an integration build. For instance, when the task is marked as complete, continuous integration will trigger the build and related testing.

After a commit occurs, the build server often has to wait several intervals (or a specific scheduled time) to start the build. If you don’t commit the changes all in one step, you may kick off a new build that’s based on an inconsistent state.

4.1.3. Associating changesets with tasks

The next important step is to associate every changeset with a specific task and indicate the task number (for example, defect 136) in the comment that you enter when you commit the changeset. (Task here means a ticket in the ticketing system, such as JIRA or Trac.)

By associating changesets with tasks, the tasks (change requests, new features, or bugs) are traceable through the system. Many tool integrations make this connection a two-way function that automatically tracks the changesets to the defect number that authorized the changes. This means that you can look up the defect in JIRA and see the revision number of the changesets that implemented the bug fix. You can also see the defect number in Subversion that explains why the changeset was committed. This two-way traceability improves quality and productivity.

If this all sounds complicated, it is. But it’s more complicated, even impossible, to track without task-based development! These different aspects of enabling task-based development, coordinating changes, using changesets, and associating changesets to tasks, are important considerations, and I’ll soon explain how to implement an example solution. Right now, though, let’s consider a high-level solution from a logical point of view.

 

Commit Messages and VCS Hooks

Task-based development is enabled by using a special commit message that references the task identifier. You can make referencing the ticket numbers in check-in messages mandatory by using VCS hooks.

 

Figure 4.1 shows what a high-level solution looks like, from a logical point of view (without any specific tools). The system infrastructure contains a ticket system, where you manage your tasks (work items, requirements, bugs, features, and tasks).

Figure 4.1. The Agile ALM infrastructure: the unique ticket number of a task connects the different participants (nodes) in the system. This results in traceability and transparency, and it ensures the alignment of activities with specific requirements.

The developers use an IDE to update tasks in the ticket system with (specific context) information. Developers can update the tickets in the ticketing system (which tracks the changes on the task description) without leaving their development workspace and tools. This information is distributed to other developers who are working on these tasks too. Their workspaces are aligned with tasks and artifacts, which are necessary to accomplish the specific task.

Code sources are managed with a VCS. The developers share their code via the VCS and perform update (pull changes) and commit (put changes) operations on the code base. In order to work in a task-based way, they add the ticket number to their commit messages.

A central continuous integration server pulls the source code and builds the software. By referencing the ticket number to the changes, the build server can retrieve this meta-information from the VCS, and reference the changes to the build artifacts.

Consequently, the Agile ALM system delivers information about which artifacts contain what features or bug fixes (which tasks motivated changes on these artifacts) and which tasks are solved by working on which artifacts. This is called traceability, and it ensures the alignment of activities with concrete requirements.

The ticketing system allows you to manage requirements (such as bugs, features, and tasks) from a logical point of view. This helps facilitate the Agile business view of the development process. The developers may also be using an IDE that has a plug-in installed to allow easy access to the information in the ticketing system. Workspaces should be created and aligned to organize the work in a logical way (using Eclipse, you can use working sets to logically group the artifacts in your workspace) whereas the code is managed in the VCS (such as Subversion). This approach provides traceability, improving both productivity and quality.

In the next two sections, we’ll look at how to implement task-based development using two different toolchains. The first uses JIRA/GreenHopper, Bamboo, and Fish-Eye with Mylyn.

4.2. Our first toolchain—JIRA, FishEye, Bamboo, and Mylyn

In this and the next section, we’ll look at how to implement task-based development using two different toolchains. The first toolchain, discussed in this section, is based on the commercial tools JIRA/GreenHopper, Bamboo, and FishEye. The second tool-chain is primarily based on Trac, which is an enhanced wiki and issue-tracking system for software development projects—it’s covered in section 4.3. Regardless of which toolchain you use, you can add a product known as Mylyn, which is a task framework for Eclipse. Both toolchains can (and should) be integrated with a continuous integration server.

Remember what we discussed in chapter 1. Your tool infrastructure should be flexible and open to changes. If you feel more comfortable with different tools in your toolchains, you can replace them with your favorites, keeping the rest of your tool-chain unchanged. Other toolchains are possible by integrating different tools of the same tool types. For instance, if you prefer Jenkins over Bamboo, you can easily replace that one specific tool in the overall chain either during initial setup or at any time later.

JIRA (and its plug-in GreenHopper), FishEye, and Bamboo are commercial products developed by Atlassian.[3] These lightweight tools span different phases of the development process, including requirements engineering, development, and delivery. Different project roles gain benefit from this highly integrated toolchain:

3 See www.atlassian.com to find comprehensive online documentation for installing and configuring these tools.

  • The team (developers and testers), project managers, and product owners can use JIRA to manage the requirements and to align their work with those requirements.
  • Developers can access the tasks from within their IDEs with Mylyn.
  • The team can use Bamboo for CI, and developers can use it to start builds from within their IDEs.
  • The team, project managers, and product owners can use FishEye to track source changes, providing real-time notifications of code changes plus web-based reporting, visualization, searching, and code sharing.
  • The team can track changes by ticket. This means the team is aware of which tickets were completed in specific builds (via Bamboo and FishEye), which sources were modified to complete a specific ticket (via JIRA and its connection to FishEye/Subversion), and which tasks they should work on (via Eclipse and Mylyn). Because developers have all this information at their fingertips, the approach is often also described as developer-centric.

These tools are lightweight (and inexpensive) but they still provide full tracking of tasks to changesets, which is the main point of task-based development. This toolchain is illustrated in figure 4.2.

Figure 4.2. This toolchain enables task-based development. It’s based on JIRA, FishEye, Subversion, Bamboo, Eclipse, and Mylyn. Requirements are managed with JIRA. GreenHopper enriches JIRA with further features for Agile development. The CI server pulls sources from the VCS to build the software. FishEye is a convenient VCS browser that makes changes visible in a convenient way. Both Bamboo and FishEye are integrated with JIRA. Developers use Eclipse with Mylyn to work on code; they access code with Eclipse and the plug-in that’s available to connect to the VCS that’s used.

As you already know, the ticket system contains your tasks. In this specific solution, JIRA is the ticket system, and its GreenHopper plug-in enables JIRA to support Agile development. Developers use Mylyn to access JIRA tasks directly from within the Eclipse IDE to work in a task-based way. The sources are managed in a VCS, which in this case is Subversion. FishEye monitors code changes in the VCS, and the FishEye integration allows you to browse your source-control repository from inside JIRA. Bamboo, as the CI server, provides build information and makes it visible inside JIRA, as part of the ticket.

Let’s take a deeper look at these tools.

4.2.1. Managing tasks with JIRA

JIRA is most commonly used for issue tracking, but it can also help with project and release management. You can configure JIRA for your needs. For example, you can configure your own workflows (transition rules), and you can modify issues so they contain information about bugs, enhancements, requirements, or a customized work item. You can configure JIRA to track different change types that contain different information. As a result, JIRA can also be used for tracking requirements and tasks, which makes it appealing.

JIRA can be integrated with a VCS, like Subversion. JIRA displays all changes in Subversion with their respective commit messages, including the JIRA ticket number. Besides its powerful configurable features, it also has an extensible open architecture. There are plug-ins that you can easily add to the system, and you can also write your own plug-ins using the documented API.

Some of JIRA’s main features include the following:

  • Release management support (roadmaps, versions, milestones)
  • Ticketing system
  • Fine-grained permission system, Lightweight Directory Access Protocol (LDAP) support
  • Open for integration with Atlassian Confluence wiki, Atlassian Bamboo, and other Atlassian products like Crucible
  • Multiproject support
  • Extensibility and configurability (for reporting, issue types, features, and so on)
  • Feature-rich approach enabling Agile development
  • A configurable state machine (a workflow engine) for handling issue transitions
  • Support for task-based development
  • Support for Agile processes, including burn-down charts and cards (via Green-Hopper)

 

Bug-Tracking Tool = Process Smell?

Some teams track defects separately from other tasks, and some teams treat a defect the same as any other work item. Many mature Agile teams call the existence of a bug-tracking tool a process smell. Other teams have such a severe problem with legacy code that they need a bug-tracking tool to find a practical starting point to improve their code base. The choice of tools will depend on local conditions and on how the team operates. JIRA’s advantage is that you can track all the different types of changes, including bugs and tasks. You can customize JIRA to hold issues of type task and bugs in parallel, making JIRA more a task-tracking tool.

 

GreenHopper is an optional JIRA plug-in that improves JIRA’s ability to prioritize and visualize priorities, and it thereby empowers JIRA to support Agile project management. To that end, GreenHopper introduces cards that can be assigned to issue types and target releases. GreenHopper also adds burn-down charts to JIRA, visualizing progress through the release. Installing GreenHopper into a running JIRA instance is easy. In newer versions of JIRA, you can install the plug-in through JIRA’s admin screen.

 

Code Reviews with Crucible

Crucible is Atlassian’s tool for reviewing work as a continuous process. Crucible enables code review and is highly integrated with JIRA, supporting Subversion, Git, and other VCSs. One common use case for Crucible is to provide a workflow that transitions a ticket from Open to Under Review to Resolved. Another scenario is a postcommit review, done automatically after code changes are checked in.

 

After you have completed the well-documented JIRA installation process, you’ll have JIRA running on your machine on port 8080, which is the default. After you’ve started JIRA, you can create and work on tickets.[4] The ticket overview shows all relevant information belonging to one ticket, including the component the ticket belongs to and the affected and target versions, as can be seen in figure 4.3.

4 For further discussion of how to set up roles and permissions, please consult the documentation.

Figure 4.3. The ticket AGILEALM-4 is of type New Feature and is linked to three subtasks.

On the right side of the screen, the ticket reporter is listed as well as the current assignee. You can assign other people to continue the work on that issue. Voting for a ticket is a nice feature: You can vote on tickets to express the importance of the ticket and the team can determine how many developers consider the ticket important. You can watch a ticket and its progress to keep informed of ongoing activities. You’ll automatically get emails advising of any changes to tickets you’re watching. The right panel also includes information about when the ticket was created and last updated.

The upper panel of buttons provides functions for working on this ticket, such as editing the attribute of the ticket (the type of the ticket, for instance), commenting on the ticket, indicating that you’ve started work on the ticket, or assigning others to work on the ticket.

Being assigned to work on one ticket doesn’t automatically mean that you’ve started the task. If you work on the item, you can document that by using the start progress feature. This way, the amount of time you spend working on that ticket is recorded. Furthermore, the ticket is added to the in progress list, which can be displayed on the dashboard. After completing work on an issue, you can resolve it. The possible transition states are also configurable.

The main middle section of the page identifies attributes of the ticket that were entered when the ticket was created, such as the issue type or the ticket’s priority, as well as status information.

By configuring JIRA, you can work on personalized items and attach your own custom fields to the ticket, your own issue types, your own priorities, and so on. You can also configure dependencies of tickets, such as relationships between them. One common example is configuring a ticket to be a subtask of another ticket. In the example in figure 4.3, the ticket with the unique identifier AGILEALM-4 identifies a feature that was sliced into three subtasks. One subtask is already implemented and closed; two others are still open and still must be implemented.

 

Integrating Confluence wiki

Atlassian also provides an enterprise wiki called Confluence. You can integrate Confluence in different ways. An easy way to integrate JIRA with Confluence is to link from Confluence to JIRA with the combination of Confluence shortcuts and JIRA’s quick search.

In Confluence, you can create a shortcut for JIRA and use it inside your Confluence page with [ALM-1@JIRA] to reference the ticket in JIRA. You can also use the {jiraissues} and {jiraportlet} macros to embed JIRA reports and portlets into your Confluence site.

Another scenario is to integrate Confluence project documentation into a build. In this use case, you maintain project documentation with Confluence. Then, in the automatic release process of your software, you export static HTML out of Confluence. This can be done with Maven in its assembly phase, for example. (Technically, you create a zip file after calling wget via Ant execution.) This is embedded in the Assembly Plugin for Maven.

A third integration scenario is quite different: pushing content to the Confluence wiki after a build is created. In this case, wiki content is created and uploaded in Confluence’s xmlrpc interface. One solution is to use Maven and its Confluence plug-in.

 

Another way to organize your work is to create target versions of your software. Tickets can be assigned to target versions in JIRA, and these JIRA versions map to releases (or iterations) in your development process. You define a JIRA version with a version ID (for example, “1.0” or “Important-0.1”), a description, and a release date. By using a schedule, you can define its position in the list of existing versions. A roadmap collects a list of upcoming versions.

You can monitor the development progress in different ways. One way is to use charts of newly created and closed tickets, or you can use GreenHopper’s burn-down charts. In addition to the burn-down chart, GreenHopper adds planning and tracking facilities to the system to help with Agile development. Figure 4.4 shows the planning board for planning and tracking issues.

Figure 4.4. GreenHopper’s planning board: Visualizing tickets as cards enables you to create new ones or change their status. Cards can be filtered to show only cards that are open or only your tickets. The GreenHopper view also visualizes target versions and uses different icons to express information such as priorities.

Instead of the linear, text-based JIRA approach, you can simulate working with cards, with a card being like a traditional JIRA ticket. The planning board can be opened via the Agile menu at the top of the JIRA screen. Here, you can create new cards and modify existing ones. You also can change the target version of cards by dragging them to a different area on the display. For instance, a card that was assigned to be part of version 1.0 can be assigned to be unscheduled by dragging the card to the Unscheduled area on the page. A transition rule must exist to perform that operation, and you can set up transition rules as part of JIRA’s state/workflow system.

Requests for developing a bug fix or a new feature lead to tasks. You’ll have different configuration settings, like priorities, but a good approach is to manage all tasks similarly. That’s why it’s named “task-based development” and not “development based on feature requests” or “development based on bug fixes.” For the same reason, JIRA talks about tickets as its coarse-grained working unit. On this level, a JIRA ticket can be compared to a task in “task-based development.”

Going deeper, it’s wise to distinguish between types of tasks (and tickets) by dividing and organizing the work into more granular tasks, in a processes that has become known as slicing. For example, suppose you’re documenting the software requirements in the ticket type requirement (JIRA allows you to configure the ticket types and relationships) or in user stories or use cases,[5] whichever is most appropriate in your context. These tickets have relationships to tickets of type task. In these tasks, the features are documented technically, but at a high level. Tasks have subtasks that contain the specific technical tasks to be implemented. Subtasks are a way to break down high-level tasks into smaller units to be estimated and rolled up into the larger estimate.

5 For slicing user stories, see Mike Cohn, User Stories Applied (Addison-Wesley, 2004). For slicing use cases, see Alistair Cockburn, Writing Effective Use Cases (Addison-Wesley, 2001).

Another way to slice the items is to use features (describing the high-level functionality), stories (special use cases), and tasks (the technical face).

4.2.2. Working on tasks with Eclipse and Mylyn

The IDE is the place where developers implement the requirements. We’re using Eclipse in this toolchain, and we can add further Eclipse plug-ins to this Eclipse configuration to access the VCS. In this toolchain, we want to connect to a Subversion repository. The Subclipse plug-in is a good choice for interacting with the repository, and you can install it via the Eclipse update manager.

Mylyn is an Eclipse-based task framework. It can integrate with ticket and bug-tracking tools such as JIRA, Bugzilla, Trac, and Mantis. After installing Mylyn with the appropriate ticket system connector for JIRA, and configuring it to connect to your task repository by providing the URL and credentials to login, an additional view is added to Eclipse, showing all tasks matching your search criteria, as shown in figure 4.5. Once your tasks are integrated, Mylyn monitors your work activities and synchronizes with the ticket system automatically. You can reference parts of the sources you’re working on in Eclipse as the context of a task. This context can be attached to the task or even posted as an attachment to the ticket.

Figure 4.5. Mylyn adds a task-based view in Eclipse. In the Eclipse task view, important information about the tasks (such as issue type, status and priorities) are shown directly, but double-clicking will open the complete ticket in your Eclipse editor. Tickets can be grouped by relationships of subtasks. In the left area, incoming and outgoing changes made by you or other developers are identified with icons. Unread tickets—tickets that haven’t been opened yet—are identified with a question mark.

 

Note

Other IDEs support an ALM approach too. IntelliJ IDEA from Jet-Brains, for example, can integrate with task repositories, including Atlas-sian’s JIRA.

 

One developer can import into their workbench a context that has been provided by another developer. This helps to standardize views. You can easily switch tasks in Eclipse, getting individual views on the sources. Tasks in your workspace are updated automatically.

These are Mylyn’s main features:

  • Mylyn accesses and integrates with your task tracker. The integration is in both directions: You import and read tasks in your workspace, and you update and create items in your workspace.
  • Mylyn supports filtering, sorting, highlighting, and folding. You can query your tracker for tasks, you can update tasks, you can see change notifications in Eclipse, and you can use contexts to slice and group your sources according to tasks. You can also activate tasks to indicate that you’re working on them.
  • Mylyn integrates with VCS changesets. A changeset can be linked to a task. A changeset can be checked in as a single atomic transaction.
  • Mylyn integrates with build servers, for instance, Hudson/Jenkins.
  • Mylyn supports activating tasks. Activating a task removes all those files from the IDE view that are unnecessary to complete the activated task. The workspace and its visible files are aligned with the task.
  • Mylyn supports attaching context information to a task and uploading this context information to the ticket in the bug tracker.
  • Mylyn allows working offline: Locally cached tasks can still be maintained although the central task tracker is not reachable. Changes to tasks can be synchronized with the task tracker when the network is available again.
  • Mylyn is part of the Eclipse standard distribution.
  • Mylyn enables task scheduling.
  • In addition to Java, Mylyn has extended its support to C/C++, PHP, and Spring Framework–powered enterprise Java applications.
  • Additional commercial features are provided by Tasktop (see www.tasktop.com). The commercial product extends task focus to time tracking, web browsing, and desktop documents, and it includes other connectors to integrate with more tools.

Mylyn subprojects include the following:

  • Tasks for integrating task and change management
  • SCM for integrating source code management
  • Build for integrating build management and continuous integration
  • Review for collaborative code review

Mylyn has evolved into a unified platform for ALM and ALM vendors. Mylyn embraces the Open Services for Lifecycle Collaboration (OSLC) standards for ALM.

 

Agile Planner Leverages Mylyn Connectors

Tasktop provides a tool called Agile Planner. This tool can manage existing defect and project management systems directly from Eclipse, making it effortless to maintain project status awareness and keep plans up to date. Agile Planner supports planning across multiple vendors’ solutions. For more details, see http://tasktop.com/connectors/agile.php.

 

The developer checks in the code changes to the Subversion repository. In the commit dialog box, the developer extends the commit message (which describes what he has done) with the ticket number. In our case, based on figure 4.6, adding AGILEALM-10 provides the information to JIRA and Bamboo to link this change to the ticket.

Figure 4.6. Committing changes to VCS in Eclipse. In the commit dialog box, developers add a reference to the tickets they’ve worked on. In this case, the ticket AGILEALM-10 motivated the code changes that are committed now.

4.2.3. Tracking source changes with FishEye

Atlassian’s FishEye is an advanced source code repository browser. You can view the content of the repository and any changes applied to it. FishEye’s features are the following:

  • FishEye lets you view user activity and track code changes.
  • FishEye enables you to search and navigate through the repository.
  • FishEye supports Subversion, CVS, Git, ClearCase, and others, with real-time notifications of changes plus web-based reporting.
  • FishEye identifies diffs between versions.
  • FishEye provides a web application for convenient browsing of the repository (see figure 4.7).
    Figure 4.7. The FishEye web application: browsing the repository. Changes (activities) are displayed in a timeline. Revisions with their changes (for instance, how many lines were added) are visualized and can be compared with each other. You can zoom in to see the respective versions of the sources.

  • FishEye enables you to view multiple communication channels, including JIRA issues, Bamboo builds, email alerts, and IDE. This means, you can gain Bamboo’s build information from within a couple of tools in a highly integrated manner.

FishEye is a web application that continuously scans the repository. The browser acts in two different ways: It allows you to see which tasks are associated with specific changes, and it allows you to browse the VCS, with its content, and browse the changes of single files. Figure 4.8 shows the FishEye integration with JIRA, illustrating the history of VCS changes referencing this ticket. Important information is displayed: who made the change and what was changed.

Figure 4.8. FishEye integrated into JIRA: A dedicated tab shows source changes associated with each ticket. One Subversion commit resulted in this entry: 1 file was changed, 15 lines were added in the file, and 2 were removed. Icons provide links to FishEye so you can zoom in if you’re interested in more information.

After installing the FishEye plug-in in JIRA, a Source tab is added to every JIRA ticket. There, you can see changes associated with each ticket and diffs in a convenient way. The example in figure 4.8 illustrates that changeset 37 in Subversion was triggered by me, and it contains changes in one file. You can browse the file, create version diffs, and so on. The main benefit is that people can trace changes and reference them to tickets, which allows impact analysis. This means you can monitor developers’ changes and their consequences on tickets. Also tech leads or senior developers or the team can closely look at commits and what effect they have had on the codebase.

Further integrations are available, such as a plug-in that integrates FishEye functionality into Eclipse.

Creating and updating tasks in JIRA was the first step. Next, you’ll view the tasks and work on them from within your IDE. Then you’ll build the software and associate the builds with the tasks created.

4.2.4. Build view with Bamboo

Bamboo is a continuous integration server that automates your software builds. You can create your own build plans to create your software on a scheduled basis (with Ant or Maven, for example), or a developer’s check-in can trigger it. Key features of Bamboo include monitoring build progress, deploying steps, and reviewing the results of static code analysis. Together with JIRA, development activity can be monitored. Bamboo helps to bridge the development phase with delivery and testing.

Continuous integration servers like Bamboo (or CruiseControl, Hudson/Jenkins, TeamCity) support continuous integration and facilitate rapid application development. When used together as a toolchain, Bamboo and JIRA help to do the following:

  • Track builds to tasks
  • Monitor progress and success on working on tasks
  • Trace issues fixed to a specific build

 

Build Comparison and Change Tracking

One major feature Bamboo offers (as do other continuous integration servers) is verbose build comparison. Efficient comparison of different builds (of the same software) delivers answers to questions like “What changes went into the build that might have caused a previously working feature to fail (regression)?” or “What caused the latest build to fail?” Linking a build server to the ticketing system adds even more value. For example, it can answer questions like “What changes does the new release deliver?” or “What problems are fixed for a customer if they upgrade to a new build?”

 

Bamboo can be integrated with different tools. For JIRA, it can be implemented as a plug-in, or as a separate application that’s accessible via a web interface. It can also be integrated into Eclipse by installing the Atlassian Connector for Eclipse. In a dedicated Eclipse view, you can trigger builds from your workspace, monitor builds, or comment on builds.

 

JIRA and Hudson/Jenkins

If you’re using Hudson or Jenkins as a continuous integration server (instead of Bamboo), you can use a plug-in to integrate either of them with JIRA. The plug-ins can be installed via the administration panel.

 

Connecting JIRA and Bamboo adds an additional Bamboo Builds tab to all of your tickets. In this tab, you’ll see all builds referencing this ticket. Figure 4.9 shows that the Bamboo build number 12 provided changes that are responsible for fixing the task AGILEALM-10. You’ll also see further information, such as who did the commit that references this ticket and triggered the build, how long the build ran, how many tests passed, and so on. Again, you can zoom in and navigate to Bamboo itself if you’re interested in further information, such as by clicking the #12 link, which leads directly to the build detail page in Bamboo.

Figure 4.9. Bamboo integration in JIRA: builds associated with this ticket. If you’re interested in more information, you can easily navigate to the Bamboo web application by clicking a link.

By using the Bamboo web application, you can gain a lot more information about your builds (see figure 4.10). You can enter the application by using links in Eclipse or JIRA or by entering the start URL and navigating from there.

Figure 4.10. The build result summary of the Bamboo web application. The summary page shows details about the build, such as why the build was triggered and what changes were newly integrated with this build. A history feature and further tabs allow you to navigate through builds and to zoom in to respective test results, generated artifacts, logs, and so on. Besides its continuous integration and build server features, it links to issues in the ticketing system.

 

In the cloud: JIRA Studio with a commit-driven approach

Atlassian offers a full, commercial toolchain named JIRA Studio (www.atlassian.com/hosted/studio/). This hosted and integrated toolchain includes Subversion, JIRA, GreenHopper, Confluence, FishEye, and Bamboo. This toolchain eliminates the installation effort and reduces administration efforts. Integrating the tools yourself will cost you some time, but you would have the advantage of configuring the toolchain in a way that meets your specific requirements.

JIRA Studio also supports interacting with JIRA via commit messages. For example, to add something like “MYPROJ-4711 #time 4h #comment ALM #resolve” to your commit message to log four hours of work against issue MYPROJ-4711, add the comment “ALM” to trigger the state transition of the ticket in JIRA, from open to resolved, finally resolving the issue.

Other comparable tool suites are also available—for instance, ScrumWorks (www.danube.com/scrumworks) and codeBeamer (www.intland.com/products/cb/overview.html).

 

The official Bamboo documentation explains all the product features in detail, including how to configure and retrieve information about your tests and changes, how to add artifacts to your build plan, and so on. The documentation also explains all the result views provided by Bamboo. Of special interest here is the Issues tab on the Build Result Page. Once you have correctly integrated JIRA and Bamboo, you’ll see the issues fixed or referenced in the build.

Another way to closely integrate Bamboo with JIRA is to use the Bamboo Release Management plug-in (https://plugins.atlassian.com/plugin/details/28559). This plug-in triggers different actions in one step, including running a release build, publishing artifacts, tagging a version in the VCS, releasing a version in JIRA, creating a branch for the next version in the VCS, and switching the build to use a new branch.

Bamboo supports even more features for task-based development, and for release management in general: It offers a pipeline feature—a pipeline is composed of stages that contain several subplans. Subplans are like Bamboo plans except they don’t have dependencies and notifications, and they can’t be run manually. In order for a pipeline to transition from one stage to another, all subplans in the current stage must pass successfully. For the pipeline to complete successfully, all subplans in all stages must pass successfully. The pipeline can pass artifacts between stages so that builds in later stages can consume previously built artifacts produced in the same pipeline. Additionally, there is functionality to promote artifacts.

4.3. Trac bug tracking and project management

Trac (http://trac.edgewall.org) is an open source tool developed and maintained by Edgewall Software. Trac is a mixture of a release management and bug-tracking tool as well as a wiki and version-control browser. Trac provides a comprehensive tool to help teams get started with software development. Although it doesn’t dictate any special development process to your team, it can be configured to be used in an Agile context. A toolchain for task-based development based on Trac is illustrated in figure 4.11.

Figure 4.11. A system for task-based development, based on Trac. Trac is the ticket system that integrates with the VCS and CI. Eclipse and Mylyn are used on developers’ desktops. This example shows Hudson/Jenkins being used as the CI server.

 

Note

In the discussion of this Trac toolchain, I won’t repeat previous discussions of aspects like build server integration or Eclipse with Mylyn. They are only suggested and mentioned as nodes in the overall toolchain here, because you already know about them from our first toolchain. In this section, we’ll discuss new aspects that haven’t been mentioned so far, such as the wiki. As a consequence, you can easily include the Atlassian Confluence wiki in the first toolchain to profit from a wiki there, or you can easily integrate a build server like Hudson/Jenkins into this second toolchain in order to link builds to tickets. Remember, driving lightweight toolchains is also about being flexible, adapting to changes, and being able to replace single tools in the overall toolchain without touching the remaining tools.

 

Trac is a lightweight system that allows Agile planning of projects. Developers use Mylyn to enrich their IDEs (figure 4.5 shows how this can look). Trac connects to a VCS (in our case, Subversion). It allows you to browse source changes and track other changes in the complete system (such as wiki changes). Trac contains its own wiki and can be integrated with a continuous integration server (such as Hudson/Jenkins; section 4.2 discusses what traceability on the build server can look like). Trac uses its wiki markup to semantically link the version-control repository, the wiki, and the issue tracker and to glue wiki pages, changesets, and tickets to each other. Trac’s timeline view shows recent activities in all those areas.

Trac is written in Python, and it’s available for different platforms such as Windows and Linux derivatives. It can be both extended and configured. Trac’s main features include the following:

  • Release management support (roadmaps, milestones)
  • Ticket system
  • Timeline of all recent activities
  • Fine-grained permission system
  • Wiki, with wiki markup
  • Customized reporting
  • Web interface for Subversion, including changeset support
  • Multiproject support
  • Minimalistic approach enabling Agile development
  • Plug-ins like the Agile-Trac[6] plug-in to further support Agile development and to add further features to Trac, such as iterations

    6 See the Agile-Trac plug-in page: http://trac-hacks.org/wiki/AgileTracPlugin.

  • Support for task-based development

4.3.1. Installing Trac

To install Trac, you must install a couple of required libraries. Using a prebuilt package provided by BitNami makes it easier (available at http://bitnami.org/stack/trac).

 

Redmine

The Redmine tool is comparable to Trac. Redmine is based on Ruby on Rails. Its feature set is equal to Trac’s, and it can be installed via BitNami as well.

 

BitNami makes it easy to use and deploy Trac by providing native installers for Windows, Linux, and Mac OS X. Each installer contains all the necessary components to run out of the box. The installed Trac configuration is self-contained and doesn’t interfere with other software on your system. After downloading the installer and running it, a wizard guides you through the process. You can also let the wizard create a Trac project for you, which is a space inside your installation that you can use for your release work. The installation takes only a few minutes and installs the following components on your system:

  • Apache 2
  • Python
  • Subversion
  • SQLite
  • Trac and its required dependencies

 

Native installer, virtual images, and Amazon EC2

Besides the normal Trac stack (and other full-packaged open source tools), BitNami also provides two different distribution formats: virtual machine images and cloud.

The virtual machine image contains a Linux operating system and the fully configured Trac installation. Running the image requires a virtualization host such as VMWare or VirtualBox.

The cloud approach is an image that can be run in the cloud, namely Amazon EC2. You can run BitNami applications on EC2 on a pay-as-you-go basis, programmatically starting and stopping them.

 

After your package is installed, you may want to configure it for your specific needs. The central point for that is the trac.ini executable installed in the same place as Trac. Here you can configure the Subversion repository you want to use, the layout, and the behavior of the Trac components, such as the wiki, the ticketing system, and the timeline.

Let’s look a bit deeper into some of these features. Assuming Trac is running on port 8010 on your central server, you’ll see a screen like the one shown in figure 4.12.

Figure 4.12. The start page of Trac: the edited wiki entry page, including access to the timeline, roadmap, source browser, and ticket viewer

Let’s go through the main points of interest, including the wiki functionality entry page and the timeline, roadmap, source browser, and ticket manager.

4.3.2. The wiki

The Trac entry page shows the wiki, which is one of the major features of Trac. A wiki is a system of linked HTML pages that can be edited on an ongoing basis. The wiki is a collaboration platform extended and maintained by users. For example, if you click the “Edit This Page” button for the Trac entry page, you’ll get its content. The following listing shows the content in plain text format with the Trac markup notation.

Listing 4.1. The content of the start page (excerpt)

You can arrange text and create new pages as needed. The comprehensive formatting support allows you to enter different header styles , link to other pages inside the wiki or outside the wiki , and emphasize text, such as displaying it in italic or bold .

An interesting feature of Trac’s wiki is that you can monitor the changes (including the change history) to the page, line by line. A bit later we’ll see a similar display for exploring the source code.

 

Agilo for Scrum

Agilo for Scrum is an application developed on top of Trac (see www.agile42.com/cms/pages/agilo/). Agilo is an open source tool available through an installer or hosted service. It contains many features that support the daily work of Scrum teams, including a configurable product and sprint backlog, the creation of requirements or user stories, multiteam and distributed team support, a wiki, a roadmap, a dashboard, and real-time burn-down charts. Agilo can be integrated with Subversion, and a ticketing system is also available.

The default Trac installation is more open than Aglio with respect to the development process you choose. With the default Trac installation, you can support Agile projects.

Agilo also ships in a commercial pro version that includes more features, such as an integrated whiteboard.

 

4.3.3. Timeline and sources

You can display the timeline by clicking on the Timeline tab. Doing so will display the recent changes made on the system. The attractive feature here is that the changes are displayed across all possible change types including changes to milestone planning, tickets, the repository, and the wiki. This functionality fits well into the ALM environment.

Figure 4.13 shows the changes and who did what at what time. The admin user edited the wiki start page, created a new ticket with the unique number 4, and submitted something into the Subversion repository. Because Trac is monitoring the underlying source repository, it detects the change and displays the groups of commits as changesets.

Figure 4.13. The timeline view showing who changed what in the system, including changes on tickets, the subversion repository, wiki pages, and milestone planning

You can configure the view via the options in the box at the right of figure 4.13. You can customize the timeline and the information that should be collected and summarized on this page. If you want more detail, click on the link to go to the next page and view the additional details. For example, if you’re interested in the changeset, you can click on the changeset number (3) and view the page shown in figure 4.14.

Figure 4.14. A changeset, including changes on the code base done in this atomic commit

 

Continuous integration with Hudson and Bitten

The Hudson Trac Plugin (http://trac-hacks.org/wiki/HudsonTracPlugin) integrates build results delivered by Hudson into the Trac timeline and provides a menu link to jump to the Hudson application.

Bitten (http://bitten.edgewall.org) is a Trac extension for continuous integration, and it joins the Trac ecosystem seamlessly. It uses a distributed build model, where one or more slaves run the tests and a master gathers the results and displays them on a web page.

 

The touched file is displayed with its differences compared to the older version. Inside the file, lines are colored to express the type of change, such as red for removed and green for added. You also have access to the revision numbers that Subversion increases continuously. In figure 4.14, Trac detects that with Subversion revision 1, the file was initially imported, and this file was changed with Subversion revision 3. You could now also extract the status of the file at those two moments in time (the revisions) by clicking the links provided—r1 and r3, respectively. In addition, you can generate a diff between two revision numbers of a file, and you can enter the two revision numbers freely.

 

Providing Outlook Tasks

Another interesting extension in context task-based development is the bridge to Outlook (http://sites.google.com/site/outlooktrac/). Many teams use Outlook for time management, and this plug-in provides Trac tickets as personal Outlook tasks.

 

When viewing changesets, Trac’s Browse Source tab is opened. If you click on that tab when you’re not viewing a changeset, you’ll see the complete Subversion repository with its contents, including its individual state (its revision numbers), its age, and the last change. This way, you can browse the complete repository.

4.3.4. Roadmap and tickets

By clicking on the Roadmap tab, you see Trac’s release management facility, which allows you to create milestones for your development.

Ticket updates are based on Trac’s configurable status transition and workflow facility (for example, assigning tickets to other people). Tickets can be assigned to milestones. Milestones also display the ticket status; for instance, which tickets are open and which ones are closed. Besides seeing the ratio of closed to active tickets, you can see the milestone due date and can enter the milestone detail page.

The Trac roadmap is a list of future milestones. You can customize ticket grouping and adjust the view by filtering the roadmap to show or hide specific milestones.

 

Eclipse And Trac

Similar to the first toolchain we discussed in section 4.2, you can integrate Eclipse with your ticketing system. Again, the Eclipse plugin Mylyn is used to integrate Eclipse and Trac. In our first toolchain, we configured Mylyn to use the available JIRA connector; here you have to use the Trac connector that glues Trac to Eclipse.

 

This concludes our tour of Trac. We saw Trac’s main features that support task-based management. The integrated approach lets you link and navigate through different aspects of your daily work across different media and development phases:

  • The smart repository browser gives you access to the Subversion repository.
  • The roadmap can aggregate tickets to releases.
  • The timeline feature aggregates all different change types on one view.
  • The wiki function lets you use Trac as a central knowledge base.

All this is linked through wiki markup. Trac is based on plug-ins, and you can extend and configure it according to your requirements.

4.4. Summary

In this chapter, we discussed lightweight tools for setting up and driving an Agile ALM process: JIRA, FishEye, and Bamboo are lightweight, commercial tools for planning and tracking tasks. Adding Mylyn to this chain makes it possible for developers to manage a task from their workspaces. GreenHopper is a JIRA extension that adds more visualization features, such as cards.

Trac also offers features for planning and tracking tasks. It’s an open source tool that provides a central view on your development activities across development phases. Besides the wiki, it contains release management functionality, including timeline and roadmap features, a ticketing system, and a Subversion repository browser. Trac can be integrated with Mylyn and Hudson/Jenkins. Both Trac and JIRA are highly configurable, feature-rich tools. They can be integrated with other tools, they can aggregate information, and they can serve as one-stop shops for managing your activities by managing tasks. In both toolchains, task-based development is based on the convention of using the ticket number in the check-in comment.

Handling toolchains can be complex. The detailed examples we looked at in this chapter should give you a good idea of how to implement lightweight toolchains to support task-based development.

In the next chapter, we’ll discuss integration management and the technical releasing of software, based on Maven.