Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuos Delivery


Published on

Reliable Software Releases through Build, Test, and Deployment Automation

Chapter 3. Continuous Integration
Jez Humble, David Farley

Published in: Software
  • Be the first to comment

Continuos Delivery

  1. 1. Reliable Software Releases through Build, Test, and Deployment Automation Chapter 3. Continuous Integration Jez Humble, David Farley Continuous Delivery
  2. 2. Continuous Integration • Requires that every time somebody commits any change, the entire application is built and a comprehensive set of automated tests is run against it. • The goal of continuous integration is that the software is in a working state all the time. • The teams that use continuous integration effectively are able to deliver software much faster, and with fewer bugs, than teams that do not.
  3. 3. What You Need Before You Start • Version Control • An Automated Build • Agreement of the Team
  4. 4. Version Control • Everything in your project must be checked in to a single version control repository: code, tests, database scripts, build and deployment scripts, and anything else needed to create, install, run, and test your application. • Some people don’t consider their project big enough to warrant the use of version control. We don’t believe that there is a project small enough to do without it
  5. 5. An Automated Build • You need to be able to run your build process in an automated way from your continuous integration environment so that it can be audited when things go wrong. • Your build scripts should be treated like your codebase. They should be tested and constantly refactored so that they are tidy and easy to understand. It’s impossible to do this with an IDE-generated build process. This gets more and more important the more complex the project becomes. • It makes understanding, maintaining, and debugging the build easier, and allows for better collaboration with operations people.
  6. 6. Agreement of the Team • Continuous integration is a practice, not a tool. It requires a degree of commitment and discipline from your development team. • You need everyone to check in small incremental changes frequently to mainline and agree that the highest priority task on the project is to fix any change that breaks the application. • If people don’t adopt the discipline necessary for it to work, your attempts at continuous integration will not lead to the improvement in quality that you hope for.
  7. 7. Prerequisites for Continuous Integration • Check In Regularly. • Create a Comprehensive Automated Test Suite • Keep the Build and Test Process Short. • Managing Your Development Workspace
  8. 8. Check In Regularly • The most important practice for continuous integration to work properly is frequent check-ins to trunk or mainline. • It makes your changes smaller and thus less likely to break the build. It means you have a recent knowngood version of the software to revert to when you make a mistake or go down the wrong path. • It helps you to be more disciplined about your refactoring and stick to small changes that preserve behavior. It helps to ensure that changes altering a lot of files are less likely to conflict with other people’s work
  9. 9. Create a Comprehensive Automated Test Suite • If you don’t have a comprehensive suite of automated tests, a passing build only means that the application could be compiled and assembled. • While for some teams this is a big step, it’s essential to have some level of automated testing to provide confidence that your application is actually working. • Should provide an extremely high level of confidence that any introduced change has not broken existing functionality.
  10. 10. Keep the Build and Test Process Short. If it takes too long to build the code and run the unit tests, you will run into the following problems: • People will stop doing a full build and running the tests before they check in. You will start to get more failing builds. • The continuous integration process will take so long that multiple commits will have taken place by the time you can run the build again, so you won’t know which check-in broke the build. • People will check in less often because they have to sit around for ages waiting for the software to build and the tests to run.
  11. 11. Managing Your Development Workspace • Developers should always work from a knowngood starting point when they begin a fresh piece of work. They should be able to run the build, execute the automated tests, and deploy the application in an environment under their control. In general, this should be on their own local machine. • For most projects, the third-party libraries they depend on don’t change very frequently, so the simplest solution of all is to commit these libraries into your version control system along with your source code. • In fact, one sign of a good application architecture is that it allows the application to be run without much trouble on a development machine.
  12. 12. Essential Practices • Don’t Check In on a Broken Build • Wait for Commit Tests to Pass before Moving On • Never Go Home on a Broken Build • Always Be Prepared to Revert to the Previous Revision
  13. 13. Essential Practices • Time-Box Fixing before Reverting • Don’t Comment Out Failing Tests. • Take Responsibility for All Breakages That Result from Your Changes • Test-Driven Development
  14. 14. SUMMARY • To implement continuous integration is to create a paradigm shift in your team. Without CI, your application is broken until you prove otherwise. • With CI, the default state of your application is working, albeit with a level of confi- dence that depends upon the extent of your automated test coverage. • CI creates a tight feedback loop which allows you to find problems as soon as they are introduced, when they are cheap to fix.
  15. 15. SUMMARY • Implementing CI forces you to follow two other important practices: good configuration management and the creation and maintenance of an automated build and test process. • CI requires good team discipline. What is different about continuous integration is that you have a simple indicator of whether or not discipline is being followed: The build stays green. • If you discover that the build is green but there is insufficient discipline, for example poor unit test coverage, you can easily add checks to your CI system to enforce better behavior.
  16. 16. SUMMARY An established CI system is a foundation on which you can build more infrastructure: • Big visible displays which aggregate information from your build system to provide high-quality feedback. • A system of reference for reports and installers for your testing team. • A provider of data on the quality of the application for project managers. • A system that can be extended out to production, using the deployment pipeline, which provides testers and operations staff with push-button deployments.
  17. 17. Andrés Callejas González Universidad Pontificia Bolivariana