Continuous integration (eng)
2 likes926 views
Continuous Integration (CI) is a software development practice where team members integrate their work frequently, tested through automated builds to identify errors quickly. This document outlines CI's practices, benefits, and tools, emphasizing communication, fast feedback, and the importance of maintaining a common source repository. The advantages of CI include reduced risks, easier bug detection, and improved developer collaboration, ultimately leading to a more efficient development process.
Continuous integration (eng)
- 1. Continuous Integration ● What is continuous integration? ● Building a feature with continuous integration ● Practices of continuous integration ● Benefits of continuous integration ● Introducing continuous integration ● Final thoughts ● Continuous integration tools ● Links
- 2. What is continuous integration? 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. This presentation is a quick overview of Continuous Integration summarizing the technique and its current usage.
- 3. What is continuous integration? ● "it can't work (here)" ● "doing it won't make much difference" ● "yes we do that - how could you live without it?" The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices. Although Continuous Integration is a practice that requires no particular tooling to deploy, it is useful to use a Continuous Integration server. ● Integration is a "pay me now or pay me more later" kind of activity.
- 4. ● Building a feature with continuous integration ● Let's do something to a piece ● Update the working copy with of software,we assume it's the changes from the others small and can be done in a & rebuild, check for clashes. few hours. ● It is yours responsibility to ● Take a copy of the current create a successful build. integrated source onto your ● Commit your changes. local development machine. ● Build on the integration ● Alter the production code, machine. and add or change the automated tests. ● Must fix the build quickly. ● Build and run the automated ● Shared stable base, fewer tests. bugs, bugs show up quickly.
- 5. ● Practices of continuous integration ● Maintain a Single ● Keep the Build Fast Source Repository ● Test in a Clone of the ● Automate the Build Production ● Make Your Build Self- Environment Testing ● Make it Easy for ● Everyone Commits To Anyone to Get the the Mainline Every Day Latest Executable ● Every Commit Should ● Everyone can see Build the Mainline on what's happening an Integration Machine ● Automate Deployment
- 6. Maintain a Single Source Repository ● Software projects involve lots of files that need to be orchestrated together to build a product. ● Tools to manage all this - called Source Code Management tools, configuration management, version control systems, repositories, etc. ● Everything you need to do a build should be in there including: test scripts, properties files, database schema, install scripts, 3rd party libs. ● Keep your use of branches to a minimum. ● In general you should store in source control everything you need to build anything, but nothing that you actually build.
- 7. Automate the Build ● Automated environments for builds are a common feature of systems (Make, Ant, Nant, MSBuild, etc.) ● A common mistake is not to include everything in the automated build (virgin machine – up!) ● Incremental builds, component builds, targets ● It's essential to have a master build that is usable on a server and runnable from other scripts (Do not depend much on IDE)
- 8. Make Your Build Self-Testing ● A program may run, but that doesn't mean it does the right thing. ● A good way to catch bugs more quickly and efficiently is to include automated tests in the build process. ● CI has a weaker requirement of self-testing code then TDD. ● For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. ● The rise of TDD has popularized the XUnit family. ● Tools that focus on more end-to-end testing, like FIT, Selenium, Sahi, Watir, FITnesse, etc. ● You can't count on tests to find everything.
- 9. Everyone Commits To the Mainline Every Day ● Integration is primarily about communication. ● The one prerequisite for a developer committing to the mainline is that they can correctly build their code. ● The key to fixing problems quickly is finding them quickly. ● The fact that you build when you update your working copy means that you detect compilation conflicts as well as textual conflicts. ● Since there's only a few hours of changes between commits, there's only so many places where the problem could be hiding. You can even use diff-debugging. ● Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress.
- 10. Every Commit Should Build the Mainline on an Integration Machine ● Using daily commits, a team gets frequent tested builds. ● People not doing an update and build before they commit, environmental differences between developers' machines and other issues – prevent mainline's healthy state. ● Integration build succeeds should the commit be considered to be done – developers responsibility. ● Use a manual build or a CI server. ● Do not just make builds on a timed schedule. ● If the mainline build fails, it needs to be fixed right away. You're always developing on a known stable base. ● It's not a bad thing for the mainline build to break. Fix fast! ● Patience and steady application – develop a regular habit of working mainline builds.
- 11. Keep the Build Fast ● The whole point of CI is to provide rapid feedback. ● For most projects the XP guideline of a ten minute build is perfectly within reason. ● Start working on setting up a staged build. ● Build pipeline – multiple sequential builds. ● Fast commit build is the build that's needed when someone commits to the mainline. ● Secondary build which runs when it can – for example tests that involve external services such as a database, etc.
- 12. Test in a Clone of the Production Environment ● The point of testing is to flush out, under controlled conditions, any problem that the system will have in production. ● You want to set up your test environment to be as exact a mimic of your production environment as possible. ● It's common to have a very artificial environment for the commit tests for speed, and use a production clone for secondary testing. ● Use virtualization.
- 13. Make it Easy for Anyone to Get the Latest Executable ● People find it much easier to see something that's not quite right and say how it needs to be changed. ● Anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week. ● Well known place where people can find the latest executable. For the very latest you should put the latest executable to pass the commit tests (pretty stable).
- 14. Everyone can see what's happening ● CI is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it. ● Tray monitors, lights, lava lamps, toy rocket launchers, etc. ● Use a tool with a web site for dashboard, reporting and extended information. ● Wall calendar for a QA team to put red & green stickers indicating healthy & broken builds.
- 15. Automate Deployment ● To do CI you need multiple environments, one to run commit tests, one or more to run secondary tests. ● Use deployment scripts to move between environments ● If you deploy into production one extra automated capability you should consider is automated rollback. ● Rolling deployments in clustered environments. ● Trial build to a subset of users.
- 16. Benefits of continuous integration ● ● The greatest and most wide ranging benefit of CI is reduced risk. ● At all times you know where you are, what works, what doesn't, the outstanding bugs you have in your system. ● CI doesn't get rid of bugs, but it does make them dramatically easier to find and remove. ● Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. Broken Windows syndrome. ● If you have CI, it removes one of the biggest barriers to frequent deployment – between customers and development.
- 17. ● Introducing continuous integration ● There's no fixed recipe (your setup & team) ● Get the build automated. Build the whole system with a single command. On-demand. ● Introduce some automated testing into you build. Identify major areas. Start doing. ● Try to speed up the commit build. Magic 10m. ● Begin with Continuous Integration from the beginning for a new project. ● Get some help.
- 18. ●Final thoughts ● Continuous Integration has become a mainstream technique for software development. ● Many teams using CI report that the advantages of CI well outweigh the disadvantages. ● The effect of finding and fixing integration bugs early in the development process saves both time and money over the lifespan of a project.
- 19. Final thoughts ● when unit tests fail or a bug emerges, developers might ● initial setup time revert the codebase back to a bug-free state, without wasting required time debugging ● well-developed ● developers detect and fix integration problems continuously - test-suite required avoiding last-minute chaos at release dates to achieve automated testing ● early warning of broken/incompatible code advantages ● early warning of conflicting changes ● large-scale ● immediate unit testing of all changes refactoring can be ● constant availability of a "current" build for testing, demo, or troublesome due to continuously release purposes changing code ● immediate feedback to developers on the quality, base functionality, or system-wide impact of code they are writing ● hardware costs ● frequent code check-in pushes developers to create modular, for build less complex code machines can be ● metrics generated from automated testing and CI focus significant developers on developing functional, quality code, and help develop momentum in a team
- 20. ● Continuous integration tools Most popular: ● Apache Continuum — continuous integration server supporting Apache Maven and Apache Ant. Supports CVS, Subversion, Ant, Maven, and shell scripts ● Hudson — MIT-licensed, written in Java, runs in servlet container, supports CVS, Subversion, Mercurial , Git, StarTeam, Clearcase, Ant, NAnt, Maven, and shell scripts ● CruiseControl — Java-based framework for a continuous build process ● CruiseControl.NET — .NET-based automated continuous integration server
- 21. Links ● http://en.wikipedia.org/wiki/Continuous_integration ● http://www.martinfowler.com/articles/continuousIntegration.html ● http://www.extremeprogramming.org/rules/integrateoften.html ● http://cruisecontrol.sourceforge.net/overview.html ● http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson ● http://continuum.apache.org/ ● http://www.wakaleo.com/books/continuous-integration-with-hudson-t ● http://www.developer.com/open/article.php/3803646/The-Best-Contin ● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.htm