Continuous Integration (CI) is a software development technique in which developers use a version control system, like Git, and push code changes daily, multiple times a day. Instead of building out features in isolation and integrating them at the end of the development cycle, a more iterative approach is employed.

Each merge triggers an automated set of scripts to automatically build and test your application. These scripts help decrease the chances that you introduce errors in your application.

If some of the scripts fail, the CI system doesn't progress to further stages, issuing a report that developers can use to promptly assess what was wrong and resolve the problem.

Benefits:

• Improved developer productivity: CI frees developers from manual tasks and the pain of integrating their code with other system parts. They can instead focus on programming the logic that delivers the business's desired features.
• Deliver working software more often: CI is a way for your team to build and test every source code change automatically. This fast CI feedback loop delivers more value to customers than teams that rely on manual integrations of each other's work. This foundation enables a software delivery process to be efficient, resilient, fast, and secure.
• Find bugs earlier, and fix them faster: The automated testing process can include different checks, like verifying code correctness, validating application behavior, or making sure the coding style follows industry-standard conventions. A CI tool provides instant feedback to developers on whether the new code they wrote works or introduces bugs or regression in quality. Mistakes that are caught early on are the easiest to fix.

CI Pipeline

Typical Dev Workflow

1. A developer from the team creates a new branch of code in Github, performs changes in the code, and commits them.
2. When the developer pushes work to GitHub, the CI system builds the code on its servers and runs the automated test suite.
3. Suppose the CI system detects any error in the CI pipeline. In that case, the developer who pushed the code gets a notification, for example, via email, and the status of CI changes to red. The developer is responsible for analyzing what went wrong and fixing the problem.
4. Otherwise, if the status is green and all goes well, the pipeline moves to its next stage, which usually involves deploying a new version of the application to a staging server. This new version can be used internally by the Quality Assurance (QA) team to verify the changes in a production-like environment.

Style Guides

Style guides exist to make code consistent and predictable so continuous integration and automated testing can reliably verify, enforce, and scale code quality without human judgment.

Style guides make code machine-verifiable

CI pipelines rely on tools that cannot interpret intent, only structure.

Style guides define:

• Naming conventions
• File organization
• Component patterns
• Testing conventions

This allows tools like:

• ESLint
• Prettier