Tasktop

We’re especially appreciative when members of our community are out there evangelizing the technologies we develop here at Tasktop. Mike Henke has been one our most ardent fans, and happily, he is again at it. Mike will be at d2w, the designer developer workflow conference in Kansas City July 14 – 16. Mike will be presenting “A Task-Oriented Workflow With Mylyn and Eclipse” on July 15 from 9:45 – 10:40.

From the d2w conference website, the presentation abstract is:

Mylyn’s task-focused interface reduces information overload and makes multitasking easy. Mylyn makes task a first class part of the Eclipse IDE and monitors your programming activity to create a “task context” that focuses your workspace. This puts the information you need at your fingertips and improves productivity by reducing information overload, facilitating multitasking and easing the sharing of expertise.

If you are in the Kansas City area, you should attend d2w and catch Mike’s presentation.

Getting a contribution accepted into Eclipse is not a walk in the park. In the Mylyn project, each patch that comes in through Bugzilla is reviewed by a committer usually going through multiple iterations until it makes its way into Git or CVS. Mylyn has great support for handling patches, but this can still be a tedious process for both the contributor and committer when it comes to larger changes, due to a lack of automation of the contribution workflow. Contributors need to keep patches up to date, possibly juggling several outgoing change sets which can easily lead to incomplete or over inclusive patches. On the receiving end committers are burdened with validating patches and running tests which requires a number of manual steps. Conversations around patches happen through Bugzilla comments making it difficult to refer to particular lines.

These problems are not limited open source contributions. In many organizations, development follows similar work-flows often requiring use of several applications that are not integrated. This article introduces the new Mylyn connector for the open-source Gerrit code review system that helps automate onerous parts of the code review process enabling developers to focus on collaborative aspects and code rather than nit picking broken patches.

Gerrit is a web-based code review server for the distributed version control Git. When combined with Hudson/Jenkins it forms a powerful system that stages and validates every change before other developers have even noticed. With the integrations available in Mylyn 3.6 and Mylyn Reviews 0.8 developers can now seamlessly integrate these tools in their day-to-day work-flows.

Alex Blewitt has written an excellent tutorial how to configure Git, Gerrit and Hudson. In this article we will assume that the following servers have been setup as described in the tutorial:

• Gerrit 2.1.8   (Gerrit 2.2 is not yet supported)
• Hudson 2.0.1

To get started we need to install the following tools from their respective p2 repositories into Eclipse:

• EGit – http://download.eclipse.org/egit/updates
• Mylyn Builds: Hudson Connector – http://download.eclipse.org/mylyn/latest
• Mylyn Reviews: Gerrit Connector – http://download.eclipse.org/reviews/updates

To illustrate the interactions in a typical code review we’ll look at how Alice and Bob work on on a code change together. We’ll start with Alice who intends to implement an enhancement for an existing project that is already setup in Gerrit and Hudson.

Alice has cloned the Git repository that is managed by the Gerrit server into her workspace. In her environment the server is called dev.

By default EGit creates a configuration that pushes the local master branch to the remote master branch. For Gerrit, Alice needs to change the configuration to push the local master to refs/for/master instead. Gerrit uses that special location to stage changes for the master branch.

Alice is now ready to commit her enhancement and push it to Gerrit. The commit dialog has an option to automatically generate a Change-Id which is used by Gerrit to track the change. If Alice wants to update her commit later Gerrit can relate the changes based on that ID.

The confirmation dialog shows that the push to refs/for/master automatically created a new branch to track the changes for the code review.

In our setup we configured a Hudson server to monitor the review server for new branches. Every time a new branch is detected a build is automatically triggered. Alice now wants to verify that all tests pass in the build that was triggered by her push before involving Bob in the code review.

After Alice has configuring the build server in the Team Repositories view and subscribed to the corresponding Hudson job she can monitor the status in the Builds view without switching to the browser. Since Alice’s commit broke one of the integration tests the build status is red. This is not problematic since the commit is staged and not yet visible in the master branch.

It’s easy to drill down into the details of a failed build. Double clicking a job opens an editor that shows the failed tests, changed files and created artifacts. With a few clicks Alice can open test results in the JUnit view and re-run the failed test in her workspace.

Once Alice has fixed the bug she commits and pushes again to replace the previous change on the code review. To update the existing code review she amends the previous commit. That way, the commit message gets automatically populated with the Change-Id from the previous commit which identifies the code review. Through the ID Gerrit knows that the new commit replaces an existing change and is not a new code review.

Again, the build server picks up the changes and this time all tests pass.

Alice is now ready to pass the change on for review. She adds a task repository for the Gerrit server and a new query in the Task List.

The query is a personalized subscription to the review server. It brings in code reviews Alice is interested in into the IDE and enables her to work with them. Like any other Mylyn task, code reviews can be scheduled and activated embedding reviews seamlessly into the task-focused work day.

Code reviews open in an editor that is the hub for the conversation around a Gerrit change. The editor shows details about the work-flow state of a review, the people involved and the comments.

The review that is shown here has received one vote already. When the Hudson server executed tests it posted the results back to the review. A +1 in the Verified category indicates that the build passed.

To pass the code review a +2 is required in the Code Review category. To notify Bob that the change is ready for review Alice adds him as a reviewer in the people section.

Bob’s workspace is setup with the same projects and queries. When Bob task list refreshes a little popup notification is displayed and the review is decorated with a blue arrow in the task list.

Bob’s first step is to open the code review. The content under review is listed in the patch-set section. Each patch-set equals one commit to the Gerrit server and is tracked in a separate Git branch. Bob can now bring a patch set into his local workspace by using the fetch button under the patch set. This is useful to verify a fix or to try a feature through running changes locally. In this case Bob decides to review changes directly in the compare editor.

Double clicking a file in the patch-set section opens an editor that shows the current master on left and the proposed changes on the right. Comments can be added by selecting any line in the file and right clicking. Initially, comments are saved as drafts and are not visible to others.

After Bob has completed the review adding several comments he publishes them. The publish button opens a dialog that allows Bob to provide a rating.

With Bob’s +2 vote all requirements are satisfied and Bob submits the review as the last step. The most recent patch on the review is automatically committed to the master branch by Gerrit and becomes visible to all developers.

With these IDE integrations, Tasktop provides the same task-focused productivity benefits that developers already enjoy for tasks and SCM systems to code reviews and builds, capturing more of the developer’s workday and providing even better integration for mixed open source and commercial ALM stacks.

To see a demo watch the video at the end of Mik’s blog post on Mylyn 3.6.

This year, Tasktop Technologies and VMware co-hosted the Eclipse Indigo DemoCamp in Vancouver. The event was a smashing success with some 60 developers in attendance, awesome networking and even cooler talks including:

		Presentation by Ralph Muller from the Eclipse Foundation
		Benjamin Cabé from Sierra Wireless presenting on Koneki
		Rafael Chaves from Abstratt Technologies presenting: “Full code generation with AlphaSimple” (AlphaSimple is an online modeling tool built on Eclipse technology)
		Kris De Volder from VMware presenting on Cloud Foundry
		Presentation by Ed Merks, project lead of the Eclipse Modeling Framework project
		David Green of Tasktop Technologies presenting the latest Mylyn integrations for Git, Gerrit and Hudson (see photo below)

To get a sense for what Demo Camps are all about, watch the video of the opening talks from VMware’s Andrew Eisenberg, Eclipse’s Ralph Mueller, and Tasktop’s David Green available here: http://vimeo.com/25746826. We were not able to capture the sessions, but hope to do so next time.

After the event, we all headed out to a nearby Lennox Pub for more fun and networking…

In this picture, Ralph Muller of the Eclipse Foundation, as well as Andrew Eisenberg of VMware and other developers networking in the background.

See More Photos from the event…

For more information about the DemoCamp please see the Vancouver Eclipse Indigo DemoCamp wiki

Hope to see you all there next year!

Yesterday’s Eclipse Indigo release delivered a year’s worth of improvements on what has become the de facto IDE platform for Java and beyond. The Java package has seen major additions, including the WindowBuilder tool that originated from Instantiations and the m2e plug-in that eases Maven-based builds. EGit 1.0 is an essential tool for the growing number of Eclipse developers using Git, and in addition the top-level project included new tooling for Hudson/Jenkins as well as early access support for Gerrit.

The Mylyn features in Indigo further entrench Eclipse as the leading IDE in terms of the application lifecycle management (ALM) tools needed for developers to collaborate around code. Most developers spend the majority of our time on application maintenance activities rather than the creation of new features, making the new traceability aspects of Mylyn and Mylyn-based tools increasingly important to large-scale application development. Out of the box you now get ALM support for the leading open source tools including Bugzilla, Trac, CVS, Git and Hudson. The rich ecosystem of both open source and commercial integrations available means that you can plug Eclipse into your own ALM stack and get the benefits of tasks-focused productivity and automated traceability across the vast majority of the leading task, issue, source and review management tools as visible below.

Other notable features in Mylyn 3.6 include automatic population of contexts on activation for tasks that contain stack traces, making it very simple to navigate to relevant sources when starting on a new task.

To emphasize the social nature of task-focused collaboration, the task editor now displays images for the assignee of a task. Thanks to the traceability that we provide between Hudson builds, tasks and code changes, putting these features together means that you now get to the faces associated with builds. Perhaps for the next release we should streamline things even further and use mapping to inline all the contributors’ Gravatar images in the build editor itself, to help give credit where it is due.

What’s key is the way that these features work together to make the Eclipse IDE be the collaborative console for the developer. The video below, recorded at the JAX conference in May, has Tasktop’s Steffen Pingel and Benjamin Muskalla illustrate the sort of open source ALM workflow automation that can be created using the new connectors and APIs and tools shipping with Mylyn 3.6. We hope that both this release and our ongoing efforts will continue to make your workday easier and more productive.

See the Mylyn 3.6 New & Noteworthy for more from the Mylyn 3.5 and Mylyn 3.6 releases included in Indigo.

Ever wondered what is going on inside the brain of people working at Tasktop?

Last week, I had to honor to speak at Skills Matter, Europe’s largest provider of open-source and agile trainings in the London area. It was a great time in London and Skills Matter was kind enough to provide a recorded version of the talk for people who could not attend.

As part of their branding, the talk was titled: “In The Brain of Benjamin Muskalla: Mylyn: Closing the Agile ALM loop with task-focused collaboration” so I thought: when you’re able to know what’s going on in my brain, I don’t even need to talk about anything. You’ll expierence some silence up to 5:20 as we forgot to turn on the microphone. As the whole talk is about 1:20h, it’s still worth watching it if you want to find out how to do task-focused collaboration with Mylyn and Tasktop. In addition, there is a quick outlook in the connectors coming up around code review with Gerrit and the Git integration for Mylyn.

You can watch the whole talk at the Skills Matter website.

Planning tools form an integral part of any software project and picking a good planning tool can be critical to success.  But for teams working in large enterprises it isn’t as simple as picking which planning tool they think is best.  In large enterprises, a significant part of many projects involves integration between heterogeneous systems, and planning in that context becomes an exercise in integration as well.  With requirements in one system and defects in another, planning can be tedious and seeing the larger picture difficult.

Imagine you’re ScrumMaster for a team in a large company that uses HP ALM’s Agile Accelerator for release planning.  Your company has just acquired a small start-up and your next release will involve full scale integrations with that company’s existing products. They’ve spent the last couple of years building up a product backlog in Rally and have a good amount of historical data to track velocity.  The tools are familiar to them and have become part of the routine for developers in their daily work and during scrum meetings so you don’t want to disrupt their productivity by switching tools.

But the new phase of development involves integrating products that have issues and defects being tracked in two completely different systems.  With the timelines and deliverables now intertwined, trying to plan across these two different systems is proving to be difficult because it’s not easy to see the dependencies between the two systems.

Tasktop has recognized that for many teams the choice of planning tools may be largely determined by existing infrastructure in the organization, and that the next generation of planning support will embrace and flow with the differences in that infrastructure, rather than try to enforce sameness.

So how does Tasktop make Agile planning work in this kind of environment?   The Tasktop Planner provides an extra level of flexibility in planning by allowing you to mix plans from different repositories.  You can have your user stories and sprints in Rally, your defects in HP Quality Centre, and still be able to plan everything in one place.
Tasktop Planner provides a unified interface for planning across different systems and lets you create associations between those systems.  And you can do all of this right from within your development environment where it’s possible to navigate from a user story in one system to a defect in another to a line of code in your IDE.

To help you fully harness the power of Tasktop’s Agile Planning, I will be offering a free webinar on cross-repository Agile planning:

When:		May 26, 2010: 9 am PDT (GMT-7)
Presented by:		Doug Janzen, Senior Software Developer and Project Manager at Tasktop Technologies
Register now:		Webinar – Cross-Repository Agile Planning

In this webinar, I will explain why it is so important to have Agile tools be able to reach across repositories to be truly usable by companies. I will then demonstrate how Tasktop’s cross-repository Agile planning works highlighting how sub-tasks in a user story or on a Scrum board can have dependencies on issues from other systems. I will also highlight how all of this information can be available from within the Eclipse IDE as well as in an offline manner.

To learn more about the Tasktop Planner and how it can help bridge the gap between heterogeneous plans download an evaluation copy of Tasktop Enterprise or sign up for the webinar: