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 and it couldn't be easier! (Just try doing this with a
changeset-based or mainline-development approach. We dare
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 just by looking at the issue record.
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, and never circulate 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 check in some code that was
half-baked, 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 the branch-per-task approach, the mainline is no longer a chaotic rendezvous point for the entire team, where everyone syncs up 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.
Check in code without breaking the build
With your mainline-development approach, how often do you commit your changes? You've probably put off checking in work because you don't want your co-workers to yell at you, saying the code won't build anymore.... Right?
With the branch-per-task pattern, 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 (on which you can fall back, if necessary) and to more fully control your development environment.
Enforce baseline creation
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 stay 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. There's no better way to enforce a best practice than to make it an essential part of your workflow.
Since each task starts from a well-known baseline, they are typically not dependent on each other. This 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.