1A developer has to work on task 1213 (taken from Jira, or any other issue tracker).
2They create a branch for it and names it following a convention (Plastic does this automatically if an integration with the issue tracker exists).
3They work on the branch making as many checkins as they need.
4When they're done, they set an "status" attribute on the branch as "resolved".
The code review can be just a quick walkthrough using Plastic diff or an in-depth one. Plastic provides a built-in code review, but others like Crucible can be used too.
5Another team member will review the changes in task1213 to make sure it is ok. If not, task will be reopened and the cycle will be restarted.
6Some teams will "validate" the task – other team member will do a short exploratory test to make sure the new feature or change makes sense. Status can be set to "validated" in the attribute.
7Your CI system, using the Plastic SCM plugin, monitors branches that have a given attribute set, and creates new plans accordingly. A branch will only be considered by the CI system when it reaches a given status. In this case status: validated.
8Your CI system will try to merge the Plastic branch. If it fails, the process will be restarted and the developer will have to rebase from main to solve any conflicts.
If the merge can be made automatically, the CI system will run the test suite.
9If tests pass, the merge is checked in and the branch is now ready to be delivered.