Testing pipeline flow chart

Introduction

This document describes different workflows inside the Testing Pipeline.
The Testing Pipeline automatically adds jobs on Jenkins based on the tree structure of the test case repositories in gitlab-test-cases. Jobs can then be executed via Jenkins and all the reports generated will be available on Jenkins.
All the jobs are also executed every night, except the weekend.

Flow chart

Jenkins CodePipeline

aws-sde-dop-testing-pipeline-flow-chart_00.png

Jenkins job script

aws-sde-dop-testing-pipeline-flow-chart_01.png

Number explanation

Jenkins CodePipeline

  1. Developers or Testers push a new test case or modify an existing test in gitlab-test-cases
  2.  
    1. The codepipeline-jenkins is triggered by CloudWatch due to a new commit
    2. The pipeline is triggered every night except the week end for running all test cases
  3. CodeBuild fetches the source from GitLab
  4. The Jenkins server and Jenkins node Docker images are fetched from Docker Hub (This step is executed once and won’t be executed again as long as the Jenkins version did not change in the Parameter Store)
  5. The images are slightly modified and pushed on ECR (This step is executed once and won’t be executed again as long as the Jenkins version did not change in the Parameter Store)
  6. The docker-compose.yml file is created and pushed in Amazon S3 bucket as an artifact
  7. CodeDeploy fetches the sources (appspec.yml, docker files, etc)
  8. CodeDeploy deploys files and especially the docker-compose.yml file on the Jenkins EC2. Jenkins is also started
  9. The Jenkins EC2 fetches the Jenkins image from ECR and Jenkins is launched
  10. CodeBuild automatically adds the new jobs on Jenkins in the right views and modifies the job configuration, if changed. If the pipeline has been launched by EventBridge then this CodeBuild will ask Jenkins to run all the jobs. This pipeline is triggered every night by EventBridge except the week end.
  11. Developers and Testers can connect to Jenkins to see the new jobs added and run them

    Jenkins job script

  12. A developer or tester run a job on Jenkins
  13. Jenkins ask ECS to create a new Jenkins node
  14. ECS creates a new Jenkins node container on its cluster
  15. Scripts and test case config files from gitlab-test-cases are fetched
  16. We ask AWS Blu Age RTS to create a DB server based on the snapshot name given by the test case. The DB server can contain multiple DBs (app DB, JICS, Bluesam, etc)
  17. The DB server is created
  18. We ask the test case ECS cluster to create a container of the modernized application with the correct environment (INT or UAT)
  19. The cluster creates the container.
  20. The server requires a connection to the Blu Age SQS queue and then we wait for the server to be up.
  21. Depending on if it is a Selenium (A) or a Groovy (B) test case, the script will behave differently until step 14.
    1. The Jenkins node ask the Selenium hub to run a .side file on the app container
    2. The Jenkins node container make a curl request on the app container to run a groovy script
  22.  
    1. The Selenium hub ask ECS to create a chrome node
    2. Once the groovy finished, we push a script in the s3-test-cases S3
  23.  
    1. ECS creates a chrome node container
    2. We run an aws ssm command on the app container
  24.  
    1. The chrome node executes the selenium test on the app container
    2. Using aws ssm command, we fetch the script from the S3 and then run the script on the app EC2 allowing us to fetch the app logs then we get the result by using aws ssm list-commands
  25. A Selenium report is generated and then pushed on the EFS
  26. We run the CompareTool script on the AWS Blu Age RTS database to compare the DB modified by the server and the DB expected
  27. A CompareDB report is generated and then pushed on the EFS
  28. In case the Selenium script or groovy script made the app container generate some files. We put a script in the s3-test-cases Amazon S3 bucket
  29. Using aws ssm command, we fetch the script from the S3 and then run the script on the app EC2 allowing us to fetch the files generated by the application and we push them on the EFS
  30. We run the CompareTool script to compare the files generated by the app container and the files expected
  31. A CompareFile report is generated and then pushed on the EFS. A Jacoco report is generated and push on the EFS as well.
  32. We ask AWS Blu Age RTS to delete the DB created for this test
  33. AWS Blu Age RTS deletes the DB of the test
  34. We ask ECS to delete the app container created for this test. Files pushed in the S3 and EFS during the test are also deleted.
  35. Developers and Testers can check all the reports, application logs and script job logs on Jenkins

    More information

  36. gitlab-test-cases contains the test case config file and everything to run it (DB snapshot name, SQL scripts, etc). It also contains the deployment scripts for the codepipeline-jenkins and the Jenkins job scripts