CI/CD

image

CI (continuous integration) — testing step

| TLDR: During the sprint we need to create the product increment and meet deadline, so merge frequently to detect bugs early, not to get stuck in the end.

Delivery of a product increment requires reliable, working, integrated software at the end of every sprint.

Continuous integration addresses this challenge by merging all changes made to the software and integrating all changed components regularly, at least once a day.

Configuration management, compilation, software build, deployment, and testing are wrapped into a single, automated, repeatable process.

Since developers integrate their work constantly, build constantly, and test constantly, defects in code are detected more quickly.

CI consists of:

  • Static code analysis: executing static code analysis and reporting results
  • Compile: compiling and linking the code, generating the executable files
  • Unit test: executing the unit tests, checking code coverage and reporting test results
  • Deploy: installing the build into a test environment
  • Integration test: executing the integration tests and reporting results
  • Report (dashboard): posting the status of all these activities to a publicly visible location or emailing status to the team

An automated build and test process takes place on a daily basis and detects integration errors early and quickly. Continuous integration allows Agile testers to run automated tests regularly, in some cases as part of the continuous integration process itself, and send quick feedback to the team on the quality of the code.

CD (continuous deployment) — testing & building artifact

  • Aimed at building, testing, releasing software faster and more frequently.
  • Creating reliable, repeatable process for releasing software. Automate almost everything (configuration, testing).
  • “Done” means released.
  • CI is the foundation of CD process.

Whole process

As soon as the developer checks in code into a Source code repository (GitHub), CI/CD pipeline/Jenkins job is triggered (In Jenkins job’s configuration we use “Poll SCM” that helps Jenkins to detect the SCM change).

1st Jenkins job is to check Code Quality. There are lot of different tools available for different technology stack. For example, SonarQube for Java, Codenarc for Groovy etc.

If there is no issue in code quality result then job will be successfully passed to next configured job. If there is issue in the result of code quality then the job will fail and notify the developer to correct the issues.

2nd Jenkins job is to check the Code Coverage. For java code, unit testing is being done by Junit. If Junit result is more than 90 % (threshold for project) then job is passed to next configured job. If Junit result is less than 90 % then the job will fail and notification is send to developer.

3rd Jenkins job is to build and package the code. Packaging can be done in form of jar, war, ear or zip. These are called artifacts. The artifacts are then uploaded into the artifact repository (like Nexus or Artifactory)

4th Jenkins job is to deploy the artifact into the desired servers preferably CI environment by downloading the artifacts from the artifact repository (curl command can be used to download the artifact from artifact repository). Deployment is being done using python or shell scripting or any other tools like Ansible, Chef, Salt and Puppet.

5th Jenkins job is to do the Integration test. Once the integration test passes, then this code can be promoted/deployed in other higher environment like LOAD, DIT, SIT, UAT, PROD ( may be triggered manually) .

SuperMade with Super