Clever Geek Handbook

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

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



「逐次統合のシステム」、翻訳が正しいかどうかわからない-継続的統合のシステムと呼ぶ方が良い。

5-7人のプログラマーがコードとテストを集中的に記述し、構成ファイルを変更し、すべての結果をトランク/マスターに注ぎ込んだとき、私が仕事の始めに初めて出会いました。 その結果、かなり頻繁に（非常に頻繁に既に激怒していた）動作不能なものがメインブランチに現れました。 さらに、これはテストベンチを展開する必要があるときに明らかになり、テストグループ（修正待ち）と開発者（それぞれ修正済み）の作業が大幅に遅くなりました。 すなわち コードの状態は、リポジトリに配置された後は制御されませんでした。



画像

その後、 ハドソン（http://hudson-ci.org/）が助けになりました（現在はJenkins（https://jenkins.io/）として知られています）が 、正式にはハドソン自体が残っていましたが、あまり人気がなく、あまり積極的に開発されていませんでした）-彼は多くのことをしました：





これは、開発チームの品質と透明性を改善するという点で大きな前進でした（マスター/トランクの混乱の可能性を最小限に抑えることについては話していません）。





しかし、それはすべて以前のものです。 質問は次のとおりです。単独で作業する場合、継続的インテグレーションシステムを使用する意味は何ですか

ある時点まで、本当に意味がありませんでした。 プロジェクトが成長し（1人の開発者の参加があっても）、統合サーバーの存在がその真の価値を示すまで：





Jenkinsの追加の興味深い機能は、そのインターフェイスです。





パイプライン



しばらく使用しなかったJenkinsの最も重要な機能改善は、Pipelineプラグインの登場でした 。これにより、Jenkinsインターフェイス自体またはプロジェクト自体の個別の構成ファイル（ Jenkinsfile



ファイル）を介して実行/起動/チェックの対象を決定できますプロジェクト/モジュールのコードを受信する際のCIサーバー。



このアプローチにより、リポジトリポーリング（Jenkinsインターフェースで実行）の設定手順とテスト/統合手順自体（ Jenkinsfile



ファイル）の設定​​手順を分離できるため、開発者またはデプロイメントの責任者は、Jenkinsにアクセスすることなく、必要なテスト/統合段階を構成/変更/追加できます。



たとえば、私のサブプロジェクトの1 Jenkinsfile



、 Jenkinsfile



内容は次のとおりです。 

 #!groovy node { def projectName = 'glr_parser' def gradleHome = tool name: 'gradle', type: 'gradle' stage('Checkout') { // for display purposes // Get some code from a GitHub repository // parent directory checkout changelog: true, poll: false, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CleanBeforeCheckout']], submoduleCfg: [], userRemoteConfigs: [[url: 'story_line2_build.github.com:fedor-malyshkin/story_line2_build.git']]] // project itself checkout changelog: true, poll: true, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: "${projectName}"]], submoduleCfg: [], userRemoteConfigs: [[url: "story_line2_${projectName}.github.com:fedor-malyshkin/story_line2_${projectName}.git"]]] // deployment // checkout changelog: true, poll: false, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: 'deployment']], submoduleCfg: [], userRemoteConfigs: [[url: 'story_line2_deployment.github.com:fedor-malyshkin/story_line2_deployment.git']]] } stage('Assemble') { dir(projectName) { // Run the maven build sh "'${gradleHome}/bin/gradle' -Pstand_type=test assemble" } } stage('Test') { dir(projectName) { try { sh "'${gradleHome}/bin/gradle' -Pstand_type=test test" } finally { junit "build/test-results/test/TEST-*.xml" } } } }


ご覧のとおり、これは実際には多少近代化されたグルーヴィーです（JenkinsのDSL）。 Pilpelineは、ステップ、ステップ、およびノー​​ドで構成されています。 ステージはステージビュープラグインに反映され、誰もがプレゼンテーションやその他のパフォーマンスで表示するのが大好きです。



同時に、開発者は、検証フェーズ中に自分が何に制限するかを決定する権利を持っています：単体テストの開始、コーディング標準の確認、統合テストの開始、または本番環境でテストされた成果物の配置（したがって、継続的配信の原則の実現）。



ヒント







現時点では、Jenkinsのマイナス面は製品の不十分なドキュメントのみであることに注意してください。多くの場合、開発者のサイトのドキュメントセクションに「これはまだ進行中の作業です」という碑文があります。 ただし、これは真に柔軟で強力な製品から押し出すべきではありません。



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


More articles:


All Articles