Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Continuous integration and testing server problem

Expand Messages
  • M. Manca
    ... Mmmm... the projects has more then 250 files so the build can t be done in less then some minutes I suppose. In my opinion if the continuous build system
    Message 1 of 3 , Aug 15, 2012
      Il 15/08/2012 23:24, Adam Sroka ha scritto:
      >
      >
      > On Wed, Aug 15, 2012 at 1:51 PM, M. Manca
      > <m.manca@... <mailto:m.manca%40micronengineering.it>>
      > wrote:
      > >
      > >
      > >
      > > Hi all,
      > > I have a customer with a problem on his continuous integration and
      > > testing server. I already use one but in practice I have no conflicts
      > > like those reported by him, so I would like to understand if some of you
      > > had problems to run a continuous integration and testing server (CITS)
      > > with scenarios similar to these:
      > >
      > > 1. there is a project already in CITS and it worked perfectly for months
      > > providing a service to see if the source code repository (based on git)
      > > is changed, if yes it will be built and tested (regression testing).
      > >
      > > 2. until now the customer didn't report any problem, now what
      > happens is:
      > > a) if a developer changes (push) one or more source code files in the
      > > repository during a built already started by the CITS (as for a previous
      > > push made by another developer) also the last pushed files are built and
      > > then tested
      > > b) if a developer changes (push) one or more source code files in the
      > > repository after the built due to previous modifications but before the
      > > regression test is started a new build starts and then when it will
      > > finish will start the regression test.
      > >
      > > Do you think that is correct or a fault? Previously my customer said
      > > that didn't happen and for him is a fault because he would like to have
      > > a complete build and regression testing for every change push to the
      > > repository.
      > >
      >
      > Sounds like either a configuration or behavioral problem, or perhaps a
      > combination. Configuration depends on the product they are using to do
      > the build, but it is possible that the build takes too long and/or
      > that you need a longer timeout to ensure things are being batched
      > together properly.
      >
      > The build shouldn't take too long. In 1990s terms that means less than
      > ten minutes. In modern terms aim for sub-minute.
      >
      Mmmm... the projects has more then 250 files so the build can't be done
      in less then some minutes I suppose.
      In my opinion if the continuous build system tool can't manage this
      situation should be better to realize something like:

      1. CITS detects a change in the development repository so it blocks the
      access to the repository
      2. CITS creates a private branch that will be used to build and test the
      system
      3. CITS free the access to the repository
      4. CITS build and tests sthe last branch it mades
      5. If every thing went ok the branch should be merged with the
      development branch
      and from here CITS may restart to check if something changed and so it
      could build and test a new push.

      what do you think about?
      >
      > If it takes much
      > longer than that people will either start to check in without waiting
      > or start taking more frequent breaks, or both. Bumping up the wait
      > period before additional changes are pulled is one remedial solution
      > that many have used, but it makes things slower not faster.
      >
      > The behavioral issue is that folks really shouldn't be pushing code
      > until they know the integration build is passing. If the integration
      > build is failing or in progress (i.e. unknown state) then we don't
      > know that we can safely push. Better off to pull the latest and test
      > locally and then push after you know it works both locally and on the
      > server.
      >
      > An integration token might help. If the team is distributed they may
      > want to consider a tool that can do two-phase commits (e.g. TeamCity.)
      >
      > To really grok CI you need to also understand the practice of
      > Collective Code Ownership. There can be only one authoritative version
      > of the system. That is the one that is checked in. If that is broken
      > everyone is broken. There is no such thing as "works for me."
      >
      >



      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.