Csc/ece 517 fall 2007/wiki3 p1

From Expertiza_Wiki
Revision as of 00:17, 19 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.
  • Clients build a program and send the status of the build to the server . The server then creates a build log that looks like:
tinderbox: tree: Application1
tinderbox: builddate: 1021331520
(...)
tinderbox: status: success
tinderbox: END
(full build log)
  • Tinderbox allows the developers to see at a a glance what Is currently going on in all aspects of the system. It prepares the HTML tree that show the status of various development variables.
Highlights Of TinderBox
  • History

Tinderbox shows a history of changes to code in Version Control System. So it is not compulsory to configure the Version Control System so that each programmer is mailed as and when there are changes in the system. Developers can see who is changing what part of the code at what time.

  • Debugging

When the builds/tests fail it is very easy to find out the person responsible for the failure. The person responsible is the one who checked in his code between the last successful build and the current build.This makes it easier to debug the code as you know exactly whose code is creating a problem. After the source tree is closed all check ins appear in grey color. So it is very easy to identify the checkinns made after the tree is closed.

  • Continual Development

The build/test logs in tinderbox are available at the click of a web link . Anyone who has a web browser can see that the build failed and identify the error message. Tinderbox doesn’t prevent any development process from occurring even when there are errors in builds/tests.If it is very important to allow development to occur even if tests fail developers can configure Tinderbox to ignore the results about the failing tests and to only be concerned about the tests that they need. Tinderbox only displays the current state of development.

  • Notice Boards

Message Of the Day can be used by the management and Notice Boards can be used by the developer to announce any of the major changes that they make to the system

Cruise Control-IBM Based Product

]

Reference: http://www.ibm.com/developerworks/rational/library/sep05/lee/

Working Of Cruise Control

The developer makes code changes in the desktop.SCM repository stores collective code changes for a team. Integration Build Server has Cruise Control Application. CruiseControl monitors SCM repository for changes. If there are new check ins it builds the application via Ant or Maven scripts , runs the JUnit test and reports the results of the build. It can send the results to the users via email or it can display these results on the website.

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