patternMinor
Is there a CI tool that guarantees no regressions in the branch quality level?
Viewed 0 times
qualitythelevelbranchguaranteesthatregressionstheretool
Problem
Traditionally CI systems only perform monitoring of the quality levels in an integration branch, by performing QA verifications on the codebase where the changes are already committed, watching for regressions and sending notifications for human intervention.
But when these regressions are detected the branch has already been in trouble at least since the respective QA verification started and will remain in such state (or even get worse!) until all the culprits are identified, repairs for them committed and a new QA verification confirms the branch quality level was restored. The branch can be considered blocked for normal development during all this time.
Is there a CI tool capable of actually preventing such regressions from happening, which would perform pre-commit QA verifications and allowing commits only when the codebase updated with the respective commits would be passing those pre-commit QA verifications as well, thus guaranteeing a minimum branch quality level?
Update: the assumption is that suitable automated QA verifications with appropriate coverage to be able to detect the respective regressions are available for invocation by the CI tool(s).
But when these regressions are detected the branch has already been in trouble at least since the respective QA verification started and will remain in such state (or even get worse!) until all the culprits are identified, repairs for them committed and a new QA verification confirms the branch quality level was restored. The branch can be considered blocked for normal development during all this time.
Is there a CI tool capable of actually preventing such regressions from happening, which would perform pre-commit QA verifications and allowing commits only when the codebase updated with the respective commits would be passing those pre-commit QA verifications as well, thus guaranteeing a minimum branch quality level?
Update: the assumption is that suitable automated QA verifications with appropriate coverage to be able to detect the respective regressions are available for invocation by the CI tool(s).
Solution
As far as I can tell, you're looking for a tool that will reject commits that break the build—a CI tool probably won't be able to prevent regressions by actually fixing your code, but it can stop you from adding bad code to the repository.
Atlassian has a few interesting applications of Git hooks:
Server-side pre-receive hooks are an especially powerful compliment to continuous integration because they can prevent developers from pushing code to master, unless the code meets certain conditions – like elite ninja guardians, protecting it from bad code.
If you're using Git, the hooks are very powerful (and there are similar hooks for SVN, Mercurial and other version control systems), and you might find it useful to use them to run pre-commit checks.
The Git documentation has a page on creating a hook to reject pushes if they don't meet a certain criteria which could easily be adapted to this use-case.
However, a lot of people would argue that rejecting commits is a bad idea on a
On the
Atlassian has a few interesting applications of Git hooks:
Server-side pre-receive hooks are an especially powerful compliment to continuous integration because they can prevent developers from pushing code to master, unless the code meets certain conditions – like elite ninja guardians, protecting it from bad code.
If you're using Git, the hooks are very powerful (and there are similar hooks for SVN, Mercurial and other version control systems), and you might find it useful to use them to run pre-commit checks.
The Git documentation has a page on creating a hook to reject pushes if they don't meet a certain criteria which could easily be adapted to this use-case.
However, a lot of people would argue that rejecting commits is a bad idea on a
feature branch—you'll just be wasting time fighting against your CI system when the build breaks for some reason, instead of actually fixing the bug. On the
master branch, it could make sense to reject broken merges, because you might want to ensure it always builds. For a feature branch, you will inevitably break things, and since the code isn't going into production now, it makes more sense just to warn you than actually reject your commit altogether.Context
StackExchange DevOps Q#268, answer score: 6
Revisions (0)
No revisions yet.