While a holistic Continuous Delivery methodology is relatively nascent, Continuous Integration (CI) has been around for quite some time. The core concept is that a Continuous Integration server is connected to project’s code repository. Every time a developer makes a commit to the repository, the CI server will fetch the latest code and run a set of predefined actions.
The predefined actions generally fall into a few specific categories. The tooling used for each of these areas will vary depending on the technology in which it is implemented:
- Unit Testing - This piece of automated testing will perform pre-written tests on the code base which test units of the code. In most cases, these tests are written by the developers who write the code. In many cases, organizations follow a TDD (Test Driven Development) or BDD (Behavior Driven Development) approach to ensure that tests are written for each feature that is integrated to the experience.
- Syntax Testing - This automated testing ensures the code that is committed follows syntax guidelines for the organization. This provides a level of technical standards that allow for consistency and governance on the technical level.
- Security & Compliance Testing - This automated testing ensures that the code checks for standard security vulnerabilities and compliance standards within the organization. While this does not replace security and compliance validation in other elements, it ensures that the most common concerns are addressed.
Once this is in place, the Continuous Integration server becomes a gate for the following integration and deployment elements. Notifications are sent to each developer when the automated tests do not pass. This allows for fast resolution of issues as they are discovered, as opposed to months later in a traditional QA cycle.