No need to Claim Credits! Codify your Work & let’s GIT Talk

Software developers don’t worry about credits because their work already tracked through SCM — or Source Control Management system, like GIT.

Even, they don’t think about it, because GIT enforces the teamwork principles like work review ( code review & PR) , in-parallel work ( multi branches)… etc.

However, people want to be appreciated on the work that they’ve done.

GIT helps companies to gather evidences on work done by Dev team. Some Git services (like github ) provides even contribution graph like the following:

GIT keeps a history of all work done. Each change( commit) includes:

• Author name
• Date/time
• Description
• change Delta (diff)

Example — Git commits in ArgoCD Git Repo

But, What about Operations Work ?

Operations work includes:

• installing tools, systems
• configuration systems
• Maintain systems — backup/restore/scaling in|out|up|down/… etc
• and others

Because this kind of this work is not a?CODE, it would not be eligible for tracking through SCM like GIT.

As consequence, validating the achievement's owner is not accurate.

Thus, the culture of “Credit” is inevitable; anyone looks to credit, which may lead to unhealthy environment at the end (hiding, less-communication,.. etc) .

Codify Ops work — GitOps

GitOps flow vs Traditional Ops Flow

A:?Traditional operations — Target directly the system to do the change/the work.

1+2+3+4+5:?Modern Operations — Convert Operation to Code & treat it asa a software then use pipeline to push the change after being reviewing & merged to the main GIT branch.

The Operation team become a software developers — not developing Java or nodeJS apps, but it’s infrastructure-as-code, configuration-as-code using technologies that allows to do that while complying with software engineering best practices.

No Need to Claim Credit ! Let’s GIT Talk

Because the modern Ops teams are writing code, their work become SOFTWARE, tracked by SCM.

It means all the work done by this team has a history, tracked by GIT.

This history includes who writes that code, when, and what.

All team members can shill out now.

GIT will talk on their behalf about their achievements.

GitOps in Action

Let’s take this example :

• you want to implement new enhancement (optimize Build of Tech X)
• A task has been transfered from your project backlog to your sprint backlog.
• Identify the Git Repos where to make the change & codify this enhancement. In this example, you will touch 4 git repos..
• Make the change in a feature branches, create pull-requests, and let your team review your work/your code.
• As soon as the Code is merged, pipeline(s) will be triggered to deploy that change to the write system
• Task is resolved in your issue management system (i.e. JIRA)..

After looking into this example, Can anyone dare to attribute this achievement to himself ?

No way! all work is codified, and code has a thorough history including the author, date/time and change delta , as explained at the beginning of this article.

This is the optimal way to protect your ideas/your achievements from being stolen by unprofessional behaviors