कभी-कभी टूटने वाले build (flaky build) को 18 गुना कम करना

GitHub में एक ही code पर कभी build fail हो जाए और कभी pass हो जाए, तो उसे flaky build कहा जाता है। उनका कहना है कि flaky issue को उसी व्यक्ति को ठीक करना चाहिए जिसने वह code लिखा है, और automation लागू करके ताकि उसका असर दूसरों पर न पड़े, उन्होंने flaky build को 1/18 तक घटा दिया।

GitHub के internal CI में flaky build को track किया जाता है, समस्या की स्थिति को व्यवस्थित किया जाता है, और फिर उसे उस व्यक्ति को assign किया जाता है जिसके बारे में अनुमान है कि उसी ने यह समस्या बनाई होगी।

• flaky build को track करने पर पता चला कि उनकी आवृत्ति अलग-अलग थी, और 100 बार से अधिक fail होने वाले flaky build कुल का 0.4% थे। इसलिए उन्होंने इसी 0.4% पर फोकस करने का फैसला किया।

• 2016 में इसे लागू करते समय, उन्होंने निम्न दो तरीकों से तरीका अपनाया।

  • build खत्म होने के बाद, उसी commit पर चलाए गए build को ढूंढकर, अगर result अलग हो तो उसे flaky build के रूप में mark करना

  • उसी build में retry करने पर result अलग हो तो flaky build mark करना

• इस तरीके से कुल flaky build में से केवल 25% को ही अलग पहचान पाना संभव हुआ।

सुधार

• 3 बार re-run करने की विधि अपनाई गई

  1. उसी process में retry किया जाता है। इस तरह के flaky build code की अनिश्चितता या race condition की वजह से होते हैं।

  2. उसी process में, लेकिन कुछ समय बाद retry किया जाता है। इस तरह के flaky build तब होते हैं जब time के बारे में गलत assumptions की गई हों।

  3. पूरी तरह अलग host पर retry किया जाता है। इस तरह के flaky build test order dependency या shared state की वजह से होते हैं।

इस तरीके से 90% को अपने-आप detect करना संभव हो गया।

प्रभाव मापना

प्राथमिकता तय करने के लिए प्रभाव को मात्रात्मक रूप से मापने का तरीका चाहिए था।

build, branch, author, commit जैसी जानकारी का उपयोग करके यह score दिया जाता है कि failure कितनी बार होता है और उसका असर दूसरे branch या developers पर कितना पड़ता है।

अगर score एक निश्चित सीमा से ऊपर चला जाए, तो developers के लिए उसे ठीक करने हेतु issue बनाया जाता है और संबंधित developer को assign किया जाता है।

[ganadist]

मेरे मामले में, gradle के unittest में flaky build अक्सर दिखाई देते थे, इसलिए मैंने नीचे दिए गए समाधान लागू किए थे.

• https://plugins.gradle.org/plugin/org.gradle.test-retry plugin का उपयोग करने से unittest के flaky build को ट्रैक करने में काफी मदद मिलती है.

• https://docs.gradle.org/current/dsl/… का उपयोग करने पर, एक निश्चित अवधि के बाद यह नए process में चलता है, जिससे flaky build कम हो सकते हैं.

• gradle enterprise को अपनाने पर flaky build के रुझान को आसानी से देखा जा सकता है. https://gradle.com/blog/flaky-tests/