Roles are a foundational component of DataOps environment management, with the following roles used:
- Read-only: Any person with read-only access to the codebase.
- Developer: The person or people making the changes.
- Approver: The person or people approving the merge request
- Merger: The person actioning the merge request. This is often one of the Approvers. A single person may be the Approver and Merger for organizations that do not need large-scale infrastructure.
- Release Manager: The person responsible for understanding "what features are where" and creating merge requests from QA to production. Merge Requests from
feature-branch-nameto dev and from dev to QA are managed by the developer working on the feature.
The conceptual model scales from single-person (or two-person) teams to massive teams of hundreds of people. Essentially, one person can do everything and achieve all the #TrueDataOps benefits except review their code, which violates a core #TrueDataOps principle, that of Governance and Change Control. Therefore a second person is needed to be the Approver. It is then possible for the one person to be Developer, Merger, and Release Manager, albeit with care taken.
As with governance and change control discussed in DataOps Roles above, collaboration is a core #TrueDataOps pillar and an imperative of DataOps environment management.
What is the #TrueDataOps pillar of collaboration?
For this answer, let's turn to the #TrueDataOps philosophy:
Collaboration is a recognizable result and clear benefit” of a successful #TrueDataops implementation rather than a principle to adopt. It is achieved by team members, business stakeholders, and end-users all working together for a common goal, to facilitate the development of data products via the DataOps platform.
Collaboration aims to be practical and create value.
In summary, the most significant benefit includes:
- The development of new features clashing and people stepping on each other toes is dramatically reduced in this model but can never be totally eliminated in DataOps or with any Git strategy.
It is still valid to occasionally hear a couple of developers ask their colleagues whether it is ok if they can have exclusive access to the dev branch this morning. This should not be seen as a sign of failure. Sometimes, it is beneficial to know that you are the only person making changes to a complex piece of work.
This exclusive access can only be a rare exception to the rule. If it becomes the norm, something is wrong.