Organizing changes into tasks
In task-driven development, changes made to individual files are grouped into higher level structures, called tasks. Every change made to implement new functionality or fix a bug is a task.
In this model, developers continually work on tasks. Periodically, a set of finished tasks are incorporated into a new release. This release becomes the basis for the next set of tasks. And the cycle continues.
The branch-per-task pattern
Plastic SCM implements task-driven development efficiently and intuitively, through the well-known branch-per-task pattern. It's all described in our Quick-Start Guide. Plastic SCM integrates with your issue tracking system (ITS), using the issue number as the link. Task branches have a simple naming scheme:
user-defined-prefix + issue-number
For example, the figure above shows branch task1102.
Clearly, the work on this branch is being performed for issue #1102
in the issue tracking system. Full CMMi-level traceability is
achieved -- it couldn't be easier! (Try doing this with a
changeset-based or mainline-development approach.)
The ITS integrations go further: for example, double-click a
branch in Plastic SCM to open the associated issue record in the
issue tracking system; or see which files have been modified for a
task by looking at the issue record.
It's agile
Task-driven development is the essence of the agile methodology. Plastic SCM makes your agile cycles visible:
- Releases and tasks are visible in the Branch Explorer, together with their relationships (when tasks were integrated, what tasks a release contains)
- Better continuous integration: validate tasks before they actually reach the mainline (be proactive better than reactive); never break your build or propagate unfinished code to other developers.
Keep the mainline pristine
Breaking the build is a common occurrence when you're using a
mainline-development approach. You checkin some code that wasn't
"fully cooked", and you break some tests -- or even worse, break
the system build with code that won't compile or link.
Keeping the mainline pristine is one of the goals of the
branch-per-task approach: you strictly control access to the main
branch, making it much less likely to introduce break-the-build
changes. With branch-per-task, the mainline is no longer a chaotic
rendezvous point for the entire team, where everyone gets
synchronized continuously and instability often occurs. Instead,
the mainline represents stability, evolving carefully with
well-established and fully-tested baselines.
For more, see this blog post.
No more broken builds stopping the team, stop bug-spreading
With your mainline-development approach, how often do you checkin (commit) your changes? You've probably put off checking-in work, because you don't want your colleagues to shout at you, saying the code won't build anymore -- right?
With branch-per-task, you don't have this problem: you can check-in as often as you want, without disturbing others' work. This enables you to create frequent checkpoints (to which you can fall back, if necessary), enabling you to more fully control your development environment.
Enforce baseline creation (don't shoot at moving targets!)
If you're using a mainline-development approach, it's easy to create a working copy from an untested, unstable base. With Plastic SCM, task branches are based on labeled baseline configurations -- well-known, stable starting points. This really helps you staying focused on your own changes, without having to worry about what others are doing.
Using baselines is an SCM best practice. When you adopt the branch-per-task methodology, baselines play a central role in your daily work. And there's no better way to enforce a best practice than to make it an essential part of your workflow.
Task independence
Since each task starts from a well-known baseline, they are typically not dependent on each other. This simple fact gives you huge flexibility. You choose what goes into the next release (by selecting which branches to merge), instead of just taking what happens to be on the mainline.
