Continuous Integration: Difference between revisions
(→Tools) |
|||
| (12 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
=Internal= | =Internal= | ||
* [[ | * [[Continuous_Delivery#Overview|Continuous Delivery]] | ||
=Overview= | =Overview= | ||
'''Continuous Integration''' (CI) is an [[Agile Software Development#CI|agile software development]] practice that involves the following: | '''Continuous Integration''' (CI) is an [[Agile Software Development#CI|agile software development]] practice that involves the following: | ||
* Verification of the build integrity by checking if the source code can be pulled from repository | * Verification of the build integrity by checking if the source code can be pulled from the code repository, built, and packaged in form of immutable artifacts. | ||
* Running and validation of the unit tests | * Running and validation of the unit tests. The build process executes all unit tests created by developers and validates the test results. This step ensures that the source code was not broken as a side effect of the commit. | ||
* Running and validation of the integration tests. | * Running and validation of the integration tests. | ||
* | * Fast identification of problems and alerting the teams. | ||
* Packaging validated functionality into immutable artifacts and publication of those artifacts in delivery repositories. | |||
The essence of | The essence of continuous integration is to test every change, as soon as possible and provide rapid feedback to any problems that was introduced by commits. Continuous integration is primarily focused on asserting that the code compiles successfully, passes a body of unit and integration tests and can be packaged in a standard format. | ||
In the DevOps culture, CI is mandatory, and it performed automatically by a tool that runs automation scripts to eliminate all human intervention during the CI process. | In the DevOps culture, CI is mandatory, and it performed automatically by a tool that runs automation scripts to eliminate all human intervention during the CI process. | ||
The CI process requires a source code repository and a continuous integration server, that pulls code from the source repository and runs the build. Developers must check in as often as possible, every time a new piece of functionality that is verified by unit tests that pass is added. The build must be completely automated | The CI process requires a source code repository and a continuous integration server, that pulls code from the source repository and runs the build. Developers must check in as often as possible, every time a new piece of functionality that is verified by unit tests that pass is added. The build process must be completely automated, must run without human intervention, and it must be fast. | ||
Testing - especially the integration testing - must be done in an environment that is as close to production as possible. | Testing - especially the integration testing - must be done in an environment that is as close to production as possible, though there are situations when later stages that are part of [[Continuous Delivery|continuous delivery]] are better suited for complex high level testing in environments similar to production. | ||
The CI process provides rapid feedback on the state of the project, each unit test or integration test-verified assertion that gets broken by a commit is immediately shared with the entire development team. The process is run every time there's a commit, presumably many times a day. Every member of the team must be able to easily access the build results. | The CI process provides rapid feedback on the state of the project, each unit test or integration test-verified assertion that gets broken by a commit is immediately shared with the entire development team. The process is run every time there's a commit, presumably many times a day. Every member of the team must be able to easily access the build results. | ||
| Line 27: | Line 28: | ||
[[SonarQube]] is a static code analysis tool. | [[SonarQube]] is a static code analysis tool. | ||
<font color=darkkhaki>[[EvoA]]: every developer commits to the main line of development at least once a day. When a team uses continuous integration, merge conflicts arise and are resolved as quickly as they appear, at least once a day</font> | |||
=Continuous Integration Pipeline= | =Continuous Integration Pipeline= | ||
Latest revision as of 17:52, 3 July 2023
External
- Continuous Integration by Martin Fowler
Internal
Overview
Continuous Integration (CI) is an agile software development practice that involves the following:
- Verification of the build integrity by checking if the source code can be pulled from the code repository, built, and packaged in form of immutable artifacts.
- Running and validation of the unit tests. The build process executes all unit tests created by developers and validates the test results. This step ensures that the source code was not broken as a side effect of the commit.
- Running and validation of the integration tests.
- Fast identification of problems and alerting the teams.
- Packaging validated functionality into immutable artifacts and publication of those artifacts in delivery repositories.
The essence of continuous integration is to test every change, as soon as possible and provide rapid feedback to any problems that was introduced by commits. Continuous integration is primarily focused on asserting that the code compiles successfully, passes a body of unit and integration tests and can be packaged in a standard format.
In the DevOps culture, CI is mandatory, and it performed automatically by a tool that runs automation scripts to eliminate all human intervention during the CI process.
The CI process requires a source code repository and a continuous integration server, that pulls code from the source repository and runs the build. Developers must check in as often as possible, every time a new piece of functionality that is verified by unit tests that pass is added. The build process must be completely automated, must run without human intervention, and it must be fast.
Testing - especially the integration testing - must be done in an environment that is as close to production as possible, though there are situations when later stages that are part of continuous delivery are better suited for complex high level testing in environments similar to production.
The CI process provides rapid feedback on the state of the project, each unit test or integration test-verified assertion that gets broken by a commit is immediately shared with the entire development team. The process is run every time there's a commit, presumably many times a day. Every member of the team must be able to easily access the build results.
The build process should generate software that can be deployed at any time - a good release candidate.
Jenkins is a Continuous Integration engine that can be adapted to drive Continuous Delivery too.
SonarQube is a static code analysis tool.
EvoA: every developer commits to the main line of development at least once a day. When a team uses continuous integration, merge conflicts arise and are resolved as quickly as they appear, at least once a day
Continuous Integration Pipeline
Tools
The software that can be used to implement a continuous integration pipeline is known as a build server:
- Jenkins
- Team City
- Bamboo
- GitHub Actions
- Cloud Platform Services