Continuous Integration

Continuous Integration is a development practice where developers integrate code into a shared repository as frequently as possible. Each integration can then be verified by an automated build and automated tests. The continuous integration process helps to answer several important questions for the software development team.

• Do all the software components work together as they should?
• Is the code too complex for integration purposes?
• Does the code adhere to the established coding standards?
• How much code is covered by automated tests?
• Were the tests successful after the latest change?

The answers to these questions tell the developers whether the merged code is working properly with minimal complexity and best practice. One of the key benefits of integrating regularly is that you can detect errors quickly and locate them more easily. As each change that is introduced is typically small, pinpointing the specific change that introduced a defect can be done quickly. These questions, which relate to a step in the integration process, tell us what needs to be fixed to ensure a smooth integration into the shared codebase.

In addition to the questions posed throughout the integration process, CI is guided by a set of key principles. Among them are version control, build automation, and automated testing. Additionally, continuous deployment and continuous delivery have developed as best practices for keeping your application deployable at any point or even pushing your main codebase automatically into production whenever new changes are brought into it. This allows your team to move fast while keeping high quality standards that can be checked automatically.

Version Control

One of the key attributes of continuous integration is the practice of version control: the process of keeping multiple versions of files so that when a change is made it is possible to access previous revisions. All aspects related to the creation of the software should be under version control. In addition to the source code, database scripts, build and deployment scripts, documentation, libraries and configuration files, and compilers as well and many other aspects should all be under direct version control. By storing all these files, it becomes easier to recreate the testing environment and production environments that the application runs on. By having everything that could possibly change at any point in the life of the project stored in a controlled manner, it allows you to recover an exact snapshot of the state of the entire system should anything go wrong.

Build Automation

Build automation is the process of taking source code and other artifacts created by developers and turning them into a software product that can be executed and used by customers. The build may include the following steps:

• Compiling source code
• Compressing target files into archives
• Generating software installers
• Running automated tests on the build
• Automatically deploying software on a target environment

The automated build process can help development teams by standardizing builds and documenting and codifying important aspects of a software project such as third-party dependencies, artifacts related to the build, tests, and deployment details.

There are generally two types of build processes: the full build and the incremental build. The full build will build the entire software application from the source files. It takes in the full project, checks dependencies, compiles all source code and builds the target software components to create the complete build artifact. The incremental build takes an existing build, checks what has changed in the source code and artifacts since the last time the software was built, and compiles or rebuilds any file that has changed, or which depends on a resource that has changed. Other files will remain unchanged and will be reused from the previous build. Incremental builds are faster and more efficient, but less reliable.