Csc/ece 517 fall 2007/wiki3 p1

From Expertiza_Wiki
Revision as of 23:56, 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 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.

Stages In Continuous Integration

A Build process is needed that builds all files required.

  1. Build process needs some identification to find out what is to be built (class,package,project,etc).In Continuous Integration all checked in files will be built.
  2. There is a build script(e.g. Ant ) determining how inputs combine to produce a single desired output.
  3. The build script is executed
  4. The build results are reported through a simple log file. Any build process needs an environment to run. This is the software configuration management environment.

Examples

TinderBox-A Mozilla Based Product

  • Tinderbox is a software development tool that allows multiple developers to manage software builds and to synchronize changes in programs developed across multiple systems . It allows the developer to see which files are checked in ,which are checked out,which projects have been built successfully and which programs ran into compilation errors.
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=Csc/ece_517_fall_2007/wiki3_p1&oldid=9055"