Как ArchUnit помогает командам Netflix управлять изменениями в коде.

Я несколько раз вплотную подбирался к использованию ArcUnit и уже даже писал примеры правил, но как-то так и не добрался до хорошего уровня внедрения. Попалась статья от которой можно оттолкнутся, чтобы понять нужно вам это или нет.

Какие предпосылки использования? В Netflix нужен был инструмент который позволит командам которые ответственным за разработку библиотек, понимать можно ли удалять Depracated код, безопасно ли менять публичное API и т.д. Искали именно инструмент который будет максимально поддерживать JVM языки и по максимуму независеть от синтаксиса. К примеру PMD анализатор работает на уровне AST, тогда как ArchUnit на уровне ASM (т.е. большая переносимость между JVM языками).

В статье есть примеры написания кастомных правил в PMD vs ArchUnit и на вид последний реально удобнее. Дальше дело техники, нагенерировали правила, внедрили в пайплайн.

"Сейчас мы применяем 358 (и это число продолжает расти) правил к более чем 5 000 репозиториев, выявляя почти 1 миллион проблем. Около 1 000 из этих проблем относятся к правилам с приоритетом «High» («Высокий»). Возможность применять эти правила в таком масштабе позволяет нам быстро получать представление о нашем обширном парке микросервисов и выявлять области, несущие наибольший критический технический долг. Это упрощает фокусировку и расстановку приоритетов в нашей работе."

В итоге получился инструмент который 1. Позволяет командам формировать свои сложные правила. Причем правила могут касаться как общих практик так и использования конкретных библиотек/сервисов. 2. У команд которые сопровождают внутренние библиотеки появился инструмент быстро найти кто использует старые версии их API, и все это на огромной масштабе в тысячи сервисов/репозиториев!

На картинке пример Security правила.

https://netflixtechblog.com/scaling-archunit-with-nebula-archrules-b4642c464c5a