Breakages are seen quite often in a large project with many developers, especially when there is a dependency between various components in the project. A change in one component could have a negative impact on other dependent ones. It gets the developer/sustainer baffled, specially when some of his/her genuine changes are released and are available in latest labels, and consequently there is a immediate urge to find out the root cause as soon as possible.
A direct approach to setup a debugger like ddd/gdb on the label having the breakage can help identify the bug and solve the same. However, it requires some time to setup and to debug, especially in embedded systems. Hence, other debugging approaches can save a lot of time in such cases.
* Most systems have a well defined logging functions in place. Functions have an entry and exit logs. Logs could be taken from both working and non-working builds and they could be compared to get a rough idea as to where the code flow is deviating in the buggy build. Thats the right place to start and to identify any recent changes in that flow.
* Once the bug is found, one could perform a binary search on the release branch so as to identify the particular change which introduced the bug.
If one has a good knowledge on the code and its flow, a direct binary search on the release branch for recent changes can reveal the bug instantly. Breakages always adds on to the valuable time and effort spent by the developers and ultimately affects the delivery. The lesser the time spent on identifying such issues, the better it is for the delivery.
No comments:
Post a Comment