Csc/ece 517 fall 2007/wiki3 p1: Difference between revisions
No edit summary |
No edit summary |
||
Line 50: | Line 50: | ||
*'''Ease Of Ensuring Adherence To Standard Coding GuideLines''' | *'''Ease Of Ensuring Adherence To Standard Coding GuideLines''' | ||
A coding standard is a set of guidelines that developers need to follow. Without an automated way to check whether the code written by developers is adhering to standard coding guidelines it can be very difficult to ensure the consistency of code written by developers working on different aspect s of the system. Continuous Integration can automate this process by running a script that compares the source code against the established standard whenever a change is applied. | A coding standard is a set of guidelines that developers need to follow. Without an automated way to check whether the code written by developers is adhering to standard coding guidelines it can be very difficult to ensure the consistency of code written by developers working on different aspect s of the system. Continuous Integration can automate this process by running a script that compares the source code against the established standard whenever a change is applied. | ||
*'''Automated Tests''' | |||
Developers usually write tests using some framework such as JUnit or NUnit. Such tests can be automatically executed from the build scripts every time the application is built. Since continuous integration requires the application to be built every time there is a change in the existing system , the tests are automatically executed from the build scripts to ensure that the system can successfully accommodate the new changes . Thus continuous integration helps to automate the tests. | |||
*'''Bugs Removed Quickly''' | |||
Bugs in software are cumulative. The greater the number of bugs the harder it is to fix them . In continuous integration the system is compiled frequently. So errors are discovered in the system incrementally and therefore are easy to fix. One doesn’t need to look beyond the changes made to the system after the last successful build to locate the bug in the system. This drastically reduces reduces the time spent in debugging the system. |
Revision as of 23:43, 18 November 2007
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.
Continuous Integration
What Is Continuous Integration?
Definition 1[1]
Continuous Integration is a process that yields executable releases that grow in functionality at every release. These releases help the management to identify risks and measure progress and quality .
Definition2[2]
Continuous integration is a software engineering term describing a process that completely rebuilds and tests an application frequently.Continuous integration is accomplished via a serialized build process. At the completion of a task, the developer (or development pair) takes a build token and runs the build process, including tests. If the tests pass, the task can be committed to the source code repository and release the token.
Definition 3[3]
Continuous integration is the name that emerged in the extreme programming community for the software engineering practice of immediately committing every change, no matter how small, to a revision control system. Other developers should always work with the latest version of the codebase.
Definition 4[4]
A central repository for all members of a team, containing: o the latest code (at least) o the latest executables An automated process for building and testing all project assets that: o can be run many times a day o is self sufficient
Advantages Of Continuous Integration
- Latest Code Version For Developers
Entire code is cleaned compiled and built everyday .The final result of the system is updated everyday to reflect the changes made everyday to the system by the code that has been newly checked in. This allows developers and testers of the system to get working software to use as frequently as possible. And in turn this also facilitates further development of the system and encourages more enhancements to the system.
- Assistance In Refactoring
Refactoring is the process of changing the system in a way that doesn’t change the way the system appears to the user but makes the system easier to structure and modify for the development team. In continuous integration the system can be inspected at regular intervals of time to identify the potential areas where refactoring is needed and the fact that more than one developer is examining the code at a point of time increases the chances that weak areas in the system would be identified .
- Ease Of Ensuring Adherence To Standard Coding GuideLines
A coding standard is a set of guidelines that developers need to follow. Without an automated way to check whether the code written by developers is adhering to standard coding guidelines it can be very difficult to ensure the consistency of code written by developers working on different aspect s of the system. Continuous Integration can automate this process by running a script that compares the source code against the established standard whenever a change is applied.
- Automated Tests
Developers usually write tests using some framework such as JUnit or NUnit. Such tests can be automatically executed from the build scripts every time the application is built. Since continuous integration requires the application to be built every time there is a change in the existing system , the tests are automatically executed from the build scripts to ensure that the system can successfully accommodate the new changes . Thus continuous integration helps to automate the tests.
- Bugs Removed Quickly
Bugs in software are cumulative. The greater the number of bugs the harder it is to fix them . In continuous integration the system is compiled frequently. So errors are discovered in the system incrementally and therefore are easy to fix. One doesn’t need to look beyond the changes made to the system after the last successful build to locate the bug in the system. This drastically reduces reduces the time spent in debugging the system.