Continuous Integration

3,211 views

Published on

A presentation given by me on CI in Aftek

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,211
On SlideShare
0
From Embeds
0
Number of Embeds
137
Actions
Shares
0
Downloads
156
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Continuous Integration

  1. 1. Continuous Integration: Improving Software Quality and Reducing Risk Preetam Palwe Aftek Limited
  2. 2. One more title  <ul><li>Do you love bugs ? </li></ul><ul><li>Or </li></ul><ul><li>Are you in love with QC members? </li></ul><ul><li>… [Courtesy: Smita N] </li></ul>
  3. 3. Agenda <ul><li>Motivation </li></ul><ul><li>Practices </li></ul><ul><li>Advantages </li></ul><ul><li>The road ahead </li></ul><ul><li>Q&A </li></ul>
  4. 4. Motivation <ul><li>“ Enter laptops, enter boards and put together with code, all teams have come together in one abode. Integration in progress.” </li></ul><ul><li>… taken from an article published in AForce March 2008 </li></ul><ul><li>Admin Utility </li></ul><ul><ul><li>User now can be associated with the profile and action like send sms, call to a specific person or play welcome message on entering in the home. </li></ul></ul><ul><ul><li>The UI part for above feature is implemented by XYZ. And backend part is implemented by PQR. Integration of the same is pending and will integrate on next week. </li></ul></ul><ul><li>… taken from an weekly status report sent in 1 st week of March 2008 </li></ul><ul><li>So ??? </li></ul>
  5. 5. Motivation <ul><li>Integration is an EVENT !!! </li></ul><ul><li>Can we have something like following? </li></ul><ul><li>Image Courtesy: Book on CI by PMD </li></ul>
  6. 6. What is CI? <ul><li>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. </li></ul><ul><li>… taken from Martin Fowlers article on CI </li></ul>
  7. 7. Agile manifesto <ul><li>Individuals and interactions <OVER> processes and tools </li></ul><ul><li>Working software <OVER> comprehensive documentation </li></ul><ul><li>Customer collaboration <OVER> contract negotiation </li></ul><ul><li>Responding to change <OVER> following a plan </li></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul>
  8. 8. Agile principles <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. </li></ul><ul><li>Business people and developers must work together daily throughout the project. </li></ul><ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul>
  9. 9. Agile principles (contd) <ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul><ul><li>Working software is the primary measure of progress. </li></ul><ul><li>Agile processes promote sustainable development. </li></ul><ul><li>The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>Simplicity—the art of maximizing the amount of work not done—is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  10. 10. Adaptive (agile) vs Predictive (plan-driven) <ul><li>Agile home ground </li></ul><ul><ul><li>Low criticality </li></ul></ul><ul><ul><li>Senior developers </li></ul></ul><ul><ul><li>Requirements change very often </li></ul></ul><ul><ul><li>Small number of developers </li></ul></ul><ul><ul><li>Culture that thrives on chaos </li></ul></ul><ul><li>Plan-driven home ground </li></ul><ul><ul><li>High criticality </li></ul></ul><ul><ul><li>Junior developers </li></ul></ul><ul><ul><li>Requirements don't change too often </li></ul></ul><ul><ul><li>Large number of developers </li></ul></ul><ul><ul><li>Culture that demands order </li></ul></ul>
  11. 11. Extreme programming <ul><li>Form of agile software development </li></ul><ul><ul><li>Traditional software engineering practices taken to so-called &quot;extreme&quot; levels—leads to a development process that is more responsive to customer needs (&quot;agile&quot;) than traditional methods, while creating software of better quality. </li></ul></ul><ul><li>Values and/or principles </li></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Feedback </li></ul></ul><ul><ul><li>Courage </li></ul></ul><ul><ul><li>Respect </li></ul></ul><ul><li>Activities </li></ul><ul><ul><li>Coding </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Listening </li></ul></ul><ul><ul><li>Designing </li></ul></ul>
  12. 12. XP practices <ul><li>Fine scale feedback </li></ul><ul><ul><li>Pair programming </li></ul></ul><ul><ul><li>Planning Game </li></ul></ul><ul><ul><li>Test driven development </li></ul></ul><ul><ul><li>Whole team </li></ul></ul><ul><li>Continuous process </li></ul><ul><ul><li>Continuous Integration </li></ul></ul><ul><ul><li>Refactoring or Design Improvement </li></ul></ul><ul><ul><li>Small Releases </li></ul></ul><ul><li>Shared understanding </li></ul><ul><ul><li>Coding Standards </li></ul></ul><ul><ul><li>Collective Code Ownership </li></ul></ul><ul><ul><li>Simple Design </li></ul></ul><ul><ul><li>System Metaphor </li></ul></ul><ul><li>Programmer welfare </li></ul><ul><ul><li>Sustainable pace </li></ul></ul>
  13. 13. Coming back to CI <ul><li>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. </li></ul><ul><li>… taken from Martin Fowlers article on CI </li></ul>
  14. 14. Practices <ul><li>Maintain a single source repository </li></ul><ul><ul><li>Keep everything needed for build in CVS </li></ul></ul><ul><ul><li>E.g. code, database schema, IDE configuration, test scripts etc but not application server and jdk. Even no build artifacts! </li></ul></ul><ul><ul><li>Keep branches to minimum (in size and in lifetime) </li></ul></ul>
  15. 15. Practices <ul><li>Automate the build </li></ul><ul><ul><li>From compilation to deployment </li></ul></ul><ul><ul><li>Configure the build: </li></ul></ul><ul><ul><ul><li>Master build on server </li></ul></ul></ul><ul><ul><ul><li>Developers build from IDE </li></ul></ul></ul><ul><ul><ul><li>Build with test, without test or different set of tests! </li></ul></ul></ul>
  16. 16. Processes <ul><li>Make your build self-testing </li></ul><ul><ul><li>High degrees of automated tests suits to check larger code base </li></ul></ul><ul><ul><li>Though TDD not mandatory but its helpful </li></ul></ul><ul><ul><li>Test case failed: build failed! </li></ul></ul><ul><ul><li>XUnit tools like JUnit and/or end-to-end testing tools like selenium </li></ul></ul><ul><ul><li>Imperfect tests, run frequently, are much better than perfect tests that are never written at all. </li></ul></ul>
  17. 17. Processes <ul><li>Everyone commits every day </li></ul><ul><ul><li>Every commit shall succeed the build </li></ul></ul><ul><ul><li>Frequent commits: small work packets for developer </li></ul></ul><ul><ul><li>Mentoring and practice is the key  </li></ul></ul>
  18. 18. Processes <ul><li>Every commit should build the mainline on an integration machine </li></ul><ul><ul><li>You shouldn’t go home until the mainline build has passed with any commits you’ve added late in the day! </li></ul></ul><ul><ul><li>Don’t check in untested / broken code </li></ul></ul><ul><ul><li>Don’t check in when build is broken </li></ul></ul><ul><ul><li>The whole point of CI is to detect integration errors as soon as possible </li></ul></ul><ul><ul><li>Peers pressure within team ensures policies are followed  </li></ul></ul>
  19. 19. Processes <ul><li>Keep the build fast </li></ul><ul><ul><li>XP guideline: 10 mins build! </li></ul></ul><ul><ul><li>Staged build (build pipeline) </li></ul></ul><ul><ul><ul><li>Commit build </li></ul></ul></ul><ul><ul><ul><li>Secondary build </li></ul></ul></ul><ul><ul><ul><li>Performance build </li></ul></ul></ul><ul><ul><li>If secondary build fails move the test case to commit build </li></ul></ul><ul><ul><li>Parallel builds </li></ul></ul>
  20. 20. Processes <ul><li>Test in a clone of production environment </li></ul><ul><ul><li>Every environmental difference results in a risk: what happens under test wont happen in production </li></ul></ul><ul><ul><li>E.g. Same IP, port, machine, hardware, os etc </li></ul></ul><ul><ul><li>Virtualization can help </li></ul></ul>
  21. 21. Processes <ul><li>Make it easy for anyone to get the latest executable </li></ul><ul><ul><li>Its very hard to specify what you want in advance and be correct; people find it much easier to see something that’s not quite right and say how it needs to be changed </li></ul></ul><ul><ul><li>Many executables in a day so not in CVS </li></ul></ul>
  22. 22. Processes <ul><li>Everyone can see what's happening </li></ul><ul><ul><li>CI is all about communication </li></ul></ul><ul><ul><li>Build status indicators: lava lamps, colored labels, hooters, mails </li></ul></ul><ul><ul><li>Build history and build status reports indicates the project “health” </li></ul></ul><ul><ul><li>Matrices are helpful to guide project management </li></ul></ul>
  23. 23. Processes <ul><li>Automate deployment </li></ul><ul><ul><li>Use deployment pipeline </li></ul></ul><ul><ul><li>Automated rollback </li></ul></ul>
  24. 24. Advantages <ul><li>Reduces risk </li></ul><ul><ul><li>Integration is predictable now </li></ul></ul><ul><ul><li>We know where we are, what works, what doesn't work, how many outstanding bugs are there </li></ul></ul><ul><li>Makes dramatically easier to find and remove bugs </li></ul><ul><ul><li>Bugs - these are the nasty things that destroy confidence and mess up schedules and reputations. Bugs in deployed software make users angry with you. Bugs in work in progress get in your way, making it harder to get the rest of the software working correctly. </li></ul></ul><ul><ul><li>Broken windows syndrome </li></ul></ul><ul><li>Break Barriers between customer and development </li></ul><ul><ul><li>Add more features rapidly, give rapid feedback </li></ul></ul>
  25. 25. The road ahead <ul><li>Just give it a try </li></ul><ul><li>Start with commit build </li></ul><ul><li>Add some automated test </li></ul><ul><li>Use deployment pipeline </li></ul><ul><li>Speed up the build </li></ul><ul><li>Integrate with anything and everything available like project management tools, bug trackers, code analysis tools etc </li></ul>
  26. 26. Deployment pipeline <ul><li>Image Courtesy: Paper on Deployment Pipeline by Dave Farley </li></ul>
  27. 27. Cruise control <ul><li>Open source CI toolkit from ThoughtWorks </li></ul><ul><ul><li>Support for different plugins like email, source control, builder, ant etc </li></ul></ul><ul><ul><li>Support of web ui for build status </li></ul></ul><ul><ul><li>Integrate with many code analysis tools, scm tools, build tools, reporting tools etc </li></ul></ul>
  28. 28. Cruise control <ul><li>Image Courtesy: CC documentation on cc website </li></ul>
  29. 29. References <ul><li>http://martinfowler.com/articles/continuousIntegration.html </li></ul><ul><li>http://en.wikipedia.org/wiki/Agile_software_development </li></ul><ul><li>http://en.wikipedia.org/wiki/Extreme_Programming </li></ul><ul><li>http:// cruisecontrol.sourceforge.net / </li></ul>
  30. 30. Q&A <ul><li>Thanks! </li></ul>

×