コンテキスト：バックエンドを備えたAndroidのニュースアグリゲーター。 ビルドシステム

導入部（すべての記事へのリンク付き）



約10〜15年前、プログラムがソースコードと少数のバイナリファイルで構成されていたとき、あらゆる種類の「？Make」が最終的なプログラムをコンパイルする素晴らしい仕事をしました。 ただし、現在の最新のプログラムと開発アプローチは大きく変化しています。これらは次のとおりです。

スタイル、テンプレート、リソース、構成、スクリプト、バイナリデータなど、さまざまなファイル（ソースについては思いません）

• プリプロセッサ;
• ソースコードのスタイルまたはプロジェクト全体（lint、checkstyleなど）をチェックするシステム。
• アセンブリ中の起動を伴うテストベースの開発手法。
• さまざまな種類のスタンド;
• クラウドベースの展開システムなど など

さらに、上記のツールと手法を使用して最終成果物または中間成果物を組み立てる段階を通じて、平均的な開発者は1日に数回行かなければなりません。 この場合、バッチファイルを手動で実行すると（結果を検証できる可能性があります）面倒です。プロジェクトデータの変更を追跡し、検出された変更に応じて必要なツールを起動するツールが必要です。



ビルドシステムを使用する私の道は、理解できない数の* make- > ant- > maven- > gradleでした （Android Studioがフードの下でgradleを使用しているという事実は、私をとても幸せにしました）。



Gradleは私を魅了しました：

• その単純なモデル（そこから、製品自体に見合った怪物を育てることができる）;
• 柔軟性（スクリプト自体のカスタマイズと、大規模プロジェクト内での配布の整理の両方）;
• 絶え間ない開発（開発中の他のすべてのものと同様-ここでは、常に何か新しいことを学ぶ必要があります）;
• 適応の容易さ（groovyおよびgradle DSLの知識が必要）;
• コミュニティによって開発されたプラグインのシステムの存在-これらは異なるプリプロセッサ、コードジェネレータ、配信および公開システムなどです（ login.gradle.orgを参照）

開発者のWebサイトのドキュメントセクションで、 Gradleの機能に慣れることができます（すべて見つけることができます！） 。 gradleとmavenを比較したい人のために、JUGからの興味深いビデオがあります。



私の場合、ビルドスクリプトは次のようになります。







、

ここで：

• build_scripts / build-tasks.gradle-依存関係を示すアセンブリのすべてのタスク。
• build_scripts / dependencies.gradle-依存関係と公開方法の説明。
• build.gradle-依存モジュール、ライブラリを定義し、他のビルドスクリプトを含むメインスクリプト。
• settings.gradle-スクリプト自体の依存モジュールと設定のリスト（gradleを起動するためにh / s引数をオーバーライドできます）。

この構成では、ビルドスクリプトへのすべての変更は集中化されたファイルで行われ（すべてのプロジェクトに与えられるわけではありません）、プロジェクトのアセンブリの責任者が集中的に調整できます。

ヒント

私が共有したい興味深いこと/ヒントのうち、私のプロジェクトでgradleをセットアップするとき、次のものがあります：

• アーティファクトバージョンの削除（モジュールのブロックを手探りするのは退屈な作業でした）

  
  
  
  
  
  
  依存関係を持つブロックを宣言します。
  
  

  // project dependencies ext { COMMONS_POOL_VER='2.4.2' DROPWIZARD_CORE_VER='1.1.0' DROPWIZARD_METRICS_VER='3.2.2' DROPWIZARD_METRICS_INFLUXDB_VER='0.9.3' JSOUP_VER='1.10.2' STORM_VER='1.0.3' ... GROOVY_VER='2.4.7' // test TEST_JUNIT_VER='4.12' TEST_MOCKITO_VER='2.7.9' TEST_ASSERTJ_VER='3.6.2' }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  そして、プロジェクトでそれを使用します。
  
  

   project(':crawler_scripts') { javaProject(it) javaLogLibrary(it) javaTestLibrary(it) dependencies { testCompile "org.codehaus.groovy:groovy:${GROOVY_VER}" testCompile "edu.uci.ics:crawler4j:${CRAWLER4J_VER}" testCompile "org.jsoup:jsoup:${JSOUP_VER}" testCompile "joda-time:joda-time:${JODATIME_VER}" testCompile "org.apache.commons:commons-lang3:${COMMONS_LANG_VER}" testCompile "commons-io:commons-io:${COMMONS_IO_VER}" } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• 外部ファイルの設定を削除する
  
  構成ファイルを作成するか、すでに持っています：
  
  

   --- # presented - for test/development only - use artifact from ""/provision/artifacts" directory storyline_components: crawler_scripts: version: "0.5" crawler: version: "0.6" server_storm: version: "presented" server_web: version: "0.1"
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  そして、プロジェクトでそれを使用します。
  
  

   import com.fasterxml.jackson.databind.ObjectMapper import com.fasterxml.jackson.dataformat.yaml.YAMLFactory buildscript { repositories { jcenter() } dependencies { // reading YAML classpath "com.fasterxml.jackson.core:jackson-databind:2.8.6" classpath "com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.8.6" } } .... def loadArtifactVersions(type) { Map result = new HashMap() def name = "${projectDir}/deployment/${type}/hieradata/version.yaml" println "Reading artifact versions from ${name}" if (new File(name).exists()) { ObjectMapper mapper = new ObjectMapper(new YAMLFactory()); result = mapper.readValue(new FileInputStream(name), HashMap.class); } return result['storyline_components']; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• パターンを使用する
  
  
  
  これは私のお気に入りの部分です。テンプレートから必要な構成ファイルを生成できます。
  
  テンプレートを作成します：
  
  

   version: '2' services: ... server_storm: domainname: story-line.ru hostname: server_storm build: ./server_storm depends_on: - zookeeper - elasticsearch - mongodb links: - zookeeper - elasticsearch - mongodb ports: - "${server_storm_ui_host_port}:8082" - "${server_storm_logviewer_host_port}:8083" - "${server_storm_nimbus_host_port}:6627" - "${server_storm_monit_host_port}:3000" - "${server_storm_drpc_host_port}:3772" volumes: - ${logs_dir}:/data/logs - ${data_dir}:/data/db ....
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  そして、プロジェクトでそれを使用します。
  
  

   //       task copyTemplates (type: Copy, dependsOn: ['createStandDir']){ description "  " from "${projectDir}/deployment/docker_templates" into project.ext.stand.deploy_dir expand(project.ext.stand) filteringCharset = 'UTF-8' }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  結果として、スクリプト中に値を受け取った変数の値でデータが満たされた構成ファイルを取得します。ただし、変数を使用してより複雑なロジックが必要な場合（たとえば、値がない場合の非表示）、アセンブリシステムに別のテンプレートエンジンが必要になることに注意してください。 プロジェクト中にYAML形式を使用してこの状況を回避しました。
  
  
  
  
• 特定のモジュールの特定の処理にGroovyリストとクロージャーを使用する
  
  
  
  これは実際にはビルドスクリプトでのgroovyの通常の使用方法ですが、いくつかの重要なタスクを解決するのに役立ちました。
  
  
  
  複数値の変数を宣言または受け取ります：
  
  

   ext { // ,  docker' docker_machines = ['elasticsearch', 'zookeeper', 'mongodb', 'crawler', 'server_storm', 'server_web'] // ,  docker'      docker_machines_w_artifacts = ['crawler', 'server_storm', 'server_web'] }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  そして、プロジェクトでそれらを使用します。
  
  

   //     docker    docker_machines.each { machine -> task "copyProvisionScripts_${machine}" (type: Copy, dependsOn: ['createStandDir']){ ... } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• Mavenリポジトリーとの統合は、記事に含めるための非常に面倒な説明です（そして、ドキュメント自体にサンプルがあるため、作品自体はまったく役に立ちません）
  
  
  
  
• 各モジュールのコピーアンドペーストが欠落しているモジュールの依存関係ブロックを処理する機能
  
  
  
  ブロックの宣言：
  
  

   def javaTestLibrary(project) { project.dependencies { testCompile "org.apache.commons:commons-lang3:${COMMONS_LANG_VER}" testCompile "commons-io:commons-io:${COMMONS_IO_VER}" testCompile "junit:junit:${TEST_JUNIT_VER}" testCompile "org.mockito:mockito-core:${TEST_MOCKITO_VER}" testCompile "org.assertj:assertj-core:${TEST_ASSERTJ_VER}" } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  そして、プロジェクトでそれらを使用します。
  
  

   project(':token') { javaProject(it) javaLogLibrary(it) javaTestLibrary(it) }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

この豊富な機能をすべて単一のコマンドでコンソールから実行します。このコマンドは、プロジェクトの下位フラグメントを決定し、必要な依存関係を更新し、必要なチェックを実行し、必要なアーティファクトを生成し、適切に構成された場合にプロジェクトの配信速度を大幅に変更できるツールとしてビルドシステムについて話すことができます消費者。



ご清聴ありがとうございました！