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.
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
7. Minimize time between phases
(and “distance” between developers)
Integrate continuously
Test continuously
8.
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
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.
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
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)
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
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.
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?
Editor's Notes
Classical waterfall model. Doesn’t *really* exist in practice. All phases are necessary important pieces of the software development process.
Problem is that the longer you wait or the more you build up between phases, the more risk you take on.
In reality, you’ve always got a back arrow to all the previous steps. A poor design decision could come out in integration or test, forcing you to go back.
