Continuous integration (CI) is a software development practice where developers integrate code into a shared repository frequently, preferably multiple times a day. Each integration is verified by an automated build and test process to detect errors early. CI utilizes source control, automated builds, and tests to minimize the time between code changes being integrated and identified issues being found. While CI focuses on frequent code integration and testing, it does not require constant production releases or infrastructure automation. CI helps reduce integration problems and allows development teams to work together more efficiently.

1. Continuous Integration
Adin Scannell
CTO, Gridcentric
adin@gridcentric.com

2. WHO AM I?
• Adin Scannell – Co-founder & CTO, Gridcentric.
• Systems and virtualization guy.
• Responsible for technology vision
• (and the most annoying bugs).
• Email: adin@gridcentric.com

3. What’s continuous integration?

4. Classic “waterfall”
4

5. 5

6. %#@$!
%#@$!
%#@$!

7. Minimize time between phases
(and “distance” between developers)
Integrate continuously
Test continuously

9. “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.”
- Martin Fowler

10. Continuous Integration
Does require Does not require
• Source control • Constant releases
• Automated builds • (i.e. continuous delivery)
• Automated tests • No manual testing
• “Operations/Infrastructure as code”
• Agile, Scrum or Kanban

11. Source control

12. Commit early and often (develop incrementally)
Branch (when necessary) for features, releases
Perform integration across all branches

13. Source control tools
• Distributed: git, hg, bzr, bitkeeper, etc.
• “Classic”: cvs, svn, etc.
• A good branching and tagging strategy is important.

15. Build automation

16. Build every commit, or as frequently as possible
Have a consistent and easily replicable environment
Build all branches, or build from staging repos

17. Build tools
• The one true tool: Make
• Alternatives: Ant, mvn, scons
• On Windows: Visual Studio platform or Cmake
• Not a good build tool: your IDE

18. Test automation

19. Types: unit testing,
component testing,
coverage testing,
system and integration testing,
installation verification testing
Purposes: smoke tests, regression tests,
usability tests, performance tests,
security tests, acceptance tests
Methodologies: whitebox, blackbox, greybox

20. More tests are better, but figure out
what you delivers the most value to you.
When in doubt…..
Great idea: gate your main branches with tests.

21. Test tools
• Web: selenium
• C/C++: check, cunit, cppunit
• Python: pytest, nosetests
• Ruby: cucumber, rspec
• And lots more…
• Test frameworks are like a$$holes…

22. Continuous integration

23. Ties together builds and tests
Archives artifacts, test results, build logs, etc.
Automates triggers, pipelines
Allows for gating of merges, staging of changes

24. Continuous integration tools
• Jenkins (Hudson)
• TravisCI
• Cruise Control
• TeamCity
• Buildbot
• Bamboo
• Team Foundation Server
• Gerrit (reviews)

27. WORKFLOW

28. OpenStack (& Gridcentric) CI Workflow
4) Jenkins builds and
tests change 8) Jenkins pulls
(triggered) from github, builds,
Gerrit Jenkins
tests and publishes
5) Jenkins updates
changeset on Gerrit
3) Developer pushes 7) On approval 6) Another developer
changeset to Gerrit Gerrit merges and reviews the changeset
pushes to github
github
1) Developer pulls
from github
2) Developer writes
and tests code

29. How does openstack help me?

30. OpenStack cloud
OpenStack CI Workflow
Test
Test VM
Test
VM
Test VM
VM
Test Build
VM VM
4) Jenkins builds and Build
tests change VM 8) Jenkins pulls
(triggered) from github, builds,
Gerrit Jenkins
tests and publishes
5) Jenkins updates
changeset on Gerrit
3) Developer pushes 7) On approval 6) Another developer
changeset to Gerrit Gerrit merges and reviews the changeset
pushes to github
github
1) Developer pulls
from github
2) Developer writes
and tests code

31. Advanced continuous integration
• Leverage OpenStack to provide infrastructure.
• Build slaves, test slaves, infrastructure dependencies.
• Structure continuous integration tests as:
• Boot a base OpenStack image.
• Provision software using tool like Puppet / Chef.
• Run full tests.
• The same standardize procedures can be used to
stand up production environments.

32. Continuous delivery

33. Discussion questions
• Where is continuous integration easiest? Hardest?
• Which tests (unit/component/system) are critical?
• What are the biggest wins from CI?
• What are your favorite tools?
• How do you set a release cadence?
• How are larger features incorporated?