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

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

How to drive your DevOps process

branch picture

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

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.

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.

branch picture

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.

branch picture

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.

branch picture

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