View source for Csc/ece 517 fall 2007/wiki3 p1

==Continuous Integration==

===What Is Continuous Integration?===

<u>'''Definition 1'''</u>[http://www.ibm.com/developerworks/rational/library/sep05/lee/]
<pre>
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 .
</pre>

<u>'''Definition2'''</u>[http://www.informit.com/guides/content.aspx?g=java&seqNum=302&rl=1]
<pre>
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.
</pre>

<u>'''Definition 3'''</u>[http://en.wikipedia.org/wiki/Continuous_integration]
<pre>
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.
</pre>
<u>'''Definition 4'''</u>[http://www.ibm.com/developerworks/rational/library/sep05/lee/]
<pre>
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 
</pre>
<u>'''Definition 5'''</u>[[http://martinfowler.com/articles/continuousIntegration.html]]
<pre>
Continuous Integration 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. Each integration is verified by an automated build 
(including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly
 reduced integration problems and allows a team to develop cohesive software more rapidly. 
</pre>

===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 ===
'''<i>
A Build process is needed that builds all files required.
'''
</i>
#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.
#There is a  build script(e.g. Ant ) determining how inputs combine to produce a single desired output.
#The build script is executed
#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:
<pre>
tinderbox: tree: Application1
tinderbox: builddate: 1021331520
(...)
tinderbox: status: success
tinderbox: END
(full build log)
</pre>
*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. 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.

*'''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====

[[Image:Cruise.jpg]]]

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.

==Collective Ownership==
<u>'''Definition 1'''</u>
<pre>
“Collective Ownership” as the term indicates means that   a team of members working and developing the code collectively own the code .
This methodology encourages everyone to work on all segments of the project.   Any developer can work on any part of the software system.
There isn’t only one person who has the knowledge of any particular area of the system. 
</pre>
<u>'''Definition 2'''</u>[http://en.wikipedia.org/wiki/Extreme_Programming_Practices]
<pre>
Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to
change any part of the code.
</pre>
<u>'''Definition 3'''</u>[http://www.webopedia.com/TERM/E/Extreme_Programming.html]
<pre>
Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to 
slow the project down. Code is changed when it needs to be changed without delay. 
</pre>
<u>'''Definition 4'''</u>[http://martinfowler.com/bliki/CodeOwnership.html]
<pre>
Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and
anyone may make changes anywhere. 
</pre>
<u>'''Definition 5'''</u>[http://www.gungfu.de/facts/wiki/Main/CodeOwnership]
<pre>
Collective code ownership means everyone accepts responsibility for the quality of the code. This means that everyone pulls in the
same direction or there is chaos, and that chaos bubbles to the surface very quickly
</pre>
===Advantages Of Collective Ownership===
*'''Speed Of Development'''
If a developer is working on some  module and he faces an error he is not able to resolve he can get the bug resolved by  other developers because in collective code ownership all developers are working on all parts of the code.

*'''Pair Programming reduces errors'''
Suppose a pair of developers is working on the same code. If the first program modifies the code the second programmer   ensures  that the changes that the first programmer is making don’t affect the working of the system in any adverse manner. He also ensures that his partner adheres to the standard coding guidelines that need to be followed. 

*'''Refactoring Facilitated'''
The entire team understands how to refactor the code.  Everyone knows what the code is like and takes good care to see to it that the refactored code doesn’t mess up with the earlier code.

*'''Team Spirit In Development''' 
In collective code ownership   each developer understands that he doesn’t own the code but only exercises a temporary authority over the code.  Also suppose a developer is working on two classes   simultaneously eg. Class A and Class B .   He has written  a part of code for Class A and he  is currently busy with Class B.  If any other developer needs class A urgently he himself can make changes and implement class A. He doesn’t need to wait for anyone. 

*'''Strong Learning Environment''' 
If a developer sees a chunk of code that  needs to be fixed or can be written more flexible than what it currently is , he can sit with the developer and discuss a better design thereby improving the developer’s code skill .

===Examples Of Collective Ownership===

====Scenario 1====
<pre>
In collective code ownership   each developer understands that he doesn’t own the code but only exercises a temporary authority over
code.  Also suppose a developer is working on two classes   simultaneously eg. Class A and Class B .   He has written  a part of code
for Class A and he  is currently busy with Class B.  If any other developer needs class A urgently he himself can make changes and
implement class A. He doesn’t need to wait for anyone. 
</pre>

====Scenario 2====
<pre>
Suppose a programmer  needs to modify someone else’s code .  He needs to ensure that no tests fail after he makes changes in the
code.  Tests for all classes are kept in a centralized test suite that has to be run whenever a developer  adds new code to the
system.  If there are tests that passed earlier but fail after the modification of code by the developer the developer has to discard
his changes and ask for assistance from someone who he knows would have better knowledge about the code. 
</pre>
==Are these methodologies widely practiced?==
The number of organizations using agile methodologies is on the rise. They key reason why people are adopting agile methodologies is adopting to changing requirements. Surveys show that the use of agile methodologies like collective class ownership and continuous integration is growing. From a recent survey conducted by Scott Amber on  4232 respondents about their Agile process implementations he concluded that
"Agile is not only growing in popularity, it is working incredibly well: so well, in fact, that it is fairly clear that adopting agile approaches is an incredibly low risk thing to consider."   
Respondents reported that:
*65 percent work in organizations that have adopted one or more agile development techniques,
*41 percent work in organizations that have adopted one or more agile methodologies,
60 percent report increased productivity,
66 percent report increased quality,
58 percent report improved stakeholder satisfaction. 

Reference:http://www.infoq.com/news/Survey-State-of-Agile-Practice

http://www.versionone.com/surveyresults.asp is a site showing the results of a survey concerning the use of Agile methodologies in organisations. 

==Are they controversial? Are there adherents of other design methodologies who consider them harmful?==
Like any new technology both these methodologies have been subject to controversy.  There are a lot of people who don’t  support collective code ownership and continuous integration.

*'''Collective  code ownership can lead to complete chaos'''  
Suppose Programmer X writes some piece of code and Programmer Y changes that code  without informing  Programmer X. But Programmer X is aware of certain subtleties that need to be handled that Programmer Y does not know .  The next day Programmer X looks at the code and sees an unexpected output. Thus there is an inherent risk of errors being introduced by programmers who change others’ code without knowing the dependencies or the subtleties of the code. 

*'''Specialization is important'''
As the number of software tools and technologies increases it becomes increasingly difficult for a single developer to grasp all new technologies  and to apply these technologies with profound understanding  to the development of the software project.  A team of developers is  mandatory with different skill sets. If people with different skill sets are to work together there arises the need for a person coordinating the entire team- the Architect


*'''Collective Ownership degenerates into no ownership as the number of people grows'''  
For small teams collective ownership may work but as the team size grows , all team members rarely stick around while the project is done.  So if a programmer commits his code into the repository and leaves the team for some reason chances are that no member of the team would take up the charge of that code afterwards. So there are a lot of people who prefer individual code ownership to collective code  ownership.

*'''Resistance to knowledge''' 
A very solid structure is often laid out in the beginning of the project . This structure becomes more and more resistant to knowledge as time passes. It becomes exceedingly difficult to fit in new functionality in the existing structure.

*'''Maintenance'''  
Continuous Integration means the code of one developer is incrementally integrated with the code of other developers. So the maintenance overhead for the application increases as there are multiple developers checking in code into the central repository at a given point of time.

*'''Backup  needed for continuous integration''' 
Some teams find the level of discipline required for continuous integration a bottleneck and would require a shift in the mindset. Programmers cant check in partially completed code in a project that uses continuous integration as this would cause an error in other people’s code.



==References==
#http://en.wikipedia.org/wiki/Extreme_Programming_Practices
#http://www.javaworld.com/javaworld/jw-06-2007/jw-06-awci.html?page=3
#http://en.wikipedia.org/wiki/Continuous_integration
#http://en.wikipedia.org/wiki/Tinderbox_%28software%29
#http://www.mozilla.org/tinderbox.html
#http://www.mozilla.org/projects/tinderbox/
#http://www.webopedia.com/TERM/E/Extreme_Programming.html
#http://www.ibm.com/developerworks/rational/library/sep05/lee/
#http://www.extremeprogramming.org/rules/collective.html
#http://martinfowler.com/bliki/CodeOwnership.html
#http://weblogs.asp.net/ralfw/archive/2006/04/01/441639.aspx
#http://buzzfrog.blogs.com/zabrak/2007/01/continuous_inte.html
#http://www.gungfu.de/facts/wiki/Main/CodeOwnership
#http://news.thomasnet.com/IMT/archives/2006/11/agile_methodologies_projects_popularity_complications.html?t=archive
#http://www.versionone.com/surveyresults.asp