A full DevOps cycle with task branches + code review and CI

A full DevOps cycle with task branches + code review and CI

How to drive your DevOps process

branch picture
One

A developer has to work on task 1213 (taken from Jira, or any other issue tracker).

Two

They create a branch for it and name it following a convention (Plastic does this automatically if an integration with the issue tracker exists).

Three

They work on the branch making as many checkins as they need.

Four

When they're done, they set an "status" attribute on the branch as "resolved".

branch picture
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.
Five

Another 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.

branch picture
Six

Some 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.

Seven

Your 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.

branch picture
Eight

Your 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.

branch picture
Nine

If tests pass, the merge is checked in and the branch is now ready to be delivered.