丨構建檢測無規(guī)矩不成方圓

上述的配置會在構建時（準確的說是在validate時）完成三項檢查requireMavenVersion查Maven本必須大于3.3.9；requireJavaVersion檢查JDK版本必須大于等于1.9；requireOS檢查OS必須是Windows系統(tǒng)。如果你使用Java1.8，Maven3.3.3，在Linux上構建，便會出現(xiàn)如下的錯誤Rule0:org.apache.maven.plugins.en r.RequireMavenVersionfailedwithmessage:DetectedMavenVersion:3.3.3isnotintheallowedrange3.3.9.Rule1:org.apache.maven.plugins.en r.RequireJavaVersionfailedwithmessage:DetectedJDKVersion:1.8.0-77isnotintheallowedrange1.9.Rule2:org.apache.maven.plugins.en r.RequireOSfailedwithmessage:OSArch:amd64Family:unixName:linuxVersion:3.16.0-43-genericisnotallowedbyFamily=windows從而導致構建失敗那么，是否有辦法在所有應用的構建前都執(zhí)行 r的檢查呢我在專欄的第5篇文章《手把你依賴管理》中，也已經介紹了在攜程內部，一般Java應用的繼承樹關系，每個項目都必須繼承來自技術或公司層面提供的super-pom。攜程在super-pom之上又定義了一層super-rule的pom，這個pom中定義了一系列的Enr規(guī)則。這樣，只要是集成了super-pom的項目，就會在構建時自動運行我們所也許你會問了，如果用戶不繼承super-pom是不是就可以跳過這些規(guī)則檢查了？是的，繼承super-pom是規(guī)則檢查的前提。但是，我們不會給用戶這樣的機會 因為上線走的都是統(tǒng)一的構建系統(tǒng)構建系統(tǒng)在構建之前會先檢查項目的繼承樹，繼承樹中必須包含super-pom，否則構建失敗。并且，構建系統(tǒng)雖然允許用戶自定義Maven的構建命令，但是會將Enr相關的參數過濾掉，用戶填寫的任何關于Enr參數都被視為無效。Enr被強制按照因為攜程的構建系統(tǒng)只提供幾個版本的Java和Maven，并且操作系統(tǒng)是統(tǒng)一的LinuxCentOS本，所以就不需要使用之前例子中提到的三個檢查，一定程度的縮小標準化范了解了MavenEnr插件，我再從MavenEnr內置的規(guī)則、自定義的Enr檢查規(guī)則，以及構建依賴檢查服務這三個方面，帶你一起看看構建監(jiān)測的“豪華套餐”，增豐富的內置的EnrMavenEn r供了非常豐富的內置檢查規(guī)則，在這里，我給你重點介紹一下bannedDependencies規(guī)則、dependencyConvergence規(guī)則，和banDuplicateClasses規(guī)則。第一，bannedDependencies規(guī)則該規(guī)則表示使用某些依賴，或者某些依賴的版本，使用示例該代碼檢查的邏輯是，只允許使用版本大于等于1.8.0org.slf4j:slf4j-api賴，否則將bannedDependencies規(guī)則的常見應用場景包當我們知道某個jar包的某個版本有嚴重時，可以用這種方法用戶使用，從而避某個公共組件的依賴必須要大于某個版本時，你也可以使用這個方法用戶直接第二，dependencyConvergence規(guī)在《手把你依賴管理》一文中，我介紹了Maven的依賴仲裁的兩個原則：最短路徑優(yōu)但是，Maven基于這兩個原則處理依賴的方式過于簡單。畢竟在一個成系統(tǒng)中，依賴的陷阱里，這時dependencyConvergence就可以粉墨登場了。dependencyConvergence規(guī)則的作用是：當項目中的A和B分別了不同版本的時En檢查失敗。下面這個實例，可以幫你理解這個規(guī)則的作用org.slf4j:slf4j-jdk14:1.6.1依賴了org.slf4j:slf4j-api:1.6.1，而org.slf4j:slf4j-依賴了org.slf4j:slf4j-api:1.6.0，當我們在構建項目時，便會有如下錯誤這時就需要開發(fā)人員介入了，使用dependecy的exclusions元素排除掉一個不合適的版本。雖然這會給編程帶來一些麻煩，但是非常必要。因為，我始終認為你應該清楚地知道系統(tǒng)依賴了哪些組件，尤其是在某些組價發(fā)生時，這就更加重要了。第三，banDuplicateClasses規(guī)則該規(guī)則是ExtraEn rRules提供的，主要目的是檢查多個jar包中是否存在同樣命名的class，如果存在編譯便會報錯。同名class若內容不一致，可能會導致 ethodException等異常，而且排查起來非常，因為人的思維很難定位到重復類這個非顯性錯誤上，例如下面這種情況：ty與ty中都包含一個名為NettyBundleActivator類，另外還有2個重復類：spring/NettyLoggerConfigurator和microcontainer/NettyLoggerConfigurator當激活了banDuplicateClasses規(guī)則之后，Enr檢查，便會有如下的報通常情況下，用戶需要排除一個多余的jar包來解決這個問題，但有些情況下兩個jar包都不能被排除，如果只是個別類名了，那么可以通過ignoreClasses去忽略的類，類名可以使用通配符（*），如:ty.container.*。不確定的問題。因此這個插件做了一些改動，通過API來獲取ignoreClasses的內容。當用戶有類似的需求時，可以提交ignoreClasses，但必須申請，經過Java專家自定義的Enr除了上述的規(guī)則，實際上攜程還做了若干個擴展的規(guī)則，如CheckVersion，用于檢查模塊的版本號必須是數字三段式，或者帶有SNAPSHOT數CheckGroupId，用于檢查GroupId是否符合規(guī)范，我們?yōu)槊總€部門都分別指定distributionManagement的repository點，并為每個部門都指定了他們在Nexus上面的repositroy；以上，便是攜程基于MavenEn r在構建檢查上的一些實踐，你可以借鑒使用。但是，有時候MavenEn r也我們所有的需求，比如，它無法完成非Java項其他語言，比如C#，NoeJS等，沒有MaenEn r這樣成工具來做構建時的依賴檢查。對于這類語言我們的做法是：構建后，收集該項目所有的依賴及其版本號，將這些數據發(fā)送給依賴檢查服務Talos，Talos根據內置的規(guī)則進行依賴檢查。Talos是一套攜程自研的，獨立的，組件依賴檢查系統(tǒng)，其中包含的檢查邏輯，完全可以自由定義。而且，Talos依賴檢查的邏輯更新非常靈活，可以直接在平臺內使用Java代碼編寫檢以下是一段.NET項目檢查邏輯的示例代該邏輯的含義是項目的依賴存在foo.dllbar.dll，bar.dll版本號必須大?？?，是不是非常方便快捷通用這樣一套組合拳下來，構建檢測以及項目依賴的問題已不再那么讓人望而生畏了。因此，工欲善其事必先利其器，好的工具可以解放大量的生產力，最重要的是構建檢測后的交付讓你我更有信心了。有條不紊的流程與規(guī)范，就像一列高速列車下的枕木，時刻保證著整個系統(tǒng)穩(wěn)定而可靠地推進。我圍繞著構建檢測，和你一起學習并介紹MavenEnr插件可以幫我們更好地完成編譯檢測可以使用內置的MavenEnr規(guī)則，覆蓋常規(guī)檢測可以使用自定義MavenEnr檢查規(guī)則的方式，增加版本號規(guī)則等的檢查MavenEnr之外，你還可以自己豐富一些例如依賴版本檢測這樣的服務，以提高檢MavenEnr提供了非常豐富的內置檢查規(guī)則，感的話，你可以通以及逐個嘗試這些規(guī)則