Green build policy everything what you must know
Green Build Policy
During the last months, I have been working with several teams that are struggling with green build policy. A green build signals that the code is working, it means that the software developed by the teams is in a state that can be released to the customer.
- Below I will present several items that should be met to consider a build as a green build:
- X% of code coverage from Unit Test (If test coverage is minor than % defined the build gets red)
- Automated tests for the User Story pass (If any test fails the build gets red)
- Integration testing pass (If any test fails the build gets red)
- Acceptance testing for all stories pass (If any test fails the build gets red)
- All regression testing of the product pass (If any test fails the build gets red)
- System-level Non-Functional requirements pass (If any test fails the build gets red)
- Static program analysis (If the analysis of the tool is not met the build gets red)
Depending on how mature your software development process is you can add more items, or you will need to remove some of these items.
Why is a green build important?
I strongly believe that one of the reasons why people don’t give the importance they should to a “Green Build” is the fact that they don’t understand what is behind it; what does a “Green Build” bring to them and the organisation?
Having a “Green Build” means that a team has their basic needs fulfilled, which is to say that they don’t need to worry about basic problems like making sure that they have the right kits or the right packages in place.
Having a “Green Build” means that the team can concentrate on improving other parts of the software development, therefore focusing on something more important; to quote Deming, “Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.”
A “Green Build” can serve as a safety net; if the code compiles, all the different tests pass, etc., it means that (most likely) nothing was broken, and this instils confidence in the team. The changes are not only visible to the other developers in the team, but they also feel as though they just “give birth” to a build that can potentially end up in acceptance testing or even in production.
Not having a “Green Build” for a long period indicates that the product is not stable. The lack of a stable product increases the unpredictability factor in any given release. In these situations, it is impossible to know when the product will be ready to release without a large (and unpredictable) testing phase at the end. Not having a “Green Build” leads to a sequential project lifecycle, aka a waterfall.
These are just small ideas, but they should serve to remind us how important it is for our companies to actively maintain a Green Build Policy.
Keeping a green build for a long term is something quite difficult and demands a lot of discipline by the development team, below you find several reasons explaining why is it so difficult to keep a green build.
Why is it difficult to have a Green Build?
There are three different areas that I want to touch.
Code changes
To illustrate my point I want to tell you a story of a project where I was involved. It was a complex; the technology was new and difficult, and the teams were not all collocated. Developers had to wait several hours to get the feedback to know if they had broken something.
As a consequence, the product was constantly broken. In this case, the basic unit test coverage was not enough to prevent the developers from breaking functionality. These teams still have a long way to go to become truly Agile.
One of the areas where we could see this was by looking at the frequency of their commits, some of the guys did not commit their changes for days in a row. Which resulted in a lot of time lost trying to merge their changes into the trunk.
And above all this complexity they also had to deal with a complex version control system, allowing developers to make many mistakes while checking in.
Tests changes
The testing part was still acting as they were before, they were now part of the same team, but they acted like they were still in the Silos. F.ex. new tests were still only written by the QA people, not by the developers who implemented the code.
This meant that sometimes the test was failing for several days because the people writing the tests were not the ones that needed to fix the code.
Another problem they faced was that when the functionality changed and the QA people were not notified that the tests would not be adapted and then fail for the wrong reason.
Build System and Test System
Finally, we had some problems that showed up once in a while, but important enough to mention here. The build system did not belong to the development team. Instead, the build system belonged to a whole separate department. Which meant that when a problem related to the build occurred hey sometimes had to wait for several days before the build was green again.
Having the above-mentioned problems meant that finding a cause was extremely difficult.
I don't have the perfect solution for all these problems, I have my beliefs and my opinions, but I don't know how to solve all issues in a short time. Since I do not want to finish this blog without any ideas, I will give an example of another team we have where the results are extremely positive.
This small team has the ownership of everything. They own the build system, testing system, production system and whatever is needed for the work. They practice TDD, and there are no departments saying how they should work.
They solve their problems on a daily basis, they do whatever is needed to make it "green". They commit their code every couple of hours, they don't go home if the code does not compile and all the tests are green.
I believe the biggest advantage of this team is the fact they know why a green build is so important. After failing so many times, they understood why a green build is mandatory.
All organisations should aim for continuous improvement. However, I truly believe the first step is to understand where we are and where we want to go. So if your organisation has some problems, bigger or smaller, does not matter.
I believe first you should realise which problems you have and define a plan where you want to go. Then just work with the rest of the organisation to achieve those goals. Do not forget to empower your teams; they know what to do much better than you.
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=green build policy" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.
