Posts Tagged ‘issue tracking’

« Older Entries
Newer Entries »

Developer Recipes: AccuRev + JIRA + Eclipse using Mylyn

April 9th, 2008 by admin
Share|

Related Recipes: AccuRev + Eclipse + Ruby.

In this developer-centric recipe I am going to setup a power-tool trifecta consisting of Eclipse, JIRA, and AccuRev. I’m not talking about installing each independently. No, no, no. AccuRev + JIRA + Eclipse ScreenshotThis recipe is going to take things one step further and configure full bidirectional integrations for a wickedly powerful, fully integrated development environmentAccuRev + JIRA + Eclipse Chart where the majority of common day-to-day development tasks can be done right within Eclipse (right picture). Integrations are the crux of setting up a best-of-breed tool strategy and if you use these three tools you definitely want them talking together (left picture). Enough chop, let’s rock.

Install Applications

Let’s start by covering the basics and installing the latest versions of all three tools.

  1. Install AccuRev 4.6.x. download. Follow the install wizard. See the quick setup guide to import code and setup streams [Windows page 1 / Linux-page 13].
  2. Install Eclipse 3.3.x. download. Follow the install wizard. See documentation if needed.
  3. Install JIRA 3.12.x. download. Follow these instructions.

At this point, you have three independent tools installed. Developers can checkin/checkout code from AccuRev, use Eclipse to modify the source code, and track bug/feature development with JIRA. In all, not a bad setup. But toggling between all these tools just takes valuable time away from coding and there is no mashing of logically related meta-data to generate useful reports… such as:

  • “Which files/lines fixed issue #1234?”
  • “Was bug #5678 fixed in mainline, 2.x, and 1.x codelines?”
  • “Release is this Friday. How many issues are unresolved in the QA area and who are we waiting on?”
  • “Which fixes went into Release 4.5.101?”
  • “If I start working on the 4.x codeline, which known fixes will I be compiling against?”

Integrate Eclipse + AccuRev

Let’s eliminate jumping between Eclipse and the AccuRev CLI or StreamBrowser GUI. Rather, why not just keep/promote/update/merge directly within Eclipse. You can install our native Eclipse plugin via the Eclipse software updater.

  1. Help –> Software Updates –> Find/Install
  2. Select ‘Seach for new features to install’
  3. Create ‘New Remote Site’ named ‘AccuRev’ with URL http://www.accurev.com/download/eclipseupdate/32
  4. Checkbox ‘AccuRev’ and select Finish

When you create a new Project, choose to “Checkout from AccuRev.” Now the Eclipse ‘Team’ menu has a sleu of AccuRev commands available for inline use and your file navigator has icons for version control status. Sweet. Note: there is an AccuRev quickstart PDF located in your Eclipse plugin directory (e.g. /opt/eclipse/plugins/com.accurev.eclipse_4.6.1.32/UsingAB4Eclipse.pdf).

Integrate Eclipse + JIRA

Have you heard of the Eclipse Mylyn project? Seriously, it’ll bring a tear to your eye. In short, Mylyn is a generic framework for ‘task management’ within Eclipse and has a number of connectors to tools like JIRA, Bugzilla, and Trac. Guess what? You can interact with JIRA directly within Eclipse. It’s sick! seriously. Once again, you can install directly from the Eclipse software updater. First install the Mylyn framework and then the JIRA connector.

  1. Install Mylyn 2.0. Follow this setup guide. Basically, just like the AccuRev plugin above, create a remote updater site with this URL: http://download.eclipse.org/tools/mylyn/update/e3.3
  2. Install JIRA Connector. Follow the short setup guide provided by Atlassian.

As a developer, your world just got a whole lot better. Not only can you commit/update file changes directly within AccuRev, now you can open/close/update JIRA issues all without leaving Eclipse. Nuts!

Integrate AccuRev + JIRA

The final piece to the puzzle. Wait? What does hooking AccuRev to JIRA actually mean?!

Lets take a step back. Back in the day, using one of those other traditional branch-based SCM tools, you probably entered your bug #id into the commit comment. Commit 10 files. Enter bug #1234. Commit another 7 files. Enter same bug #1234. Very loose. And you probably had some validation and reporting scripts all stacked on top to keep things (hobbled) together. At the end of the day, this was far from a ‘tight’ integration and a struggle to maintain and enforce. Answering the simple question “which files -and- lines were fixed for bug #1234″ was not easy (probably impossible!).

AccuRev Change Packages. AccuRev has an out-of-the-box feature called Change Packages that natively tracks a set of files (as patches) regardless of the number of commits. Change packages are first class citizens in AccuRev. You can promote multiple times to the same change package and even remove files. The trick is to understand that a change package has a 1-to-1 relationship with… an issue! And those issues can come from JIRA. So as you work in your AccuRev workspace coding day-to-day you can promote your changes and assign them to a JIRA issue. Then make more changes and promote to the same issue. Think of it like this: creating a feature or fix may take 1 day or 100 days; 1 commit or 50 commits; Change packages don’t care. They just track the current set of files that you claim are ‘logically’ related as part of a fix or feature. That’s it! I’ll keep this short, but basically, you can now use the change package / issue as a new, first-class currency for promoting further up and/or patching those changes to other codelines! It’s very powerful. See pg 33 of our Concepts Guide for details. But I digress.

Back to the recipe. Hooking up AccuRev and JIRA means that AccuRev receives issues from JIRA and JIRA receives meta-data such as fixed files and versions for each issue. The setup requires our own connector technology called AccuBridge for JIRA. It’s pretty easy to setup and simply requires mapping JIRA fields to AccuRev fields and setting up the data synchronization. There is a well written ‘quick start’ guide to walk you through the entire setup process.

  1. Install AccuBridge for JIRA. download (link half-way down). Follow the setup guide located in the download package: doc/ais4jira_quick.pdf. [Note: Additional licensing may be required]
  2. Enable Change Packages. See pg 75 of the Admin Guide. Basically, you need to tell AccuRev ‘when’ to prompt users for issues, ‘which’ issues to query for, and which data columns to display in the lists. [Note: AccuRev Enterprise Edition is required]

At this point, developers are promoting file changes to JIRA issues and JIRA can report on ‘who’ fixed ‘which’ files for any given bug/feature/task. Now that’s what I call traceability!

All Together Now!

With everything hooked up, what do we have? Simple. AccuRev + JIRA + Eclipse ScreenshotAs a developer you can do just about everything directly within Eclipse. Edit files. Commit and update changes from AccuRev. Create issues and update comments/status/fields in JIRA. And behind the scenes, the JIRA records are being annotated by AccuRev as files are promoted out of Eclipse. Eclipse is your one-stop-shop workbench for developing, tracking changes, and managing task workflow (see picture).

Next we’ll add a build tool to the mix that integrates with AccuRev, JIRA, and Eclipse… But that’s for another day. Sounds great though, doesn’t it!

/happy coding/ – dave

7 comments »

Posted in AccuRev, Best Practices

Tags:

How Much Process is Enough? Just Enough

April 2nd, 2008 by brad hart
Share|

by Brad Hart

Hi, my name is Brad Hart and I am the Director of Technology at AccuRev, Inc. I’ve been working in the software delevelopment / process space for 10+ years. I’ve designed and supported numerous ClearCase / ClearQuest implementations both while working at IBM/Rational and as a customer at various companies. At AccuRev, I’ve been involved with countless implementations of AccuRev with our customers, everything from small to large, ISVs, Internal IT, and Embedded systems companies.

Over the years, I have seen so many different approaches for software development in all kinds of companies. One area that every company seems to struggle with is defining their process. There are many stakeholders in the development process (Developers, QA, Release Engineers, Admins, Management, etc…), and it is a difficult task to get everyone on the same page to ensure that the defined process meets the needs of everyone. One area of particular contention is the amount of process to use. I’ve worked with small companies with a handful of “cowboy” developers which had absolutely no process, and I’ve also seen the opposite end of the spectrum with so much process at large companies that it gets the nickname “pebble moving.” Neither approach works.

In the no/little process environment, developers just do what they want, where they want, and how they want. This freedom certainly seems nice for the developers. I’ve never met one yet who was yearning for more process… However, this hurts the company (including the developers) in the long run. Release Engineers have a difficult time reliably building and reproducing software, parallel development is held to a minimum, Admins lose control of the assets, Managers cannot track progress and at the end, less software is produced and what is produced is lower quality. The positive side is developers spend 100% of the time coding and 0% on process overhead. The negatives are poor software, slow delivery and regressions.

The opposite end of the spectrum is equally inefficient. Have you ever seen an issue tracking schema with 10+ tabs, 100+ fields, and a state transition workflow that can only be described using 5+ visio diagrams? I have…many times. In an effort to control each step that everyone takes, these companies suffocate their developers with way too much process. So much so that they cannot work at even close to their full efficiency. They may spend as much as 30% – 40 % of their time working within the many steps of the process and not enough time coding. From my experience, developers react to this in 2 ways. (1) They just succumb to it. They simply accept the are not working at full capacity and move on. This of course means the organization is only 60% effective and can only produce 60% as much software as the next company… (2) They rebel. A motivated developer will find a way around the process so they can be more “efficient” and get more code written. Their intentions are good, but the results are bad. This approach almost always results in disaster: broken builds, regressions, lost work, etc…

So what is the answer? Just enough process. Just enough is going to be different for each company and even each group within a company. It also is a moving target based on changes in business requirements, company growth, etc… The right thing to do is to get representatives from each stakeholder group and work together to define what all the end goals and requirements are:

  • How many releases do we need to ship per year?
  • How many releases at a time will we support?
  • What is our patching strategy?
  • Do we need to support distributed development?
  • Are we working with partners or 3rd party vendors?
  • Will we support customer one-offs?
  • What are our testing requirements and ship criteria?

Once you have the answers to these questions, you can start working on the process. The goal behind any process design is not to have a beautiful and elegant process. The goal for the process is to facilitate all actors in the process in doing the right thing and putting up just enough guardrails to keep from accidentally doing the wrong thing. Keep each business goal in mind and think about what it will take to make sure every actor has just enough information to accurately complete their task and just enough protection in place to handle common mistakes. That’s it. Don’t go overboard. That is just as bad as not having enough process. Don’t overwhelm people with information or steps to complete a simple goal. Should someone really have to fill in 40 fields to submit a defect? I don’t think so, but I’ve seen it. Keep it simple and straightforward. Just enough process is the key.

Also, make sure the tools you are using support the processes you’ve outlined. They should be able to implement your desired process and be able to adapt to changes in your process requirements.

2 comments »

Posted in Best Practices

Tags:

Adrift in a Sea of Conflicting Priorities and Assignments? Here's a Life Preserver!

March 28th, 2008 by damonpoole
Share|

Do you ever feel like things are out of control on your project, that you are adrift in a sea of conflicting priorities and requests? Do you suddenly find out at the last minute that you are the bottleneck and everybody is breathing down your neck asking you what is taking you so long to create the moveStuff() method but you had no idea that anybody even cared about moveStuff() or that you owned it? Do you ever find yourself in the exact opposite position, wondering why Sue and Bob didn’t get their stuff done that you need and then your boss walks by while you are surfing the net waiting for Sue and Bob? And who is Bob anyway?

The solution is simple! All you need to do is get everybody to move to Project. Well, if you have somebody you can spare full-time to keep Project up to date of course. Oh and I almost forgot, you’ll need to start using a requirements tool. But that’s it really, other than integrating them all together over the weekend and of course that’s assuming you’ve already gotten a CRM tool for workflow.

There is a simpler solution. It isn’t perfect, and it doesn’t solve all problems, but it can definitely provide the following benefits:

  • reduce the chaos
  • increase your vision into where you are and what’s going on
  • reduce the number of status and/or project management meetings
  • reduce the need to provide the same information over and over again
  • simplify collaboration both locally and for distributed teams
  • provide a more Agile workflow

The answer is to reduce the amount of rework that you are already doing. Right now you are probably storing defects in a defect tracking system, enhancements (aka RFEs, requirements, etc) in a requirements management tool (usually Excel or Word but sometimes an actual RM tool), and if you are using a project management tool it is probably MS-Project. All three of these product areas evolved to provide different aspects of project management for different groups of people and as a result they have lots of overlap. Considering how hard it is to coordinate three different systems, why not consider standardizing on one system for most of the work? The only question is, which system?

If we are going to try to do most of our project management work in a single tool, we should first decide what the interesting activities are. I believe they are: recording enhancement requests and defects as they are gathered by marketing or reported by users, load balancing, estimated completion calculation, critical path determination, work assignment, workflow, and reporting.

First let’s consider how well suited Project is for doing most or all of these tasks. Project is good at taking a small static collection of large tasks and doing load balancing, estimated completion, and critical path determination. Thus, it is mostly used for the very narrow task of project management of enhancements.

Next let’s consider requirements management. For whatever reason, most people use Excel or Word as their requirements management tool instead of a “real” requirements management tool. Excel and Word are just not appropriate for project management.

Lastly, there is defect tracking. A defect tracking system covers the assignment, tracking, workflow and reporting of defects. There is usually a higher volume of defects than enhancements, and they are usually smaller in scope and have a more complicated and often more time critical workflow. If it works well for defects, it should work equally well for enhancements.

Based on this analysis, it makes sense to extend the project management that you are already doing with a defect tracking system to include enhancements. A generic name for something that is either a requirement, enhancement, or defect is “work item.” By using work items to track all work, it is easy to see where you are and what remains to be done. Now you can use a similar workflow for enhancements as you do for defects, for instance from newly entered, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. You can easily run a query to see which work items have their code written but do not yet have any tests. Similarly, you can see which work items are done from a coding perspective and have tests but have not yet been verified as done by QA. This will give you a much more complete view of your overall project status and progress.

Whatever you are currently using for defect tracking it will be straightforward to start getting the benefits of managing defects and enhancements together. Just add a field that indicates if a work item is a defect or an enhancement. You may need to make a few more changes to accommodate a slightly different workflow for enhancements than you have for defects, but I think you’ll find it is worth the effort. For one example of how this can work, you can take a look at how AccuRev does it using AccuWorkflow.

2 comments »

Posted in Best Practices

Tags: