Issue Based Development Part IV

In our last 3 posts, we’ve reviewed

  1.  the benefits of issue based development,
  2. the new product features in AccuRev that have been released in v6.0,6.1 and soon to be v6.2 that further support for issue based development
  3. general issue based development best practices.

In this final post in the series, we will not pull it all together by outlining stream structure and promotion guidelines.

Stream Structure

Let’s start off with a very simple path for development, which lends itself to agile methodologies. The hierarchy represents working through a mainline release structure, with sprint/user-story “topic” streams. Cut releases each month for sprints/iterations & continue working against mainline for subsequent releases. This same model can be applied for collaboration streams, feature streams, componentized streams, or any logical subset of code that can help eliminate a large, shared, integration “build-up” of active changes.

IBDfour Issue Based Development Part IV

Issue Based promotion vs Transactional Promotion

This is the point we would want to dictate where change packages are going to be “in play” during the development life-cycle process – meaning, promote by the change package task(s) through user-story streams into sprint streams, & use transactional promotes from that point forward. Change packages should encapsulate “tasks” assigned to developers & each specific development task will be assigned off of an associated user-story stream that pertains to the task(s). The objective is to allow isolation & flexibility at a user-story stream level (development) while alleviating dependencies which would occur immediately without smaller encapsulation of grouped tasks. In other words, you are more likely to hit file dependency issues against a large, integration stream without the division of user-story/topic streams.

In the case above, user-story streams serve many important purposes:

  1. Determine task(s) that are still in-flight or may not be able to meet the sprint deadline. This is easily queried by the active changes icon on the user-story stream. From that point decisions/actions are easily made to apply more pressure to developers, assign more development resources, or slip to the next sprint. Refactoring to the next sprint is a simple drag/drop of user-story stream to the next iteration. Work in progress (tasks) move automatically along to the next sprint & tractability is perfectly attainable.
  2. Isolation of builds & tests at a segmented/componentized level. Almost guarantees a stable, testable, full integration environment.
  3. Quick delivery/test of working component at a user-story level.
  4. Allows isolation of pushes upstream (promotes), yet allows for continuous integration pulls downstream (inheritance). Integration through inheritance will significantly reduce merge & dependency conflicts.

IBDFive Issue Based Development Part IV

Do not think that this process can only work if the project is only following Agile development practices, the same logic applies for any logical breakdown of project’s – components, features, sub-projects, collaboration, etc. The key aspect is to isolate away from the super-sized, integration bucket as much as possible. Integrate smaller & often.

That being said, how should the change packages be propagated into the development pipeline (official builds, official testing, & production delivery)?

As active changes accumulate within the full, integration stream, it logically makes sense to propagate upstream via transactions at this point. This guarantees that what was built & smoke tested will be in the same baseline upstream. This method completely eliminates change package dependencies during upstream promotes and allows for quicker, reliable propagation. Change packages will follow the transactional promote giving complete visibility & tractability at the issue level.


IBDSix Issue Based Development Part IV

Promote out of INT & QA streams up to the last transaction that was built/tested. A known, validated baseline will provide the most streamlined approach and efficient results.

The following basic best practices should be applied when working with change packages.

Follow Promotion Rules to Avoid Dependencies

Following these promotion guidelines will help you avoid dependencies.

Promote by Default Group or Transaction as a Common Case

Change Package dependencies & “patching changes” only becomes an issue when a sub-set of packages in a stream’s default group are promoted forward while others are left behind. This type of selective promotion and cherry picking is a powerful capability that Change Packages supports, but should not be the core practice that an IBD process is based upon.  Basing and IBD process on a common case where promotion from stream to stream is done by selecting all change packages within the default group (the entire contents of a default group is promoted as a single transaction) or transaction (all active transactions <= a know validated baseline transaction are promoted) will provide the most streamlined and efficient results.

Stream structure becomes an important consideration in achieving this. The stream hierarchy must be designed to encapsulate deliverable units along the process. For example, as simple stream hierarchy with the following levels in the hierarchy would look like Release<-Project<-Feature<-Topic. A stream structure needs to balance support of the delivery decision making and software integration.

FIFO Promotion

If Change Packages are promoted independently by issue preserving FIFO order will minimize dependencies.  For example, if CPK A, B, and C are promoted to a “DEV” stream in order, and all have revisions of affiliated with them, then promoting them to a parent “QA” stream in one of the following sequences will avoid dependencies:

  • {A},{B},{C}
  • {AB},{C}
  • {A},{BC}
  • {ABC}

Cross Promote to Workspace

This drastically reduces the amount of clashes (deep overlaps) between files due to inheritance – take care of the issues in a workspace and follow the defined process upstream. Promote safe and strict practices.

Promote Large Batch CPKs to Shared Configurations Quickly

Large, sweeping changes to the core baseline can be assigned to a Change Package but must be moved quickly through the process. Meaning, get the Change Package out of the way because any subsequent changes will create Change Package dependencies. Ex – adding copyright info to the whole code-base.

I hope this series was helpful. If you’d like to diver deeper, please contact us, and we can schedule time with one of our solutions engineers.

Posted in: Agile, change packages, Tips and Tricks

Leave a Comment (0) →

Issue Based Development Part 3 – Best Practice

Issue Based Development Part 3 – Best Practice

Now that Jon has outlined some of the product investments we’ve made to drive support of issue based development in the last 2 posts, I want to change the conversation and talk a bit about best practices. I spend most of my time in the field helping our customers implementing optimal delivery processes on AccuRev. There are a set of clear best practices for issue based development that we’ve developed as a result. I’ll re-cap these basic best practices in this post, and then drill down into stream structure and promotion patterns in the following post.

Promote File Elements from Workspace Streams

Change packages should be created during this promotion process. Configure the AccuRev Change Packages Trigger to enforce associated of all revisions with change packages at promote time. Essentially this forces all developers to associate all change with a change package immediately upon promoting issues out of their workspace. In order to maximize effectiveness of the IBD process, associate all revisions with change packages. There should be no unaffiliated revisions in the system.

Integrate Issue Management Systems with AccuRev/AccuWork

The typical development organization has multiple systems involved in tracking tasks and work items that require code change. For example, user stories may reside in an agile project management system, while defects are managed in a separate issue tracking system.

Effective IBD requires making all of those tasks accessible in the developer workflows so developers can appropriately associate code changes to the relevant work item (story, defect, CR, etc).

Use AccuRev’s AccuSync technology to aggregate and bi-directionally sync all work items and tasks from disparate systems into AccuWork. This makes up-to-date work items and tasks accessible to the developers participating in an IBD workflow, provides a simple, single system for developers interact with, and ensures that the original systems or record are continuously refreshed with up-to-date status, content and artifact changes.

Appropriately size “issues” (and therefore change packages)

The larger the change package, the larger the potential dependency & overlap surface area you create. Decompose work into smallest possible units that meet INVEST (Independent, Negotiable, Valuable, Estimatable, Sized appropriately, and Testable) criteria. This is not only a general development best practice that leads to a more agile development process, but it also results in a streamlined SCM process especially if CPKs are being utilized.

Close Issues When Work on them Is Complete

When work on an issue is complete, mark that issue appropriately in AccuWork to indicated that it is no longer in a work in progress state. This is not only good CM hygiene, but it prevents developers from associating changes to the issue in the future. If new changes need to be made to the original issue, simply re-open or create a new, associated issue.

Do not re-use change packages

Again, apply INVEST principles to work decomposition. Each change package should represent a distinct (small as possible) change in behavior. If developers simply use change packages as containers for arbitrary change, only loosely associated with specific behavioral outcomes, you will not only completely undermine the benefits of IBD, but will create a significant dependency entanglement and increase the likelihood of overlaps when the change package is promoted. Create new issues when applicable and define rules around when the reuse of a Change Package is not permitted.

  • Ex-1. When an issue is “closed”, the Change Package is closed, use a new issue.
  • Ex-2. When cross-promoting Change Package and merges exist, use new issue.

Use topic or collaboration streams to manage active development of change packages:

Use short lived topic streams to develop individual changes packages. This provides the following benefits:

  • Isolation of work in progress  and potential destabilization and build breakage that it can bring to a shared code line
  • Provides a sandbox for collaborating
  • Keep up stream configurations stable and releasable

Follow Rigorous Integration Practices

Integrate change packages as frequently as possible. This minimizes divergence, overlap and dependency. This includes:

  • Having developers update their workspaces frequently using “Update with Merge”.  Note :  Update with Merge will perform a rebase merge in the workspace and therefore will avoid cluttering ancestry  and history with merge lines.
  • Promoting change packages forward to integration streams as frequently as possible.  This needs to be balanced with requirements related to late stage decision making.

Proactively Manage Unaffiliated and Stranded File Revisions

There will be no unaffiliated revisions in an effectively implemented IBD process. All revisions must be associated with change packages to achieve the benefits that IBD provides, and the existence of unaffiliated revisions can cause promote by issue to fail.

IBD5 150x150 Issue Based Development Part 3   Best Practice

I hope this was helpful. Like I said, in the next post, I drill into stream structures and promotion rules that should be applied for optimal delivery.


Posted in: AccuRev, Best Practices

Leave a Comment (0) →

AccuRev Enhancements related to Issue Based Development

AccuRev Enhancements related to Issue Based Development

As a stream based SCM, AccuRev is well suited to support IBD workflows. The stream model with inheritance allow organizations to frame their delivery process as a stream structure a have the AccuRev SCM do a lot of the heavy lifting in regards to enabling parallel development and enabling integration. That said, there are two specific feature sets provided in AccuRev integral to its ability to enable IBD.

Change Packages

Change Packages provide the mechanism for tracing work items (stories, defects, etc) to the code that fulfills them, and are a key ingredient for IBD.  The AccuRev v6.2 release that is coming next month will provide the 3rd installment of significant enhancements to Change Packages that begun with AccuRev 6.0. Lets quickly re-cap the improvements that have been made over the last 3 releases and why they are important.

IBD2 AccuRev Enhancements related to Issue Based Development

Over the last year, Change Packages have evolved into an extremely powerful tool in management IBD and agile delivery. See Jack Flynn’s excellent video on Change Package improvement.


AccuSync is an ALM integration solution that allows you to bi-directionally synchronize work items from different tools such as Agile planning (Rally, Jira, Borland Agile) or defect management (Jira, Bugzilla, HP) aggregating them and making them available to the IBD workflows implemented in AccuRev.

AccuRev has invested heavily in this technology in terms of supported integrations, feature set, and performance, and offers this as a significant improvement over the prior generation integration technology, AccuBridge. AccuSync facilitates IBD at a massive scale while minimizing administrative costs.

Tools to Implement Sound Practices.

With these new capabilities that have been delivered over the last year, AccuRev has doubled down on its leading capabilities around IBD. However, tools without practices get us nowhere. Next we will explore the best practices that our customers follow to implement effective IBD.



Posted in: Agile, Product Review, Tips and Tricks

Leave a Comment (0) →
Page 1 of 79 12345...»