Continuous Integration / Development (CI/CD) tools engaged in the XANDAR’s toolchain development

Published by xandaradmin on

CI/CD is the acronym for the combined practices of continuous integration (CI) and continuous delivery (CD). CI/CD practices are currently the most widely accepted choice to shorten software development and delivery cycle time by providing continuous delivery with high software quality. The CI/CD methodology emerged as the pivotal solution to quick and robust response to market demands and it is nowadays assumed to be the dominant part of the DevOps set of practices that combines software development (Dev) and IT operations (Ops).

In CICD, CI workflows are triggered when the developer completes his total work and pushes his commits to the remote repository. This event initiates a process that consists of multiple stages. The first stage is pulling the latest version of the source code. Then, the source code building task is started (including fetching all the dependencies). Upon the successful completion of the building tasks, unit tests are executed sequentially. Unit tests reassure independent software units/methods/functions behave as expected. Finally, upon the successful execution of the unit tests, integration testing is executed. Integration testing verifies whether the various software components interact with each other – via their predefined and implemented interfaces – according to the defined test case scenarios. The result of each stage of the process is reported. Apart from the overall status (success or fail) more fine-grained feedback is given (e.g., number of totals, failed and succeeded tests, build number, etc.). These stages can be summarised in the list below [1] :

  1. Detect and fetch updates in the source code repository
  2. Static code analysis Build
  3. Testing (unit, integration, system)
  4. Packaging
  5. Overall status reporting

If one of the steps above fails:

  • Integration may stop or continue depending on defect severity and configuration
  • Results are notified to the team via email or chat system
  • Team fixes defects and commits again
  • Tasks are performed again

Continuous delivery (CD) picks up where continuous integration ends. While CI is the process to build and test automatically, CD deploys all code changes in a build to the testing or staging environment. CD makes it possible to release builds to the production environment when needed. Allowing the team to deploy at will, CD effectively reduces time to market. Before deploying software to production, the CD process includes performing automated system testing, unit testing (including API testing and load testing), and integration testing. As tests can fail at any level and environment, CI/CD must include a feedback channel to quickly report failures to developers. Dependent on policies and processes defined by teams, the best practices considering CI/CD dictate the following:

  1. Before committing new changes check if the previous build has succeeded. If not, fix errors before committing new changes.
  2. Build and test locally to ensure the new update does not break any functionality.
  3. If successful, commit new changes.
  4. Allow CI pipeline to complete with new changes.
  5. If the build fails, stop and fix errors on local workstations. Go back to Step 2.
  6. If the build passes, continue working on other items.

If one of the steps above fails, the process is interrupted, and the development team is informed accordingly. The process starts again when new source code fixes are committed again to the repository.

On the other hand, if integration completes successfully, the CD part takes over. CD is responsible to deploy the new artefacts to the target environment (testing, staging, production, etc.). While the CI part improves the source code quality CD speeds up the release cycle, shortening thus the total time to market.

Apparently, CI/CD cannot meet its objectives if testing automations are missing or if test coverage is low.  Before deploying software to production, the CD process includes performing automated testing in various levels, including unit testing (including API testing and load testing), integration testing and system testing

  • Unit test: Tests individual units of source, functions/methods.
  • Integration test: Ensure that software components interact with each other as expected based on predefined interfaces.
  • System test: The behaviour of the system is tested. Test case scenarios are executed aiming to simulate the final system environment and operation (or the user behaviour if present).

Apart from testing the functional parameters of a system, testing the non – functional parameters (e.g., security, load/stress) is also required for delivering high quality software.

Many software tools are available to support implementing CI/CD practices. These tools range from repository management such as GitHub and Bitbucket, Jenkins, Bamboo, and Travis for build automation, to Selenium for test automation.

Categories: News