Csc/ece 517 fall 2007/wiki3 p1

From Expertiza_Wiki
Revision as of 23:32, 18 November 2007 by Pjgandhi (talk | contribs)
Jump to navigation Jump to search

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 1 developer is examining the code at a point of time increases the chances that weak areas in the system would be identified .

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=Csc/ece_517_fall_2007/wiki3_p1&oldid=9048"