Reduzindo builds instáveis (flaky builds) em 18 vezes

No GitHub, eles definem como flaky build uma build que, com o mesmo código, em alguns casos falha e em outros passa. Dizem que reduziram as flaky builds para 1/18 ao introduzir automação para que cada problema flaky seja resolvido pela pessoa que escreveu aquele código e não afete outras pessoas.

No CI interno do GitHub, eles rastreiam flaky builds, organizam as situações problemáticas e depois atribuem o caso à pessoa que se estima ter causado o problema.

• Ao rastrear flaky builds, perceberam que a frequência variava, e as flaky builds que falhavam mais de 100 vezes representavam 0,4% do total. Por isso, decidiram se concentrar nesses 0,4%.

• Quando isso foi introduzido em 2016, adotaram as duas abordagens a seguir.

  • Quando a build termina, procuram builds executadas com o mesmo commit e, se os resultados forem diferentes, marcam como flaky build

  • Se a mesma build for repetida e o resultado for diferente, marcam como flaky build

• Com esse método, só foi possível distinguir 25% de todas as flaky builds.

Melhorando

• Usaram o método de reexecutar 3 vezes

  1. Tentar novamente no mesmo processo. Essa flaky build acontece por aleatoriedade no código ou por race condition.

  2. Tentar novamente no mesmo processo, mas depois de algum tempo. Essa flaky build acontece quando foram feitas suposições incorretas sobre tempo.

  3. Tentar novamente em um host completamente diferente. Essa flaky build acontece por dependência da ordem dos testes ou por estado compartilhado.

Com esse método, passaram a conseguir detectar 90% automaticamente.

Medindo o impacto

Era necessário um método para quantificar o impacto e assim definir prioridades.

Usando informações como build, branch, autor, commit etc., eles atribuem uma pontuação de impacto com base em quanto aquilo falha e em quanto afeta outras branches ou desenvolvedores.

Se ultrapassar uma certa pontuação, criam uma issue para que os desenvolvedores possam corrigir e a atribuem ao desenvolvedor.

[ganadist]

No meu caso, eu encontrava flaky builds com frequência nos unittests do Gradle, então apliquei as soluções abaixo.

• Usar o plugin https://plugins.gradle.org/plugin/org.gradle.test-retry ajuda bastante a rastrear flaky builds em unittests.

• Usar https://docs.gradle.org/current/dsl/… pode reduzir flaky builds, já que a execução passa a ocorrer em um novo processo após um determinado período.

• Se você adotar o Gradle Enterprise, fica fácil acompanhar a evolução dos flaky builds. https://gradle.com/blog/flaky-tests/