Csc/ece 517 fall 2007/wiki3 p1

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]

Continuous Integration is:
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 

Definition 5[[5]]

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. 

Definition 6[[6]

Continuous Integration (CI) is the practice of periodically executing Automated Build Scripts (ABS), preferably in short intervals.
There are two flavors of this practice. The first flavor, mostly applied by early XP practitioners states that the system is built 
by one developer at any given time. In this flavor of CI Automated Build Scripts are still required, but kicking off the build
happens manually. Since this version relies heavily on the entire team to be co-located, it does not scale well in distributed
agile projects. The second flavor of CI relies on a computer background process to poll the code repository in short intervals
and automatically trigger the build process if it detects any changes since the last build. In this version of CI, the developer
is only responsible to build locally and check-in the code. This model is better suited for highly scalable agile teams because
of its reliance on automated asynchronous processes to trigger the build. This gives distributed teams an early feedback on the 
status of the system and therefore it enables dislocated team members and managers to have the same quick feedback as the team itself. 

Definition 7[[7]]

Continuous integration allows that team to measure their progress in compile-able working code. It gives the team instant feedback
on the health of the build and the state of code repository. Setting up continuous integration also sets the team up for reaping
the value of automated testing once they grow enough to include that in the agile arsenal

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. 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

]

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

Definition 1

“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. 

Definition 2[8]

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.

Definition 3[9]

Collective ownership is an agile methodology in which 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. 

Definition 4[10]

Collective code ownership is a practice that abandons any notion of individual ownership of modules. The code base is owned by
the entire team and anyone may make changes anywhere. 

Definition 5[11]

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

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

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. 

Scenario 2

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. 

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 who is missing in Collective Code Ownership.

• 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 as all developers put their thoughts into the design . 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.

Conclusion

Despite the controversies Agile methodologies like collective code ownership and continuous integration are here to stay for long due to rapidly changing requirements and desirability for a greater development speed.

References

1. http://en.wikipedia.org/wiki/Extreme_Programming_Practices
2. http://www.javaworld.com/javaworld/jw-06-2007/jw-06-awci.html?page=3
3. http://en.wikipedia.org/wiki/Continuous_integration
4. http://en.wikipedia.org/wiki/Tinderbox_%28software%29
5. http://www.mozilla.org/tinderbox.html
6. http://www.mozilla.org/projects/tinderbox/
7. http://www.commandinformation.com/blog/?p=30
8. http://www.webopedia.com/TERM/E/Extreme_Programming.html
9. http://www.ibm.com/developerworks/rational/library/sep05/lee/
10. http://www.extremeprogramming.org/rules/collective.html
11. http://martinfowler.com/bliki/CodeOwnership.html
12. http://weblogs.asp.net/ralfw/archive/2006/04/01/441639.aspx
13. http://buzzfrog.blogs.com/zabrak/2007/01/continuous_inte.html
14. http://www.jacoozi.com/blog/?p=18
15. http://www.gungfu.de/facts/wiki/Main/CodeOwnership
16. http://news.thomasnet.com/IMT/archives/2006/11/agile_methodologies_projects_popularity_complications.html?t=archive
17. http://www.versionone.com/surveyresults.asp