Welcome to the Verigreen wiki!

Verigreen is a lightweight, server side solution for verification of git commits. It is a gated check-in process which will not allow any failed commit to arrive into an integration/release/any protected branch. This will keep your branches green at all times and will deny failures to replicate into the rest of the development team. This, along with a clever optimization algorithm for working with your CI system, makes it an ideal solution for teams to adopt and brings quality to a much higher level.

The Problem

As a developer submits his code upstream, it usually triggers on some sort of CI process (at least, it should...). It can be followed by a CD process or any other related processes which eventually reflects the changes made by the developer to the internal/external customers, be it QA teams, other development teams or even real customers, when it comes to SaaS services.

The problem lies within this flow order itself - it happens only after the code has been submitted to the integration branch. This means that most if not all verification processes take place after the changes made it to the target branch. Once failed, it halts the development flow and vibrates to the rest of the developers is the team, as they all pulling each other's code from the same integration branch. This eventually can cause a big disruption and a big waste of time and effort for all. It also causes a lot of pressure on the developers responsible for breaking the code, as they are very much aware of the fact that the rest of the team may be waiting for their fix to be merged in as soon as possible. this is how it is usually looks, it terms of a changes flow:

The Solution

Verigreen simply changes the order of things in the CI/CD process : when a developer submits code targeted to one of your important branches (release ,hotfixes, etc.), Verigreen makes sure it will not arrive there before going through a verification process, as defined by the team. It is only then, after the verification process has been successfully completed, the changes will arrive to their destination by Verigreen, although the developer's name is preserved, of course, and will show up as the one who made the change.

In case of a failure in the verification process, whether it a real code break, a network issue, or any other problem which may have caused the verification process to fail (or not work at all for that matter), the code will not go to the integration branch and will have to be fixed or the job to be re-run and succeed first, in case it was a random/sporadic failure of some kind. This is how it looks like when Verigreen comes in:

Verigreen Basic Flow

When the Verigreen project was initiated the following mindset, defined right from the start dictated how Verigreen would be designed:

• The solution should not alter the development environment, hence, a server side solution.
• The solution should be lightweight in footprint in terms of computational resources.
• The solution should be flexible enough to integrate with any verification flow the DevOps team may decide to utilize.
• It should be easy to disengage Verigreen in case a problem occurs, so back to normal carries no issues.
• The solution should know how to handle low and high pace development teams and keeping the system consistent at all times.

Having said that, Verigreen flow is simple and very effective. When a developer pushes code to a repository in which Verigreen was enabled on, this is the basic flow that takes place:

1. The developer pushes his/her changes to a remote repository
2. The pre-receive hook is triggering Verigreen
3. Verigreen checks if the commit coming in is targeted to a "protected" branch (by "protected" we mean that a verification process is needed before the commit is approved to be merged)
4. if the commit is not targeted to a protected branch, the commit is being merged in as usual
5. Otherwise, Verigreen is diverting the commit to a temporary side branch and runs a verification process from this branch
6. Verigreen reports the diversion to the git client which initiated the push. It reports the push as failed but that is a must due to the way Git is designed
7. If the verification process returns a "success" result, the commit is being merged in, the temporary branch is being discarded (deleted) and the process ends. If not, the change is rejected and stays on the temporary branch
8. The change initiator receives an informative status email and can decide on the ways to fix the problem
9. The system is ready for the next change to arrive

The very basic and high level flow, for one protected branch and one commit, at a given moment, should look something like this: