• 15 Sep 16
  

  m0ll3art

  best practices version control continuousintegration

• 06 Sep 16
  

  voxsim
• 02 Sep 16
  

  rashda2008
• 29 Aug 16
  

  shouraigen
• 07 Jun 16
  

  Matt Fahrner

  • 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 article is a quick overview of Continuous Integration summarizing the technique and its current usage. 

      

     

     
• 30 May 16
  

  atrohn
  • I'll focus now on the key practices that  make up effective CI.
• 21 Mar 16
  

  davicres
  • Integration is primarily about communication. Integration  allows developers to tell other developers about the changes  they have made. Frequent communication allows people to know  quickly as changes develop.
  • with any commit  cycle the developer first updates their working copy to match  the mainline, resolves any conflicts with the mainline, then  builds on their local machine. If the build passes, then they  are free to commit to the mainline.
  • My general rule of thumb is that every developer should  commit to the repository every day. In practice it's often  useful if developers commit more frequently than  that. The more frequently you commit, the less places you have  to look for conflict errors, and the more rapidly you fix  conflicts.
  • 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. Often people  initially feel they can't do something meaningful in just a few  hours, but we've found that mentoring and practice helps them learn.
  • you should ensure that regular builds happen on  an integration machine and only if this integration build  succeeds should the commit be considered to be done
  • . Since the  developer who commits is responsible for this, that developer  needs to monitor the mainline build so they can fix it if it  breaks.
  • There are two main ways I've seen to ensure this: using a manual build or a continuous integration server.
  • The developer goes to the integration machine,  checks out the head of the mainline (which now houses his last  commit) and kicks off the integration build. He keeps an eye  on its progress, and if the build succeeds he's done with his  commit
  • A continuous integration server acts as a monitor to the  repository. Every time a commit against the repository  finishes the server automatically checks out the sources onto  the integration machine, initiates a build, and notifies the  committer of the result of the build. The committer isn't done  until she gets the notification - usually an email.

  7 more annotations...

• 25 Sep 15
  

  perivr

  continuous integration

• 15 May 15
  

  Igor Khavkin

  To do Continuous Integration, everyone must commit daily to mainline, & each commit should build and test
  http://t.co/2NJhcSMe4v

• 05 May 15
  

  zubenko
  • e English electronics company. My manager, part of the QA group, gave me a tour of a s
• 24 Feb 15
  

  webdev

• 09 Nov 14
  

  p_rajca
• 15 Oct 14
  

  fawadmalik
• 20 Sep 14
  

  saeedj
  • Continuous Integration
• 04 Sep 14
  

  tonyzhoujingtao
  • The first  stage would do the compilation and run tests that are more  localized unit tests with the database completely stubbed out.  Such tests can run very fast, keeping within the ten minute  guideline. However any bugs that involve larger scale  interactions, particularly those involving the real database,  won't be found. The second stage build runs a different suite  of tests that do hit the real database and involve more  end-to-end behavior. This suite might take a couple of hours  to run
  • If the secondary build detects a bug, that's a sign that the commit build could do with another test. As much as possible you want to ensure that any later-stage failure leads to new tests in the commit build that would have caught the bug, so the bug stays fixed in the commit build
  • This way the commit tests are strengthened whenever something gets past them
  • The  builds after the commit build can also be done in parallel, so if  you have two hours of secondary tests you can improve  responsiveness by having two machines that run half the tests  each. By using parallel secondary builds like this you can  introduce all sorts of further automated testing, including  performance testing, into the regular build process
  • The point of testing is to flush out, under controlled  conditions, any problem that the system will have in  production. A significant part of this is the environment  within which the production system will run. If you test in a  different environment, every difference results in a risk that  what happens under test won't happen in production
  • As a result you want to set up your test environment to be  as exact a mimic of your production environment as  possible. Use the same database software, with the same  versions, use the same version of operating system. Put all  the appropriate libraries that are in the production  environment into the test environment, even if the system  doesn't actually use them. Use the same IP addresses and  ports, run it on the same hardware
  • One of the most difficult parts of software development is  making sure that you build the right software
  • We've found  that it's 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
  • Continuous Integration 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
  • To do Continuous Integration you need multiple  environments, one to run commit tests, one or more to run  secondary tests. Since you are moving executables between these  environments multiple times a day, you'll want to do this  automatically. So it's important to have scripts that will  allow you to deploy the application into any environment easily
  • A natural consequence of this is that you should also have  scripts that allow you to deploy into production with similar  ease
  • automatic  deployment helps both speed up the process and reduce  errors. It's also a cheap option since it just uses the same  capabilities that you use to deploy into test environments
  • If you deploy into production one extra automated  capability you should consider is automated rollback
  • greatest and most wide ranging  benefit of Continuous Integration is reduced risk
  • The trouble with deferred integration is that it's very hard  to predict how long it will take to do, and worse it's very hard  to see how far you are through the process
  • Continuous Integrations doesn't get rid of bugs, but it does make them dramatically easier to find and remove

  14 more annotations...

• 26 Jul 14
  

  dnelson1964
  • Maintain a Single Source Repository.
  • These tools - called Source Code Management tools, configuration management, version control systems, repositories, or various other names - are an integral part of most development projects
• 22 Jul 14
  

  irahat

  development architecture

• 01 Jul 14
  

  Alexey Menkov

  continuous Integration

• 30 Jun 14
  

  Eddie Osh

  continuousintegration

• 25 Jun 14
  

  masnotsram
• 16 May 14
  

  amadu80

  agile development continuousintegration integration programming software build ci martin fowler

• 14 Apr 14
  

  Vasilis Margioulas
• 01 Apr 14
  

  Charl Cordiglia

  agile continuousintegration

• 18 Mar 14
  

  Ricky Kurniawan

  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 article is a quick overview of Continuous Integration summarizing the technique and its current usage.

  web developer web development continuous integration practice martin fowler

• 19 Feb 14
  

  rhm2ktmi

  continuous integration

  • The easiest way for me to explain what CI is and how it works is to show a quick example of how it works with the development of a small feature.
  • Continuous Integration assumes a high degree of tests  which are automated into the software: a facility I call  self-testing code. Often these use a version of the popular  XUnit testing frameworks
  • Once I'm done (and usually at various points when I'm  working) I carry out an automated build on my development  machine.
  • With a good build, I can then think about  committing my changes into the repository.
  • Once I have made my own build of a properly synchronized  working copy I can then finally commit my changes into the mainline,  which then updates the repository.
  • However my commit doesn't finish my work. At this point we  build again, but this time on an integration machine based on  the mainline code.

  4 more annotations...

• 05 Feb 14
  

  Navneet Kumar

  Continuous-Integration CI Software-Engineering Software-Management

• 27 Jan 14
  

  Erik Paulsson

  continuous integration integration testing

• 23 Nov 13
  

  Tim Beck

  continuous integration

• 22 Nov 13
  

  Sam Rose

  continuousintegration software programming development agile

• 24 May 13
  

  Ewerton Costa
  • So as a simple basis make sure you get a decent source code management system
  • Everything should be in the repository
  • Keep your use of branches to a minimum. In particular  have a mainline: a single branch of the project  currently under development
  • In general you should store in source control everything  you need to build anything, but nothing that you actually  build
  • A common mistake is not to include everything in the automated build.
  • Build scripts come in various flavors and are often particular to a platform or community, but they don't have to be
  • A good way to catch bugs more quickly and efficiently is to include automated tests in the build process
  • Imperfect tests, run frequently, are much better than perfect tests that are never written at all
  • Integration is primarily about communication
  • The whole point of continuous integration is to  find problems as soon as you can
  • The whole point of Continuous Integration is to provide  rapid feedback

  9 more annotations...

• 29 Apr 13
  

  squ4lor

  continuousintegration

• 17 Apr 13
  

  marm5r

  continuous integration ci software development fowler

• 24 Nov 12
  

  dalogoz
  • integration is a long and unpredictable process.
  • Any individual developer's work is  only a few hours away from a shared project state and can be  integrated back into that state in minutes
  • Any integration errors  are found rapidly and can be fixed rapidly.
  • In a Continuous Integration  environment you should never have a failed integration build  stay failed for long. A good team should have many correct  builds a day. Bad builds do occur from time to time, but should  be quickly fixed.
  • If people  use one they'll put code in there, but everything you need to  do a build should be in  there including: test scripts, properties files, database  schema, install scripts, and third party  libraries.
  • Keep your use of branches to a minimum.

  4 more annotations...

• 19 Oct 12
  

  Jesús Benito

  Artículo sobre Integración Continua escrito por Martin Fowler.

  continuous integration integración continua de development software programming ci agile

• 11 Oct 12
  

  Marco Antonio Almeida
• 19 Sep 12
  

  Deen Seth
  • integrating for several months.
  • integrating frequently, usually daily, against a  controlled source code repository.
  • useful to use a Continuous Integration server
  • Continuous Integration assumes a high degree of tests  which are automated into the software:
  • I carry out an automated build on my development  machine
  • update my  working copy
  • At this point we  build again, but this time on an integration machine based on  the mainline code
  • Bad builds do occur from time to time, but should  be quickly fixed.
  • Everybody  develops off that shared stable base and never gets so far away  from that base
  • worth paying for is Perforce
  • everything you need to  do a build should be in  there including: test scripts, properties files, database  schema, install scripts, and third party  libraries.
  • walk up to the project with a virgin machine, do a  checkout, and be able to fully build the system
  • An operating system, Java development environment, or base  database system are typical examples
  • IDE configurations  are good to put in there because that way it's easy for people  to share the same IDE setups
  • The build should include getting the database schema out of the repository and firing it up in the execution environment
  • most IDEs have some kind of build management process within them
  • a suite of automated tests
  • XUnit tools have proved very valuable
  • Imperfect tests, run frequently, are much better than perfect tests that are never written at all.
  • passing the build tests

  18 more annotations...

• 12 Sep 12
  

  nikbox

  20090123

• 23 Aug 12
  

  shariharan

  development continuous-integration

• 11 Aug 12
  

  rabid shaman

  aop

• 10 Jul 12
  

  Alex Yakyma
  • Continuous Integration
  • The trouble with deferred integration is that it's very hard  to predict how long it will take to do, and worse it's very hard  to see how far you are through the process. The result is that  you are putting yourself into a complete blind spot right at one  of tensest parts of a project - even if you're one of the rare  cases where you aren't already late.
  • 

  1 more annotation...

• 17 May 12
  

  Ben Simanek

  hn blog development programming integration continuousintegration

• 09 May 12
  

  Arash Milani

  Continuous Integration

  continuous integration integration agile

• 05 May 12
  

  Thiago Hiromi

  php development programming continuousintegration

• 20 Mar 12
  

  marco_antonio_almeida_silva

  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

  continuousintegration martinfowler design architecture programming

• 13 Mar 12
  

  will iam

  continuousintegration devops

• 08 Mar 12
  

  Lukasz Jay

  integration software programming

• 06 Mar 12
  

  Boris Raicheff

  ci

• 16 Feb 12
  

  borhaus ^_^

  agile qa

• 09 Feb 12
  

  acazsouza

  martinfowler continuousintegration software agile programming development

• 20 Jan 12
  

  D C

  agile continuous_integration fowler tdd testing otimo build design_patterns

• 13 Jan 12
  

  Dal Ix

  version control svn git branch

  • I carry out an automated build on my development  machine.
  • Pretty much everyone should work  off this mainline most of the time
  • Everyone Commits To the Mainline Every Day

  1 more annotation...

• 05 Jan 12
  

  Bruno Passos

  Dev Projetos

• 28 Dec 11
  

  Jonathan Creek

  software development

• 

  janto_d

  software development

• 11 Dec 11
  

  Shafiq Ahamed
  • 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 article is a quick overview of Continuous Integration summarizing the technique and its current usage.
• 23 Nov 11
  

  stormwild

  development agile programming software continuousintegration testing integration continuous-integration build ci

• 17 Nov 11
  

  sensimevanidus
  • 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.
  • a common story of software projects: integration is a long and unpredictable process.
  • Most projects done by my colleagues  at ThoughtWorks, and by many others around the world, treat  integration as a non-event. Any individual developer's work is  only a few hours away from a shared project state and can be  integrated back into that state in minutes. Any integration errors  are found rapidly and can be fixed rapidly.
  • The essence of it lies in the simple practice of everyone on  the team integrating frequently, usually daily, against a  controlled source code repository.
  • 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, we've found that it is useful to use a Continuous Integration server. The best known such server is CruiseControl, an open source tool originally built by several people at ThoughtWorks and now maintained by a wide community.
  • Let's assume I have to do something to a piece of software, it doesn't really matter what the task is, for the moment I'll assume it's small and can be done in a few hours.
  • I begin by taking a copy of the current integrated source  onto my local development machine. I do this by using a source  code management system by checking out a working copy from the  mainline.

  • A source code  control system keeps all of a project's source code in a  repository. The current state of the system is usually referred  to as the 'mainline'. At any time a developer can make a controlled  copy of the mainline onto their own machine, this is called  'checking out'. The copy on the developer's machine  is called a 'working copy'. (Most of the time you actually update  your working copy to the mainline - in practice it's the same thing.)

      

    Now I take my working copy and do whatever I need to do to  complete my task. This will consist of both altering the  production code, and also adding or changing automated  tests. Continuous Integration assumes a high degree of tests  which are automated into the software: a facility I call  self-testing code. Often these use a version of the popular  XUnit testing frameworks.

      

    Once I'm done (and usually at various points when I'm  working) I carry out an automated build on my development  machine. This takes the source code in my working copy, compiles  and links it into an executable, and runs the automated  tests. Only if it all builds and tests without errors is the  overall build considered to be good.

      

    With a good build, I can then think about  committing my changes into the repository. The twist, of course, is  that other people may, and usually have, made changes to the  mainline before I get chance to commit. So first I update my  working copy with their changes and rebuild. If their changes  clash with my changes, it will manifest as a failure either in  the compilation or in the tests. In this case it's my  responsibility to fix this and repeat until I can build a  working copy that is properly synchronized with the mainline.

      

    Once I have made my own build of a properly synchronized  working copy I can then finally commit my changes into the mainline,  which then updates the repository.
  • However my commit doesn't finish my work. At this point we  build again, but this time on an integration machine based on  the mainline code. Only when this build succeeds can we say that  my changes are done. There is always a chance that I missed  something on my machine and the repository wasn't properly  updated. Only when my committed changes build successfully on  the integration is my job done. This integration build can be  executed manually by me, or done automatically by Cruise.
  • If a clash occurs between two  developers, it is usually caught when the second developer to  commit builds their updated working copy. If not the integration  build should fail. Either way the error is detected rapidly. At  this point the most important task is to fix it, and get the  build working properly again. In a Continuous Integration  environment you should never have a failed integration build  stay failed for long. A good team should have many correct  builds a day. Bad builds do occur from time to time, but should  be quickly fixed.
  • The result of doing this is that there is a stable piece of  software that works properly and contains few bugs. Everybody  develops off that shared stable base and never gets so far away  from that base that it takes very long to integrate back with  it. Less time is spent trying to find bugs because they show up  quickly.
  • I'll focus now on the key practices that  make up effective CI.
  • Software projects involve lots of files that need to be orchestrated together to build a product. Keeping track of all of these is a major effort, particularly when there's multiple people involved. So it's not surprising that over the years software development teams have built tools to manage all this. These tools - called Source Code Management tools, configuration management, version control systems, repositories, or various other names - are an integral part of most development projects.
  • So as a simple basis make sure you get a decent source code management system. Cost isn't an issue as good quality open-source tools are available.
  • Once you get a source code management system, make sure it  is the well known place for everyone to go get source  code. Nobody should ever ask "where is the foo-whiffle file?"  Everything should be in the repository.
  • If people  use one they'll put code in there, but everything you need to  do a build should be in  there including: test scripts, properties files, database  schema, install scripts, and third party  libraries. I've known projects that check their compilers into  the repository (important in the early days of flaky C++  compilers). The basic rule of thumb is that you should be able  to walk up to the project with a virgin machine, do a  checkout, and be able to fully build the system. Only a  minimal amount of things should be on the virgin machine -  usually things that are large, complicated to install, and  stable. An operating system, Java development environment, or base  database system are typical examples.
  • You must put everything required for a build in the source  control system, however you may also put other stuff that  people generally work with in there too. IDE configurations  are good to put in there because that way it's easy for people  to share the same IDE setups.
  • One of the features of version control systems is that they  allow you to create multiple branches, to handle different  streams of development. This is a useful, nay essential,  feature - but it's frequently overused and gets people into  trouble. Keep your use of branches to a minimum. In particular  have a mainline: a single branch of the project  currently under development. Pretty much everyone should work  off this mainline most of the time. (Reasonable branches are  bug fixes of prior production releases and temporary experiments.)
  • Getting the sources turned into a running system can often be a complicated process involving compilation, moving files around, loading schemas into the databases, and so on. However like most tasks in this part of software development it can be automated - and as a result should be automated.
  • Automated environments for builds are a common feature of systems. The Unix world has had make for decades, the Java community developed Ant, the .NET community has had Nant and now has MSBuild. Make sure you can build and launch your system using these scripts using a single command.
  • A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.
  • Depending on what you need, you may need different kinds of things to be built. You can build a system with or without test code, or with different sets of tests. Some components can be built stand-alone. A build script should allow you to build alternative targets for different cases.
  • it's essential to have a master build that is usable on a server and runnable from other scripts. So on a Java project we're okay with having developers build in their IDE, but the master build uses Ant to ensure it can be run on the development server.
  • Traditionally a build means compiling, linking, and all the additional stuff required to get a program to execute. A program may run, but that doesn't mean it does the right thing. Modern statically typed languages can catch many bugs, but far more slip through that net.
  • A good way to catch bugs more quickly and efficiently is to include automated tests in the build process. Testing isn't perfect, of course, but it can catch a lot of bugs - enough to be useful. In particular the rise of Extreme Programming (XP) and Test Driven Development (TDD) have done a great deal to popularize self-testing code and as a result many people have seen the value of the technique.
  • Regular readers of my work will know that I'm a big fan of both TDD and XP, however I want to stress that neither of these approaches are necessary to gain the benefits of self-testing code. Both of these approaches make a point of writing tests before you write the code that makes them pass - in this mode the tests are as much about exploring the design of the system as they are about bug catching. This is a Good Thing, but it's not necessary for the purposes of Continuous Integration, where we have the weaker requirement of self-testing code.
  • For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. The tests need to be able to be kicked off from a simple command and to be self-checking. The result of running the test suite should indicate if any tests failed. For a build to be self-testing the failure of a test should cause the build to fail.
  • Over the last few years the rise of TDD has popularized the XUnit family of open-source tools which are ideal for this kind of testing. XUnit tools have proved very valuable to us at ThoughtWorks and I always suggest to people that they use them. These tools, pioneered by Kent Beck, make it very easy for you to set up a fully self-testing environment.
  • XUnit tools are certainly the starting point for making your code self-testing. You should also look out for other tools that focus on more end-to-end testing, there's quite a range of these out there at the moment including FIT, Selenium, Sahi, Watir, FITnesse, and plenty of others that I'm not trying to comprehensively list here.
  • Of course you can't count on tests to find everything. As it's often been said: tests don't prove the absence of bugs. However perfection isn't the only point at which you get payback for a self-testing build. Imperfect tests, run frequently, are much better than perfect tests that are never written at all.
  • Integration is primarily about communication. Integration  allows developers to tell other developers about the changes  they have made. Frequent communication allows people to know  quickly as changes develop.
  • The one prerequisite for a developer committing to the  mainline is that they can correctly build their code. This, of  course, includes passing the build tests. As with any commit  cycle the developer first updates their working copy to match  the mainline, resolves any conflicts with the mainline, then  builds on their local machine. If the build passes, then they  are free to commit to the mainline.
  • By doing this frequently, developers quickly find out if  there's a conflict between two developers. The key to fixing  problems quickly is finding them quickly. With developers  committing every few hours a conflict can be detected within a  few hours of it occurring, at that point not much has  happened and it's easy to resolve. Conflicts that stay  undetected for weeks can be very hard to resolve.
  • The fact that you build when you update your working copy  means that you detect compilation conflicts as well as textual  conflicts. Since the build is self-testing, you also detect  conflicts in the running of the code. The latter conflicts are  particularly awkward bugs to find if they sit for a long time  undetected in the code. Since there's only a few hours of  changes between commits, there's only so many places where the  problem could be hiding. Furthermore since not much has  changed you can use diff-debugging to help you find the bug.
  • My general rule of thumb is that every developer should  commit to the repository every day. In practice it's often  useful if developers commit more frequently than  that. The more frequently you commit, the less places you have  to look for conflict errors, and the more rapidly you fix  conflicts.

  • Using daily commits, a team gets frequent tested  builds. This ought to mean that the mainline stays in a  healthy state. In practice, however, things still do go  wrong. One reason is discipline, people not doing an update  and build before they commit. Another is environmental  differences between developers' machines.

      
  • As a result you should ensure that regular builds happen on  an integration machine and only if this integration build  succeeds should the commit be considered to be done. Since the  developer who commits is responsible for this, that developer  needs to monitor the mainline build so they can fix it if it  breaks. A corollary of this is that you shouldn't go home  until the mainline build has passed with any commits you've  added late in the day.
  • There are two main ways I've seen to ensure this: using a manual build or a continuous integration server.
  • The manual build approach is the simplest one to  describe. Essentially it's a similar thing to the local build  that a developer does before the commit into the  repository. The developer goes to the integration machine,  checks out the head of the mainline (which now houses his last  commit) and kicks off the integration build. He keeps an eye  on its progress, and if the build succeeds he's done with his  commit.
  • A continuous integration server acts as a monitor to the  repository. Every time a commit against the repository  finishes the server automatically checks out the sources onto  the integration machine, initiates a build, and notifies the  committer of the result of the build. The committer isn't done  until she gets the notification - usually an email.
  • Many organizations do regular builds on a timed schedule,  such as every night. This is not the same thing as a  continuous build and isn't enough for continuous  integration. The whole point of continuous integration is to  find problems as soon as you can. Nightly builds mean that  bugs lie undetected for a whole day before anyone discovers  them. Once they are in the system that long, it takes a long  time to find and remove them.
  • A key part of doing a continuous build is that if the  mainline build fails, it needs to be fixed right away. The  whole point of working with CI is that you're always  developing on a known stable base. It's not a bad thing for  the mainline build to break, although if it's happening all  the time it suggests people aren't being careful enough about  updating and  building locally before a commit. When the mainline build does  break, however, it's important that it gets fixed fast. To  help avoid breaking the mainline you might consider using a  pending head.
  • The whole point of Continuous Integration is to provide  rapid feedback. Nothing sucks the blood of a CI activity more  than a build that takes a long time.
  • For most projects, however, the XP guideline of a ten  minute build is perfectly within reason.
  • For enterprise applications, at least, we've  found the usual bottleneck is testing - particularly tests  that involve external services such as a database.

  • Probably the most crucial step is to start working on setting up a staged build. The idea behind a staged build (also known as build pipeline or deployment pipeline) is that there are in fact multiple builds done in sequence. The commit to the mainline triggers the first build - what I call the commit build. The commit build is the build that's needed when someone commits to the mainline. The commit build is the one that has to be done quickly, as a result it will take a number of shortcuts that will reduce the ability to detect bugs. The trick is to balance the needs of bug finding and speed so that a good commit build is stable enough for other people to work on.

      

     

    Jez Humble and Dave Farley extended these ideas into the  topic of Continuous Delivery, with more details on the concept  of staged builds - which they call deployment pipelines. Their  book, Continuous  Delivery, rightly won the Jolt excellence award in 2011.

     

      

    Once the commit build is good then other people can work on  the code with confidence. However there are further, slower,  tests that you can start to do. Additional machines can run  further testing routines on the build that take longer to  do.
  • A simple example of this is a two stage build. The first  stage would do the compilation and run tests that are more  localized unit tests with the database completely stubbed out.  Such tests can run very fast, keeping within the ten minute  guideline. However any bugs that involve larger scale  interactions, particularly those involving the real database,  won't be found. The second stage build runs a different suite  of tests that do hit the real database and involve more  end-to-end behavior. This suite might take a couple of hours  to run.
  • This example is of a two-stage build, but the basic  principle can be extended to any number of later builds.
  • The point of testing is to flush out, under controlled  conditions, any problem that the system will have in  production. A significant part of this is the environment  within which the production system will run. If you test in a  different environment, every difference results in a risk that  what happens under test won't happen in production.
  • As a result you want to set up your test environment to be  as exact a mimic of your production environment as  possible. Use the same database software, with the same  versions, use the same version of operating system. Put all  the appropriate libraries that are in the production  environment into the test environment, even if the system  doesn't actually use them. Use the same IP addresses and  ports, run it on the same hardware.
  • If you have a pretty simple setup without many awkward  communications, you may be able to run your commit build in a  mimicked environment. Often, however, you need to use test  doubles because systems respond slowly or intermittently. As a  result it's common to have a very artificial environment for  the commit tests for speed, and use a production clone for  secondary testing.
  • One of the most difficult parts of software development is  making sure that you build the right software. We've found  that it's 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. Agile  development processes explicitly expect and take advantage of  this part of human behavior.
  • To help make this work, 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.
  • Doing this is pretty straightforward: make sure there's a  well known place where people can find the latest  executable. It may be useful to put several executables in  such a store. For the very latest you should put the latest  executable to pass the commit tests - such an executable  should be pretty stable providing the commit suite is  reasonably strong.
  • Continuous Integration 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.
  • One of the most important things to communicate is the  state of the mainline build. If you're using Cruise  there's a built in web site that will show you if there's a  build in progress and what was the state of the last mainline  build.
  • If you're using a manual CI process, this visibility is  still essential. The monitor of the physical build machine  can show the status of the mainline build. Often you have a  build token to put on the desk of whoever's currently doing  the build (again something silly like a rubber chicken is a  good choice). Often people like to make a simple noise on good  builds, like ringing a bell.
  • To do Continuous Integration you need multiple  environments, one to run commit tests, one or more to run  secondary tests. Since you are moving executables between these  environments multiple times a day, you'll want to do this  automatically. So it's important to have scripts that will  allow you to deploy the application into any environment easily.
  • If you deploy into production one extra automated  capability you should consider is automated rollback.
  • A particularly interesting variation of this that I've come  across with public web application is the idea of deploying a  trial build to a subset of users. The team then sees how the  trial build is used before deciding whether to deploy it to  the full user population. This allows you to test out new  features and user-interfaces before committing to a final  choice. Automated deployment, tied into good CI discipline, is  essential to making this work.
  • On the whole I think the greatest and most wide ranging  benefit of Continuous Integration is reduced risk.

  • The trouble with deferred integration is that it's very hard  to predict how long it will take to do, and worse it's very hard  to see how far you are through the process. The result is that  you are putting yourself into a complete blind spot right at one  of tensest parts of a project - even if you're one of the rare  cases where you aren't already late.

      

    Continuous Integration completely finesses this  problem. There's no long integration, you completely eliminate  the blind spot. At all times you know where you are, what works,  what doesn't, the outstanding bugs you have in your system.

  • 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.

      

    Continuous Integrations doesn't get rid of bugs, but it does make them dramatically easier to find and remove. In this respect it's rather like self-testing code. If you introduce a bug and detect it quickly it's far easier to get rid of. Since you've only changed a small bit of the system, you don't have far to look. Since that bit of the system is the bit you just worked with, it's fresh in your memory - again making it easier to find the bug. You can also use diff debugging - comparing the current version of the system to an earlier one that didn't have the bug.
  • Bugs are also cumulative. The more bugs you have, the harder  it is to remove each one. This is partly because you get bug  interactions, where failures show as the result of multiple  faults - making each fault harder to find. It's also  psychological - people have less energy to find and get rid of  bugs when there are many of them - a phenomenon that the  Pragmatic Programmers call the Broken Windows syndrome.

  • As a result projects with Continuous Integration tend to have  dramatically less bugs, both in production and in  process. However I should stress that the degree of this benefit  is directly tied to how good your test suite is. You should find  that it's not too difficult to build a test suite that makes a  noticeable difference. Usually, however, it takes a while before  a team really gets to the low level of bugs that they have the  potential to reach. Getting there means constantly working on  and improving your tests.

      

    If you have continuous integration, it removes one of the  biggest barriers to frequent deployment. Frequent deployment is  valuable because it allows your users to get new features more  rapidly, to give more rapid feedback on those features, and  generally become more collaborative in the development  cycle. This helps break down the barriers between customers and  development - barriers which I believe are the biggest barriers  to successful software development.

  • There's no fixed recipe here - much depends on the nature of  your setup and team. But here are a few things that we've  learned to get things going.

      

  65 more annotations...

• 23 Oct 11
  

  Arun Ilango
• 07 Oct 11
  

  Sorawit Wanitwarodom

  continuousintegration ci continuous integration

• 29 Sep 11
  

  pyotr galois

  agile development continuousintegration software integration programming build ci

• 27 Sep 11
  

  Manan Jani

  articles

• 14 Sep 11
  

  michaelkrenz

  continuousintegration agile fowler

• 30 Jul 11
  

  Jorge Gamba

  To do Continuous Integration, everyone must commit daily to mainline, & each commit should build and test
  http://t.co/2NJhcSMe4v

  tweet continuousintegration featured definition introduction overview starting toprocess processed

• 21 Jul 11
  

  Jojo Pad

  software-engineering agile devops

• 21 Jun 11
  

  Ernest Lee

  development continuous integration version control

  • The essence of it lies in the simple practice of everyone on  the team integrating frequently, usually daily, against a  controlled source code repository
  • Only when my committed changes build successfully on  the integration is my job done
  • Bad builds do occur from time to time, but should  be quickly fixed
  • The basic rule of thumb is that you should be able  to walk up to the project with a virgin machine, do a  checkout, and be able to fully build the system
  • A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment.

  3 more annotations...

• 10 Jun 11
  

  Tom Staubitz

  development extremeprogramming continous

• 23 May 11
  

  elle m

  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 article is a quick overview of Continuous Integration summarizing the technique and its current usage.

  agile development continuousintegration ci build

• 19 May 11
  

  Thoughts for CruiseControl, Bambo

  continuousintegration integration programming development continuous

• 02 May 11
  

  ricardozanini

  java programming development tutorial reference CI continuousintegration

• 23 Apr 11
  

  expertwk

  continuous integration

• 14 Apr 11
  

  ci continuousintegration development agile article howto

• 06 Apr 11
  

  anshu gaind

  source+build+deploy

  • The current open source repository of choice is Subversion.
  • The basic rule of thumb is that you should be able  to walk up to the project with a virgin machine, do a  checkout, and be able to fully build the system.
  • 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.
  • A common mistake is not to include everything in the automated build.
  • So on a Java project we're okay with having developers build in their IDE, but the master build uses Ant to ensure it can be run on the development server.

  4 more annotations...

• 05 Apr 11
  

  Bryan Bishop

  Martin Fowler's article about CI

  development continuousintegration agile programming software for:shackelford fowler thoughtworks

• 29 Mar 11
  

  Tomislav Rajaković

  U duhu CrozCon-a

  continous-integration ci

• 08 Mar 11
  

  Chris 089

  Fowler on CI. Zitieren!

• 05 Mar 11
  

  Rodolfo Romero

  continuous_integration build build_process best_practice

  • 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 article is a quick overview of Continuous Integration summarizing the technique and its current usage.
• 15 Feb 11
  

  juha riissanen
  • On the whole I think the greatest and most wide ranging  benefit of Continuous Integration is reduced risk.
  • Continuous Integration completely finesses this  problem. There's no long integration, you completely eliminate  the blind spot. At all times you know where you are, what works,  what doesn't, the outstanding bugs you have in your system.
  • Continuous Integrations doesn't get rid of bugs, but it does make them dramatically easier to find and remove.
  • As a result projects with Continuous Integration tend to have  dramatically less bugs, both in production and in  process. However I should stress that the degree of this benefit  is directly tied to how good your test suite is. You should find  that it's not too difficult to build a test suite that makes a  noticeable difference. Usually, however, it takes a while before  a team really gets to the low level of bugs that they have the  potential to reach. Getting there means constantly working on  and improving your tests.

  2 more annotations...

• 30 Dec 10
  

  tersyon

  development agile programming

• 14 Dec 10
  

  vanarchi

  development agile continuousintegration ci

• 03 Dec 10
  

  farfromreality

  development continuous_intergration

  • Continuous Integration
  • Practices of Continuous Integration
  • Maintain a Single Source Repository.
  • The current open source repository of choice is Subversion.
  • The basic rule of thumb is that you should be able  to walk up to the project with a virgin machine, do a  checkout, and be able to fully build the system.
  • One of the features of version control systems is that they  allow you to create multiple branches, to handle different  streams of development. This is a useful, nay essential,  feature - but it's frequently overused and gets people into  trouble. Keep your use of branches to a minimum. In particular  have a mainline: a single branch of the project  currently under development. Pretty much everyone should work  off this mainline most of the time. (Reasonable branches are  bug fixes of prior production releases and temporary experiments.)
  • Automate the Build
  • Make sure you can build and launch your system using these scripts using a single command.
  • A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.
  • A big build often takes time, you don't want to do all of these steps if you've only made a small change. So a good build tool analyzes what needs to be changed as part of the process. The common way to do this is to check the dates of the source and object files and only compile if the source date is later. Dependencies then get tricky: if one object file changes those that depend on it may also need to be rebuilt. Compilers may handle this kind of thing, or they may not.
  • Many of us use IDEs, and most IDEs have some kind of build management process within them. However these files are always proprietary to the IDE and often fragile. Furthermore they need the IDE to work. It's okay for IDE users set up their own project files and use them for individual development. However it's essential to have a master build that is usable on a server and runnable from other scripts.
  • Make Your Build Self-Testing
  • A good way to catch bugs more quickly and efficiently is to include automated tests in the build process. Testing isn't perfect, of course, but it can catch a lot of bugs - enough to be useful. In particular the rise of Extreme Programming (XP) and Test Driven Development (TDD) have done a great deal to popularize self-testing code and as a result many people have seen the value of the technique.
  • For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. The tests need to be able to be kicked off from a simple command and to be self-checking. The result of running the test suite should indicate if any tests failed. For a build to be self-testing the failure of a test should cause the build to fail.
  • Everyone Commits To the Mainline Every Day
  • The one prerequisite for a developer committing to the  mainline is that they can correctly build their code. This, of  course, includes passing the build tests. As with any commit  cycle the developer first updates their working copy to match  the mainline, resolves any conflicts with the mainline, then  builds on their local machine. If the build passes, then they  are free to commit to the mainline.
  • My general rule of thumb is that every developer should  commit to the repository every day. In practice it's often  useful if developers commit more frequently than  that. The more frequently you commit, the less places you have  to look for conflict errors, and the more rapidly you fix  conflicts.
  • Every Commit Should Build the Mainline on an Integration Machine
  • Using daily commits, a team gets frequent tested  builds. This ought to mean that the mainline stays in a  healthy state. In practice, however, things still do go  wrong. One reason is discipline, people not doing an update  and build before they commit. Another is environmental  differences between developers' machines.
  • As a result you should ensure that regular builds happen on  an integration machine and only if this integration build  succeeds should the commit be considered to be done. Since the  developer who commits is responsible for this, that developer  needs to monitor the mainline build so they can fix it if it  breaks. A corollary of this is that you shouldn't go home  until the mainline build has passed with any commits you've  added late in the day.
  • There are two main ways I've seen to ensure this: using a manual build or a continuous integration server.
  • The manual build approach is the simplest one to  describe. Essentially it's a similar thing to the local build  that a developer does before the commit into the  repository. The developer goes to the integration machine,  checks out the head of the mainline (which now houses his last  commit) and kicks off the integration build. He keeps an eye  on its progress, and if the build succeeds he's done with his  commit.
  • A continuous integration server acts as a monitor to the  repository. Every time a commit against the repository  finishes the server automatically checks out the sources onto  the integration machine, initiates a build, and notifies the  committer of the result of the build. The committer isn't done  until she gets the notification - usually an email
  • Many organizations do regular builds on a timed schedule,  such as every night. This is not the same thing as a  continuous build and isn't enough for continuous  integration. The whole point of continuous integration is to  find problems as soon as you can. Nightly builds mean that  bugs lie undetected for a whole day before anyone discovers  them. Once they are in the system that long, it takes a long  time to find and remove them.
  • A key part of doing a continuous build is that if the  mainline build fails, it needs to be fixed right away. The  whole point of working with CI is that you're always  developing on a known stable base. It's not a bad thing for  the mainline build to break, although if it's happening all  the time it suggests people aren't being careful enough about  updating and  building locally before a commit. When the mainline build does  break, however, it's important that it gets fixed fast. To  help avoid breaking the mainline you might consider using a  pending head.
  • Keep the Build Fast
  • For most projects, however, the XP guideline of a ten  minute build is perfectly within reason.
  • If you're staring at a one hour build time, then getting to  a faster build may seem like a daunting prospect. It can even  be daunting to work on a new project and think about how to  keep things fast. For enterprise applications, at least, we've  found the usual bottleneck is testing - particularly tests  that involve external services such as a database.
  • Probably the most crucial step is to start working on setting up a staged build. The idea behind a staged build (also known as build pipeline) is that there are in fact multiple builds done in sequence. The commit to the mainline triggers the first build - what I call the commit build. The commit build is the build that's needed when someone commits to the mainline. The commit build is the one that has to be done quickly, as a result it will take a number of shortcuts that will reduce the ability to detect bugs. The trick is to balance the needs of bug finding and speed so that a good commit build is stable enough for other people to work on.
  • Once the commit build is good then other people can work on  the code with confidence. However there are further, slower,  tests that you can start to do. Additional machines can run  further testing routines on the build that take longer to  do.
  • A simple example of this is a two stage build. The first  stage would do the compilation and run tests that are more  localized unit tests with the database completely stubbed out.  Such tests can run very fast, keeping within the ten minute  guideline. However any bugs that involve larger scale  interactions, particularly those involving the real database,  won't be found. The second stage build runs a different suite  of tests that do hit the real database and involve more  end-to-end behavior. This suite might take a couple of hours  to run.
  • In this scenario people use the first stage as the commit  build and use this as their main CI cycle. The second-stage  build is a secondary build which runs when it  can, picking up the executable from the latest good commit  build for further testing.
  • If the secondary build detects a bug, that's a sign that the commit build could do with another test.
  • Make it Easy for Anyone to Get the Latest Executable
  • To help make this work, 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.
  • Everyone can see what's happening
  • Continuous Integration 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.
  • One of the most important things to communicate is the  state of the mainline build. If you're using Cruise  there's a built in web site that will show you if there's a  build in progress and what was the state of the last mainline  build.
  • Cruise provides an indication not just of  who is building, but what changes they made. Cruise also  provides a history of changes, allowing team members to get a  good sense of recent activity on the project. I know team  leads who like to use this to get a sense of what people have been  doing and keep a sense of the changes to the system.
  • Automate Deployment
  • To do Continuous Integration you need multiple  environments, one to run commit tests, one or more to run  secondary tests. Since you are moving executables between these  environments multiple times a day, you'll want to do this  automatically. So it's important to have scripts that will  allow you to deploy the application into any environment easily.
  • If you deploy into production one extra automated  capability you should consider is automated rollback. Bad  things do happen from time to time, and if smelly brown  substances hit rotating metal, it's good to be able to quickly  go back to the last known good state. Being able to  automatically revert also reduces a lot of the tension of  deployment, encouraging people to deploy more frequently and  thus get new features out to users quickly.
  • Benefits of Continuous Integration
  • Continuous Integrations doesn't get rid of bugs, but it does make them dramatically easier to find and remove. In this respect it's rather like self-testing code. If you introduce a bug and detect it quickly it's far easier to get rid of. Since you've only changed a small bit of the system, you don't have far to look. Since that bit of the system is the bit you just worked with, it's fresh in your memory - again making it easier to find the bug. You can also use diff debugging - comparing the current version of the system to an earlier one that didn't have the bug.
  • Bugs are also cumulative. The more bugs you have, the harder  it is to remove each one. This is partly because you get bug  interactions, where failures show as the result of multiple  faults - making each fault harder to find. It's also  psychological - people have less energy to find and get rid of  bugs when there are many of them - a phenomenon that the  Pragmatic Programmers call the Broken Windows syndrome.
  • As a result projects with Continuous Integration tend to have  dramatically less bugs, both in production and in  process. However I should stress that the degree of this benefit  is directly tied to how good your test suite is. You should find  that it's not too difficult to build a test suite that makes a  noticeable difference. Usually, however, it takes a while before  a team really gets to the low level of bugs that they have the  potential to reach. Getting there means constantly working on  and improving your tests.
  • Introducing Continuous Integration
  • One of the first steps is to get the build automated. Get  everything you need into source control get it so that you can  build the whole system with a single command. For many projects  this is not a minor undertaking - yet it's essential for any of  the other things to work. Initially you may only do build  occasionally on demand, or just do an automated nightly  build. While these aren't continuous integration an automated  nightly build is a fine step on the way.
  • Introduce some automated testing into you build. Try to  identify the major areas where things go wrong and get automated  tests to expose those failures. Particularly on an existing  project it's hard to get a really good suite of tests going  rapidly - it takes time to build tests up. You have to start  somewhere though - all those cliches about Rome's build schedule  apply.
  • Try to speed up the commit build. Continuous Integration on a build  of a few hours is better than nothing, but getting down to that  magic ten minute number is much better. This usually requires  some pretty serious surgery on your code base to do as you break  dependencies on slow parts of the system.
  • If you are starting a new project, begin with Continuous  Integration from the beginning. Keep an eye on build times and  take action as soon as you start going slower than the ten  minute rule. By acting quickly you'll make the necessary  restructurings before the code base gets so big that it becomes  a major pain.

  49 more annotations...

• 19 Nov 10
  

  agile software build integration

• 29 Sep 10
  

  Donald Matheson

  development programming software testing xp continuousintegration agile integration build productivity reference

• 

  craignicol

  Contiuous Integration (because some people haven't read it yet) http://martinfowler.com/articles/continuousIntegration.html

  via:packrati.us from:delicious

• 27 Sep 10
  

  ci continuousintegration

• 16 Sep 10
  

  Manuel Cerdá

  testing tools programming

• 11 Sep 10
  

  stachon

  development continuousintegration agile programming from-delicious

• 26 Aug 10
  

  paul winter

  programming

• 28 Jul 10
  

  walter simba
• 23 Jun 10
  

  AnandavelMurugan Chandramohan

  continuousintegration agile programming

• 01 Jun 10
  

  Augusto Elesbão

  agile continuousintegration development tools

• 21 May 10
  

  yong que

  Continuous Integration agile development

• 17 May 10
  

  Onno van der Straaten

  martinfowler continuousintegration practice

• 13 May 10
  

  Abdul Qabiz

  versioncontrol continuousintegration martinfowler temp ci testing xp software integration development build programming agile

• 08 May 10
  

  Marcus Pingel

  continuousintegration development agile programming software testing tools

• 23 Apr 10
  

  Hugo Baraúna

  martin fowler integracao continua

• 23 Mar 10
  

  Camilo Martinez

  continuousintegration agile development integration

• 19 Mar 10
  

  Ivan Pavlov

  development agile

• 16 Mar 10
  

  Nico Heid

  agile continuousintegration development

• 28 Feb 10
  

  accentcompetence

  ingenierie processus agile

• 14 Feb 10
  

  Rudiger Wolf

  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

  agile continuousintegration continuous management continuous-integration productivity automation programming build reference development

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.