Continuous Integration := CI is a concept and it was introduced to prevent integration issues. In CI, developers commit the code periodically, and every commit is built. Automated tests verify the system integrity. It helps in the incremental development and periodic delivery of the working software.
When CI is not available, development teams or developers make changes to code and then all the code changes are brought together and merged. Sometimes, this merge is not very simple; it involves the integration of lots of conflicting changes.
Often, after integration, weird bugs crop up and a working module may start to fail, as it involves a complete rework of numerous modules. Nothing goes as planned and the delivery is delayed. As a result, the predictability, cost, and customer service are affected.
CI requires a listener tool to keep an eye on the version control system for changes. Whenever a change is committed, this tool automatically compiles and tests the application (sometimes it creates a WAR file, deploys the WAR/EAR file, and so on).
If compilation fails, or a test fails, or deployment fails, or something goes wrong, the CI tool immediately notifies the concerned team so that they can fix the issue.
Tools such as Sonar and FindBugs can be added to the build process to track the code quality, and they automatically monitor the code quality and code coverage metrics. Often, CI tools have the ability to present dashboards pertaining to quality metrics.
In a nutshell, CI tools enforce code quality, predictability, and provide quick feedback, which reduces the potential risk. CI helps to increase the confidence in the build. A team can still write very poor quality code, even test poor quality code, and the CI will not care.
Numerous CI tools are available on the market, such as Go, Bamboo, TeamCity, CruiseControl, and Jenkins. However, CruiseControl and Jenkins are the widely used ones.
When CI is not available, development teams or developers make changes to code and then all the code changes are brought together and merged. Sometimes, this merge is not very simple; it involves the integration of lots of conflicting changes.
Often, after integration, weird bugs crop up and a working module may start to fail, as it involves a complete rework of numerous modules. Nothing goes as planned and the delivery is delayed. As a result, the predictability, cost, and customer service are affected.
CI requires a listener tool to keep an eye on the version control system for changes. Whenever a change is committed, this tool automatically compiles and tests the application (sometimes it creates a WAR file, deploys the WAR/EAR file, and so on).
If compilation fails, or a test fails, or deployment fails, or something goes wrong, the CI tool immediately notifies the concerned team so that they can fix the issue.
Tools such as Sonar and FindBugs can be added to the build process to track the code quality, and they automatically monitor the code quality and code coverage metrics. Often, CI tools have the ability to present dashboards pertaining to quality metrics.
In a nutshell, CI tools enforce code quality, predictability, and provide quick feedback, which reduces the potential risk. CI helps to increase the confidence in the build. A team can still write very poor quality code, even test poor quality code, and the CI will not care.
Numerous CI tools are available on the market, such as Go, Bamboo, TeamCity, CruiseControl, and Jenkins. However, CruiseControl and Jenkins are the widely used ones.
No comments:
Post a Comment