At Renuo when writing new software we work in a very specific way. We like to call it «The Renuo Flow». The Renuo Flow consists of rules and conventions for «Rapid Development». I will now describe tools and processes to clarify how we define «done» and work with our clients. We initially took inspiration from Git Flow but adapted and simplified it over time to fit exactly our and our customers needs.
Our base branch is called develop, we work on «feature/» branches. There might be more branches for each new feature, depending on the feature's complexity.
👉 We like to keep our feature branches as small as possible. In case of complex features, it is desired and expected that developers work on multiple feature branches.
Continuous Integration / Continuous Deployment
Both main and develop branches are connected to an environment via CI/CD.
This guarantees our developers that the latest version of the code in each branch is also the version of the code running on each environment.
🔥 We are currently working on allowing Review Apps.
Our primary and beloved tool for CI/CD is SemaphoreCI. Nothing can be released if the CI is not green.
Merging into develop
We said that develop is our base branch, so the most important question is: «How do we bring features to develop?» What does it take and what is needed so that we can bring our code from a feature branch to the base branch? Because once it is on develop the code gets automatically released to a develop environment (also known as integration or pre-production) and is ready to be tested live.
We follow one simple rule: «You can merge a feature branch on develop when the button is green». In other terms: «If the button is green, you can release your feature to develop».
The green button
What button, what green button are we talking about? The GitHub Merge button.
Once the Merge button is green, we click it and merge our feature into develop. This means that each branch needs a Pull Request. Each Pull Request, before getting merged, needs to go through our quality barrier.
The quality barrier
Without passing through our quality barrier, nothing can end up on develop (and therefore on main). The quality barrier is made of manual and automated checks. Here is a complete list:
Automated checks
Line test coverage of 100%
Code linters
Static analysis for security vulnerabilities
All tests run
Manual checks
System tests introduced/adapted
Visual changes
Code review
If even one of those checks is still running, the button will not be green, and therefore the feature cannot be merged.
If one of the checks fails, the button will be automatically red.
☝ As an administrator, you may still merge this pull request. Everyone at Renuo is an administrator. Everyone can, anytime, override the rules defined above if needed. Everyone working at Renuo is responsible enough to use this power wisely. We always prefer people over processes, allowing everyone to release if needed.
Release
Now that we know how stuff gets from a feature branch to develop, how do we get it to main? The Release process can vary from project to project: it depends on the people involved and the clients needs. Depending on every project, you must know how the release works and who gives the «go». Still, we can sum up the following points:
The developer has tested it
The project owner/manager has tested it
The client has tested it
The client/project owner has given «the go»
Again, the above is a rule of thumb; all these steps are not mandatory:
The developer may feel comfortable with the automated tests
The project owner may not be able to test it (refactorings)
We usually tell the client when a test is necessary. We may have Continuous Deployment or Deployment Windows.
Redmine
Redmine – our project management software – is the interface between Renuo and our clients. The status of tickets mirrors the flow described above.
Each ticket can be created in Redmine by either Renuo or the client. The ticket starts from the status «To estimate» and is closed by us or the client when released on main.
Definition of done
We can now finalize our definition of done.
✅ A feature is done when the ticket is closed.
