Continuous Integration

A Continuous Integration (CI) process looks for changes in the code (i.e. new commits being pushed or merged), then automatically tries to build, run, test, analyze, and deploy the code.

Key Concepts

• Source of truth: Sometimes, you may write code that works on your machine, only to discover that it doesn't work on other machines. There may be a forgotten configuration or pre-condition that prevents it from running smoothly or at all. A CI server can act as an impartial judge of whether the code base works by building, installing and testing each change from scratch. Unless it works on the CI server, it doesn't really work.
• Automated build: Having a server rebuild the codebase after every change means that the entire build process has to be scripted. While this requires that the development team has to gain some fluency with operational concepts like environment configuration and bash scripts, it makes sure that the build process is well-understood, consistent and version-controlled.
• Dependency security audit: Dependencies (borrowed libraries of code) can introduce security vulnerabilities in your app. Well-maintained libraries release patch-level versions to fix vulnerabilities. Tools like npm audit and capabilities of tools like Artifactory and Nexus allow the audit of dependencies to find such inherited vulnerabilities.
• Automated tests: Once the codebase is built, the server should be able to run a suite of tests to validate the functionality and verify nothing has broken. Again, this will rely on scripts to initialize the environment and execute the tests.
• Code analysis: If the test suite ran successfully, the CI server can use other tools to measure code coverage, code complexity, compliance with style and a host of other metrics that can be tracked to show how the code has improved over time.
• Validate pull requests: A CI server can be used as the first step in a PR review process. Before other developers get a chance to review the code, it can be automatically built, tested and analyzed. This frees up the development team to perform high-quality review tasks only after the low-level checks have succeeded.

Pluribus Expectations

• Use a CI server: There are several free CI servers available. We use GitHub Actions as a default for internal projects, and that or others (Jenkins, Azure DevOps, etc.) for customer work. These should be configured to build and test every push and/or every pull request.
• Metrics: Static code analysis tools check code quality. SonarQube is a common tool to do so, and some static analysis capabilities are built into GitHub.
• Perform security scans: Static code analysis products like the above code quality tools, or standalone security scan solutions, should be used to find potentially unsecure code (i.e. of the code that we write).
• Enforce security audits: High severity dependency audit results should "break the build", and not allow the app to progress to deployment. This is generally a quick fix (updating the library to the latest patch version), but could occasionally result in replacing a library that is not well maintained enough to issue fixes.