Git Feature — A new methodology to manage your development work

Sebastian Gaviria Tangarife
6 min readJan 13, 2022

Hi for all, today early in my work we detected some errors in our projects. and you will ask me why are you tell me that and i don’t care your history, so i will response you you are really interested because the problems in those project are caused because a bad organization and really confusing steps to complete a feature and this is the important not the problem, is the solution Git Feature!!!

Git Feature is an organizational methodology where they bring together the development team with QA and DevOps, and how is possible bring together all teams, asynchronous, without communication and automatically.

Git Feature is separated in 4 stages:

  • Git management
  • Testing environment
  • Merge/Branch approbation
  • CI/CD Integration

Before describe the stages we need know the roles in Git Feature which are:

  • Maintainer: Principal Developer or Product Owner (in Scrum) where decide the future of the project and accepts or denies the new features and fixes.
  • Developer: Create new branches and complete features, the developer can’t approve or merge a branch.
  • QA or Tester: This role is approve and comment a merge request searching the completing of a Issue, Note: a QA only can test a branch at the time cant merge multiple branches in a “testing” branch to do an overall test, because is preventing branch conflicts.
  • SysAdmin or DevOps: A SysAdmin receive the merge notification via WebHook or Message (Discord, Slack, others…) and update or upgrade the infrastructure, Note: is better if is an automatic task the SysAdmin only should in a update if need a change of the infrastructure.

So with the roles already defined now we can understand the 4 stages:

1. Git Management

This stage is the most important and the base of the Git Feature methodology because now the other teams like QA, DevOps and Marketing will checking the repositories actively and we can comment and create issues and the repository will Feature driven instead of other Git Management methodologies like Git Flow, because Git Feature doesn’t has staging branches like development, testing, staging only creating feature branches with a maximum life of one or two months, and is separated in three ways depending the type of repository which are:

  • #UR (Unique Repository): #UR is used if the repository has a one technology and no depends or is depending directly of an another project. this type is very simple where a feature are created and start the history and is merged directly into main/master branch.
#UR repository structure (example)
  • #SR (Separated Repository): This option is used to manage multiple repositories where reference to the same project or are dependency. This kind of repository will need sync with a tagged feature, a tagged feature is a feature branch with a common id used to refer to other branch in other repository.
#SR repository backend side (example)
#SR repository frontend side (example)
  • #FR (Fusion repository): This kind of repository basically a fusion of the previous two kinds because is only a one repository but has 2 different technologies.
#FR repository structure (example)

1.1. Commits and flags

In addition to the types of repositories, Git Feature has an specific form to create a commit which is:

Commit example
  • <FLAG> the flag is the type of commit what are you creating the flags are: FEAT (Feature), TODO (Task creation or TODO file change), CHG (Minor change), FIX (Fix an error/bug) but your team can create more flags if is needed.
  • [scope/milestone] what module or milestone are you referring, examples can be: user (users module), api-integration (a milestone to integrate with other API) and others.
  • <short description> a little comment where is the things what are you changed like “query optimization on route ‘/users’ ”.
  • [long description] a detailed description with wip changes, or explaination of why are changed the section in the commit and other things.

2. Testing environment

The QA team obviously need a testing/staging environment to test and ensure the security of the code (nowadays use a common server to test in a “testing” branch) but the idea is create a personal environment per tester because is better use a tester per branch instead all testing team in a only branch creating a parallel process and approving changes most faster, but the QA team needs a introduction into Linux, Git and The specific project deploy but this can be automated with a screen or web interface on the local computer of the tester (idea to develop a small tool), this is important because in a CI project need speed is needed to keep the project up to date and not generate bottlenecks downgrading the quality of the project and minimizing the new clients curve.

3. Merge/Branch approbation

This section is simple because the Merge approbation only can do it a maintainer or the product owner, because he knows what are the priorities of the project and which are safe changes or updates. So a maintainer can approve a branch only if a specified number of tester approve the change (the common is one but in big teams 2 o 3 is better) and if the merge is not marked as a Draft.

4. CI/CD Integration

The CI/CD integration will use 2 tools which are a Turret and Pipelines, because the objective is automate the more things possible, a SysAdmin only need update manually if the infrastructure need be changed or upgraded.

Pipeline

A pipeline is a hook triggered if new commit was created and if some rules (user defined) are true. the pipeline work is test and build the project checking the integrity and uploading in a registry if is a package or Docker image.

If the pipeline fails the change would be reverted immediately and will be checked why fails to fix it and try again.

Turret

A turret is a web server where are listening for actions to “shot” or trigger changes and update the infrastructure or do actions depending of the purpose action, this can be triggered be a CronJob or a WebHook. a turret will be used with different purposes and can do different things depending the technologies where are oriented like Terraform, Ansible or Kubernetes.

A turret is like a manager where do actions to up to date the infrastructure and report errors if the server can’t update the application.

And that was all thanks for reading and I hope it will be useful for your work.

--

--

Sebastian Gaviria Tangarife
0 Followers

I’m a Software Developer, with two objetives create more faster and secure apps and drink a coke ;)