About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Continuous Integration

What is the purpose of Continuous Integration (CI)?

To avoid last minute integration surprises. CI tries to break the integration process into small, frequent steps to avoid big bang integration as it leads to integration nightmare.

If people are afraid to check-in frequently, your Continuous Integration process is not working.

CI process goes hand in hand with Collective Code Ownership and Single-Team attitude.

CI is the manifestation of “Stop the Line” culture from Lean Manufacturing.

What are the advantages of Continuous Integration?

  • Helps to improve the quality of the software and reduce the risk by giving quicker feedback.
    • Experience shows that a huge number of bugs are introduced during the last-minute code integration under panic conditions.
  • Brings the team together. Helps to build collaborative teams.
  • Gives a level of confidence to checkin code more frequently that was once not there.
  • Helps to maintain the latest version of the code base in always shippable state. (for testing, demo, or release purposes)
  • Encourages lose coupling and evolutionary design.
  • Increase visibility and acts as an information radiator for the team.
  • By integrating frequently, it helps us avoid huge integration effort in the end.
  • Helps you visualize various trends about your source code. Can be a great starting point to improve your development process.

Is Continuous Integration the same as Continuous build?

No, continuous build only checks if the code compiles and links correctly. Continuous Integration goes beyond just compiling.

  • It executes a battery of unit and functional tests to verify that the latest version of the source code is still functional.
  • It runs a collection of source code analysis tools to give you feedback about the Quality of the source code.
  • It executes you packing script to make sure, the application can be packaged and installed.

Of course, both CI and CB should:

  • track changes,
  • archive and visualize build results and
  • intelligently publish/notify the results to the team.

How do you differentiate between Frequent Versus Continuous Integration?

Continuous means:

  • As soon as there is something new to build, its built automatically. You want to fail-fast and get this feedback as rapidly as possible.
  • When it stops becoming an event (ceremony) and becomes a behavior (habit).

Merge a little at a time to avoid the big cost at full integration at the end of a project. The bottom line is fail-fast & quicker feedback.

Can Continuous Integration be manual?

Manual Continuous Integration is the practice of frequently integrating with other team members’ code manually on developer’s machine or an independent machine.

Because people are not good at being consistent and cannot do repetitive tasks (its a machine’s job), IMHO, this process should be automated so that you are compiling, testing, inspecting and responding to feedback.

What are the Pre-Requisites for Continuous Integration?

This is a grey area. Here a quick list is:

  • Common source code repository
  • Source Control Management tool
  • Automated Build scripts
  • Automated tests
  • Feedback mechanism
  • Commit code frequently
  • Change of developer mentality, .i.e. desire to get rapid feedback and increase visibility.

What are the various steps in the Continuous Integration build?

  • pulling the source from the SCM
  • generating source (if you are using code generation)
  • compiling source
  • executing unit tests
  • run static code analysis tools – project size, coding convention violation checker, dependency analysis, cyclomatic complexity, etc.
  • generate version control usage trends
  • generate documentation
  • setup the environment (pre build)
  • set up third party dependency. Example: run database migration scripts
  • packaging
  • deployment
  • run various regression tests: smoke, integration, functional and performance test
  • run dynamic code analysis tools – code coverage, dead-code analyzer,
  • create and test installer
  • restore the environment (post build)
  • publishing build artifact
  • report/publish status of the build
  • update historical record of the build
  • build metrics – timings
  • gather auditing information (i.e. why, who)
  • labeling the repository
  • trigger dependent builds

Who are the stakeholders of the Continuous Integration build?

  • Developers
  • Testers [QA]
  • Analysts/Subject Matter Experts
  • Managers
  • System Operations
  • Architects
  • DBAs
  • UX Team
  • Agile/CI Coach

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, Some System tests which are hard to automate.

What are the different types of builds that make Continuous Integration and what are they based on?

We break down the CI build into different builds depending on their scope & time of feedback cycle and the target audience.

1. Local Developer build :
1.a. Job: Retains the environment. Only compiles and tests locally changed code (incremental).
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. (If it takes longer, then you could make the build incremental, not start on a clean environment)
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/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 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]

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

    Licensed under
Creative Commons License