CSC/ECE 517 Fall 2011/ch6 6f va: Difference between revisions
No edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
Continuous Integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. It is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. | Continuous Integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. It is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. | ||
Continuous Integration is about integrating changes to the development project continuously and automatically. These changes usually come in form of modifications and additions to the source code. When we keep them as small as possible and automatically run all checks available (starting from the compilation process and up to the full test routines), we can detect most breaking issues whenever they are introduced. Since the changes are small, it is much easier to isolate and fix the root cause | Continuous Integration is about integrating changes to the development project continuously and automatically. These changes usually come in form of modifications and additions to the source code. When we keep them as small as possible and automatically run all checks available (starting from the compilation process and up to the full test routines), we can detect most breaking issues whenever they are introduced. Since the changes are small, it is much easier to isolate and fix the root cause | ||
Continuous integration helps to achieve this by reducing development friction involved in project integration. This is done with the help of: | |||
* Version Control Systems that allow large and distributed teams to work together on the same project, while sending their code changes (commits) to the central server. Each commit is stored on the server and could be reviewed or reverted. | |||
* Build Automation that is basically about build tools and scripts that allow to start the complete integration build on a local machine with a single mouse-click. | |||
* Unit Tests ensuring that code stays stable through all the changes (this normally comes with the Test-Driven Development practices). | |||
* Code Quality Tests that consistently enforce development guidelines accepted by the team. | |||
* Regular Commits by developers that reduce amount of change involved in every integration. | |||
* Integrating Every Commit (as soon as it comes) on a central server allows to detect any compilation failures or broken tests immediately. Also this is the best way to deal with "but it works on my machine" problem. | |||
* Publishing Integration Results that get created along with the build project might simplify getting feedback from people outside of the development team. Examples of these results are: unit test results, performance metrics, install packages, code quality reports etc. | |||
==Why Continuous Integration?== | ==Why Continuous Integration?== | ||
==Practices== | ==Practices== | ||
Revision as of 20:56, 17 November 2011
Continous Integration We keep our code ready to ship.
Definition
Continuous Integration is a software development practice where members of a team integrate their work frequently. This approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly
We keep our code ready to ship
Introduction
Software development landscape has changed lately. In the previous years, one third of the development time was spent on writing exhaustive specifications, which then went through intensive reviews, and then spend months before something was released; in the last years the focus was changed. Nowadays the specs are sketches at most, and releases are at least twice a month in order to get rapid feedback from the customer, allowing for a more focused product. The big question is though: how can we developers adapt to the new world?
Continuous Integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. It is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Continuous Integration is about integrating changes to the development project continuously and automatically. These changes usually come in form of modifications and additions to the source code. When we keep them as small as possible and automatically run all checks available (starting from the compilation process and up to the full test routines), we can detect most breaking issues whenever they are introduced. Since the changes are small, it is much easier to isolate and fix the root cause
Continuous integration helps to achieve this by reducing development friction involved in project integration. This is done with the help of:
- Version Control Systems that allow large and distributed teams to work together on the same project, while sending their code changes (commits) to the central server. Each commit is stored on the server and could be reviewed or reverted.
- Build Automation that is basically about build tools and scripts that allow to start the complete integration build on a local machine with a single mouse-click.
- Unit Tests ensuring that code stays stable through all the changes (this normally comes with the Test-Driven Development practices).
- Code Quality Tests that consistently enforce development guidelines accepted by the team.
- Regular Commits by developers that reduce amount of change involved in every integration.
- Integrating Every Commit (as soon as it comes) on a central server allows to detect any compilation failures or broken tests immediately. Also this is the best way to deal with "but it works on my machine" problem.
- Publishing Integration Results that get created along with the build project might simplify getting feedback from people outside of the development team. Examples of these results are: unit test results, performance metrics, install packages, code quality reports etc.