Continuous Integration Introduction

2,354 views

Published on

Slides for introducing Continuous Integration into the software development process

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

  • Be the first to like this

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

No notes for slide

Continuous Integration Introduction

  1. 1. Continuous Integration
  2. 2. Agenda • Definition • CI Considerations • About tools • CI as a scheduling in the development process
  3. 3. Sources • Duvall, Matyas and Glover. Continuous integration improving software quality and reducing risk. Addison Wesley, 2007. • Martin Fowler. Continuous Integration. Available in http://www.martinfowler.com/articles/continuousIntegration .html • Schach, Stephen R. Object-Oriented and Classical Software Engineering Eighth Edition. Mc Graw Hill, 2010 • And so others…
  4. 4. Critical Issue Supporting the idea of creating systems to continuously build and test systems in response to changes in source control.
  5. 5. Continuous Integration (From Wikipedia) • Continuous Integration emerged in the Extreme Programming (XP) community • XP advocates Martin Fowler and Kent Beck first wrote about continuous integration (1999). • Beck's book Extreme Programming Explained, the original reference for Extreme Programming, also describes CI. • Fowler's paper is a popular source of information on the subject.
  6. 6. Martin Fowler and CI In his very popular “Continuous Integration” article, Martin Fowler describes CI as: • “. . . 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”
  7. 7. Wikipedia say us!!! Continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. From: http://en.wikipedia.org/wiki/Continuous_integration
  8. 8. This means • Continuous integration improving software quality and reducing risk • As the complexity of a project increases (even just adding one more person), there is a greater need to integrate and ensure that software components work together—early and often. • Waiting until the end of a project to integrate leads to all sorts of software quality problems, which are costly and often lead to project delays. CI addresses these risks faster and in smaller increments
  9. 9. The value of CI is to: • Reduce risks • Reduce repetitive manual processes • Generate deployable software at any time and at any place • Enable better project visibility • Establish greater confidence in the software product from the development team
  10. 10. Typical CI context From: Continuous integration improving software quality and reducing risk (Or any other version repository)
  11. 11. Beyond to the CI Tools… Practicing CI is more than installing and configuring some tools. • How many of the following items are you consistently performing on your project? • How many of the other CI practices can improve your development capabilities?
  12. 12. Beyond to the CI Tools… • On average, is everyone on your team committing code at least once a day? Are you employing techniques to make it easier to commit code often? • What percentage of each day’s integration builds is successful (that is, the most recent build run has passed)? • Is everyone on your team running a private build before committing to the repository so that integration errors are reduced? • Have you scripted your builds to fail if any of your tests or inspections fail? • Is a broken integration build a priority to fix on your projects? • Do you avoid getting the latest code from the version control system when there is a broken build? • How often do you consider adding automated processes to your build and CI system—on a continuous or even periodic basis?
  13. 13. But Tools are so important… …Hudson/Jenkins is widely recognized as a core tool for developers, QA engineers, project managers, release engineers, DevOps, and managers. It is also a crucial open source option for teams using Agile methodology, in which continuous integration is a fundamental practice… • Kohsuke Kawaguchi - Creator of the Jenkins CI server. In: 7 Ways to Optimize Jenkins/Hudson White Paper
  14. 14. The Hudson Book (pages 3-4) • Without continuous integration, developing modern applications is practically impossible without dramatic inefficiency. There is too much unproductive down-time, and far too much waste. The development group described above would be hard pressed to release anything more than a global update once a month • In other words, when you automate build, test, and verify using a tool like Hudson you can continue developing your applications without having to wait (or synchronize) on some manual build, test, verify process.
  15. 15. Just for information… • Jenkins and Hudson are the same =) in http://en.wikipedia.org/wiki/Comparison_of_continuous_i ntegration_software • Why Hudson and Jenkins names were choosed? • Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute with Oracle, which claims the right to trademark the Hudson name and has applied for such a trademark as of December 2010
  16. 16. CI as a scheduling method • RUP proposes the Integration Build Plan • The purpose of this is to define the order in which the components should be implemented, which builds to create when integrating the system, and how they are to be assessed.
  17. 17. CI as a scheduling method • RUP: You should adjust the outline of the Integration Build Plan to suit the nature of your project. For example, if the system is large, there may be a case for having subsidiary plans for each implementation subsystem. The formality and extent of the test material contained or referenced from the Integration Build Plan will vary depending on the significance of the build. • The RUP approach to integration is to incrementally integrate the software. Incremental integration means that code is written and tested in small pieces, and then combined into a working whole by adding one piece at a time.
  18. 18. Integration approaches • Integration then integration • Top-down Integration • Bottom-up integration • Sandwich integration Source: Object-Oriented and Classical Software Engineering Eighth Edition
  19. 19. Integration approaches Source: Object-Oriented and Classical Software Engineering Eighth Edition
  20. 20. Integration approaches Source: Object-Oriented and Classical Software Engineering Eighth Edition
  21. 21. … While we recognize that tooling may improve or otherwise affect a continuous integration implementation, the practice of continuous integration itself requires no particular tools at all (Fowler, 2013). Consequently we regard tools to be of secondary importance, but not of primary interest… Source: Modeling continuous integration practice differences in industry software development, 2013
  22. 22. And… • Now, CI is not enough… • ;(
  23. 23. CI evolves as CD (Continuous Delivery) • CI literally started to change how companies looked at Build Management, Release Management, Deployment Automation, and Test Orchestration… • However, if CI started as automation of the development phase only, pretty soon the revolution embraced the test- phase of the QA team and the deployment into various environment of the Ops team, involving the whole lifecycle of a product… Source: Armenise V., Continuous Delivery with Jenkins. 2015 IEEE/ACM 3rd International Workshop on Release Engineering.
  24. 24. CI evolves as CD (Continuous Delivery) • A CD platform allows Dev, QA and Ops teams to work closely together using the same orchestrator and embracing the key points of CD: • Collaboration across all the teams involved in the product-lifecycle • Extensive automation of the delivery process Source: Armenise V., Continuous Delivery with Jenkins. 2015 IEEE/ACM 3rd International Workshop on Release Engineering.
  25. 25. CI evolves as CD (Continuous Delivery) • Implementing CD means being able to chain the different steps involved in the cross-team pipeline and automate their execution: from the checkout of the code and the unit-tests, • to the static code-analysis, • to the performance tests, • to the release of the binaries until the deployment into test/staging/production Source: Armenise V., Continuous Delivery with Jenkins. 2015 IEEE/ACM 3rd International Workshop on Release Engineering.
  26. 26. Thanks for your attention fdgiraldo@uniquindio.edu.co

×