What is the purpose of Continuous Integration?
1. To avoid last minute integration surprises. Big bang integration leads to integration nightmare. Continuous Integration tries to break that by doing it in small steps.
2. Helps in improving quality of the software and reducing the risk by giving quicker feedback.
3. Brings the team together. Helps in building collaborative teams.
4. Continuous Integration gives a level of confidence to checkin code more frequently that was once not there. So if people are afraid to check in, your Continuous Integration process is not working. Continuous Integration process goes hand in hand with Collective code ownership and one team attitude.

Is Continuous Integration the same as Continuous build?
No. Continuous build only checks if the code compiles. But Continuous Integration goes beyond just compiling. It executes a bunch of unit and functional tests to verify that the software built is functioning the way it should.

How do you differentiate between Frequent Versus Continuous Integration?
As soon as there is something new to build, its built automatically. But it has to be using a clean environment. This gives the feedback as quickly as possible to respond fast.
When it stops becoming an event and becomes behavior.
Merge a little at a time to avoid the big cost at full integration at the end of a project
The bottom line is quicker feedback.

Can Continuous Integration be manual?
Manual Continuous Integration is the practice of frequently integrating with other team members manually.
I feel it should be an automated process so that you are compiling, testing, inspecting, responding to feedback. Because people are not good at being consistent and cannot do repetitive tasks (i.e. its a machine‘s job)

Requisites for Continuous Integration?
There are lots of grey areas. But a quick list is:

• Common source code repository
• SCM tool
• Automated tests
• Build scripts of some type
• Feedback mechanism
• Commit code frequently
• Change of developer mentality, desire to do it. Reinforce thinking about Integration.

What is in a Continuous Integration build?

• pulling the source from the SCM
• compiling source
• executing unit tests
• deployment
• packaging
• labeling the repository
• generating and compiling source
• documentation (javadocs)
• source code metrics – static analysis, pmd, dependency analysis (jdepends), mccabe/cyclomatic complexity
• code coverage
• database – create the schema
• restoring the environment (pre/post build)
• reporting / publish status of the build
• historical record of the build
• functional test
• integration tests
• performance tests
• regression tests
• smoke test
• build metrics – timings
• artifact publishing (.ear, .jar, .zip)
• auditing information (i.e. why, who)
• creating installer

Who all are the stakeholders in the Continuous Integration build?

• developers
• testers [QA]
• analysts
• managers
• system operations
• architects
• DBAs

What is the scope of QA?
They help the team with automating the functional tests. They pick up the product from the nightly build and do other types of testing. For Ex: Exploratory testing, Mutation testing, System tests which are hard to automated [pulling out the network cord].

What are the different types of builds that make Continuous Integration and what are they based on?
Builds are usually based on their feedback cycle and target audience.

1. Local Developer build :
1.a. Job: Retains the environment and only compiles and tests changed code.
1.b. Feedback: less than 5 mins.
1.c. Stakeholders: Developer pair who runs the build
1.d. Frequency: Before checking in code
1.e. Where: On developer workstation/laptop

2. Smoke build :
2.a. Job: Compiles , Unit test , Automated acceptance and Smoke tests on a clean environment[including database].
2.b. Feedback: less than 10 to 15 mins.
2.c. Stakeholders: All the developers within a single team.
2.d. Frequency: With every checkin
2.e. Where: On a team‘s dedicated continuous integration server. [Multiple modules can share the server, if they have parallel builds]

3. Functional build :
3.a. Job: Compiles , Unit test , Automated acceptance and All Functional\Regression tests on a clean environment. Stubs out or mocks out other modules or systems.
3.b. Feedback: less than 1 hour.
3.c. Stakeholders: Developers , QA , Analysts in a given team
3.d. Frequency: Every 2 to 3 hours
3.e. Where: On a team‘s dedicated continuous integration server.

4. Cross module build :
4.a. Job: If your project has multiple teams, each working on a separate module, this build integrates on those modules and runs the functional build across all those modules.
4.b. Feedback: in less than 4 hr.
4.c. Stakeholders: Developers , QA , Architects , Manager , Analyst across the module team
4.d. Frequency: 2 to 3 times a day
4.e. Where: On a continuous integration server owned by all the modules. [Different from above]

5. Product build :
5.a. Job: Integrates all the code that is required to create a single product. Nothing is mocked or stubbed. [Except things that are not yet built]. Creates all the artifacts and publishes a deployable product.
5.b. Feedback: less than 10 hrs.
5.c. Stakeholders: Every one including the Project Management.
5.d. Frequency: Every night.
5.e. Where: On a continuous integration server owned by all the modules. [Same as above]

Adapt your own process/practice.
General Rule of Thumb: No silver bullet