OpenStackのジェンキンスCIにテストプロセスの構成例

テストプロセスは、様々な方法で構築することができます。 プロセスの自動化をテストするための最も効果的な方法の一つは、継続的にソフトウェアの継続的デリバリーによってテストされています。 継続的なテストにより、コードの品質を安定化および改善できます。 なぜなら すべてのアプリケーションは開発から始まるため、本格的なテストを開発サイクルに実装する必要があります。



連続的な供給の基本的な考え方は、バージョン管理システムへの各変更は、戦闘環境に標準と完全に自動化された方法を取得することを可能にするパイプライン（展開パイプライン）を、構築することです。



最初の部分のためのジェンキンスさんへの配備例のパイプラインの建設：



1.パイプラインプロジェクトの作成

1.1。 「アイテムの作成」-名前を入力し、パイプライン構成を選択します

1.2。 「GitHubプロジェクト」フィールドにリポジトリのアドレスを入力します

1.3。 「変更についてSCMに問い合わせる」チェックボックスを選択し、リポジトリを毎分チェックするようにスケジュールを設定します「* * * * *」

1.4。 「パイプラインスクリプト」フィールドにプロジェクトの手順を入力します

node{ stage 'Deploy' build 'Deploy_CHECK' stage 'Sonar_analysis' build job: 'Sonar_analysis', parameters: [string(name: 'STAND', value: 'CHECK')] stage 'Unit tests' build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'CHECK')] stage 'Deploy DEV' build 'Deploy_DEV' stage 'Unit tests' build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'DEV')] stage 'Acceptance_test' build 'Acceptance_test' stage 'Smoke_tests' build job: 'Smoke_tests', parameters: [string(name: '', value: 'DEV')] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2.リポジトリに変更を加えます

3. 1分以内に、パイプラインはリポジトリの新しい変更を確認し、チェックを開始します



図1 CHECKおよびDEV環境でチェックを実行する例。





図2。 検証手順の1つの結果。





図3 作業のステップの1つでのエラー検出





Jenkinsで展開パイプラインを構築する2番目の部分の例：



1.パイプラインプロジェクトの作成

1.1。 「アイテムの作成」-名前を入力し、パイプライン構成を選択します

1.2。 「GitHubプロジェクト」フィールドにリポジトリのアドレスを入力します

1.3。 「変更についてSCMに問い合わせる」チェックボックスを選択し、リポジトリを毎分チェックするようにスケジュールを設定します「* * * * *」

1.4。 「パイプラインスクリプト」フィールドにプロジェクトの手順を入力します

 node{ stage 'Deploy QA' build 'Deploy_QA' stage 'Compliance tests' build job: 'chef-compliance', parameters: [string(name: 'STAND', value: 'QA')] stage 'Functional tests' build job: 'Tempest', parameters: [string(name: 'STAND', value: 'QA')] stage 'Performance tests' build 'Rally' stage 'Deploy PROD' build 'Deploy_PROD' stage 'Smoke tests PROD' build 'Smoke_tests_PROD' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2.マージリクエストが正常に閉じられた場合、

2.1。 開発ブランチをリリース2.2としてトリミングします。 パイプラインはリリース*ブランチの変更を確認します

2.3。 パイプラインはチェックから始まります



図4 QAおよびPRODUCTION環境のパイプライン実行プロセス





図5 QAおよびPRODUCTION環境でのテストの展開と実行による成功したパイプラインの結果





図6 QAおよびPRODUCTION環境でのテストの展開と実行で失敗したパイプラインの結果





3.マージ要求が失敗して閉じられた場合、

3.1。 変更の影響を受ける開発者にエラー通知が送信されます。