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

Re: [XP] Continuous Integration Question

Expand Messages
  • Ron Jeffries
    Hello, Jeffrey. On Friday, February 2, 2007, at 12:10:07 PM, you ... Yes ... and certainly what I /really/ think is that its the version on hand at the end of
    Message 1 of 120 , Feb 2, 2007
      Hello, Jeffrey. On Friday, February 2, 2007, at 12:10:07 PM, you
      wrote:

      > On 2/2/07, Ron Jeffries <ronjeffries@...> wrote:
      >> >>
      >> >> We should be able to ship the current build at any time.
      >> >>

      > Looking back I think this is the critical point to explore.

      Yes ... and certainly what I /really/ think is that its the version
      on hand at the end of the iteration that should be shippable.

      However ... we never know which version that'll be. So it seems
      prudent to me that every promoted build should always be better than
      the last.

      >> The point of Continuous Integration is, I imagine, to have the
      >> system integrated all the time. I would say that there are at least
      >> the following objectives to Continuous Integration:
      >>
      >> 1. The head of the code line is always good: a developer can bring
      >> down the head and be certain that any defect in the code, going
      >> forward, will be his own.
      >>
      >> 2. The head of the code line is always the most shippable version
      >> ever: it has more features and fewer defects than any prior version.
      >>
      >> For these objectives to be met, one has to check in good code. If
      >> any code checked in is not good, i.e. doesn't run all the tests,
      >> then the objectives are not met.
      >>

      > Having a build that is _always_ shippable is great, better than having
      > a build that is _almost_ always shippable. But aren't there
      > trade-offs between the always and almost?

      Yes ... but I'd bet that they aren't what we think they are.

      > Perhaps you don't, but this seems like a situation where smart
      > thoughtful people could disagree, especially if their situations are
      > different.

      This word, situation (the second one). Perhaps to you it means "how
      things are". To me, it means "how we make things be". I don't think
      our job is to observe our fate and figure out how to live with it. I
      think our job is to create our fate.

      >> Would you, Kevin, and the world at large, agree that if we promote
      >> code before we test it, code at the head of the line will be broken
      >> more often than if we promote and then test?

      > Just curious, but what do you mean by "promote" in your case? Do you
      > mean that your intial commit is to a private branch and then you
      > commit to the head or are you moving a tag or what?

      I don't care about the implementation. I want things to be such that
      nothing on the head is ever broken.

      >> I would be interested to see a matrix drawn up listing all kinds of
      >> objectives such as those I listed above, and evaluating each kind of
      >> build against each objective, kind of like the car mags evaluate all
      >> the cars in a test against a list of criteria.

      > That's a fantastic suggestion!

      > For my part with continuous integration I've never had "always" as an
      > objective -- I would take your two and say that almost always was good
      > enough but with additional objective of

      > 3. knowing the state of the code base at all time.

      Would we agree that Knowing is better than not knowing ... but
      knowing it's bad is a lot worse than knowing it's good?

      > Clearly you know the state of the build at all times with your
      > approach also (it is good), but since I don't all the fancy lights and
      > emails are helpful to let me know when I've strayed off the path... so
      > that I can quickly get back to good.

      > In the car mag model of reviewing does this mean I get the 3/4 full
      > dot instead of the totally full one?

      Perhaps something like that ...

      > Now here is where I have a question about the relative trade-offs:
      > with your approach is there an incremental cost at every commit over
      > mine? Agree I'll need to pay an extra cost in those cases where the
      > build breaks, but if the cost is both small and rare perhaps I come
      > out ahead?

      I don't know whether there is or not. I think that the CC capability
      was originally invented by a large team with a relatively slow
      build, and, I think, a long time between commits. I wonder what
      would have happened had they resolved those other issues instead of
      coding around them.

      > Then it comes down also to the imperative from the top of the message:
      > "We should be able to ship the current build at any time".

      > Why?

      Because whenever we have a build that we cannot ship, we have an
      unknown amount of work to do until we can ship it. And therefore our
      velocity measurements are inaccurate. And therefore our projections
      of when we'll be done are inaccurate.

      Continuous integration of a system that works -- running tested
      features as I've called it -- is the best way I know to have clear
      knowledge of where we are.

      When a better way comes along, I'll support it. When compromised
      ways come along ... not so much.

      > I'll grant that in any situation where that imperative exists then you
      > must have a process where you can _always_ ship. But I don't -- and
      > have never -- worked on a team where that was an imperative. I
      > certainly like the idea, but I just never had the need; it has always
      > been good enough if we could ship "soon", where "soon" ranged from
      > hours to weeks, depending on the company, product, and means of
      > delivery.

      Maybe it's not about need. Maybe it's about what would be enabled if
      we learned how to be ready "now" instead of "pretty soon".

      > If my system allows me to meet the needs of my context and at a lower
      > cost then that seems a better approach... for me, when in this
      > context.

      This word, context ... ;->

      Ron Jeffries
      www.XProgramming.com
      Learn the principle, abide by the principle, and dissolve the principle.
      -- Bruce Lee
    • Brad Appleton
      ... The usage is the same - it has many aliases, and developer s branch (or Developer Branch ) is one of the known ones for quite some time. -- Brad
      Message 120 of 120 , Feb 11, 2007
        Slava Imeshev wrote:
        > Brad, it's not another name for "Private Branch". It is just a developer's branch.
        > Or Developer Branch if You Want To Speak Like Patterns...

        The usage is the same - it has many aliases, and "developer's branch"
        (or "Developer Branch") is one of the known ones for quite some time.

        --
        Brad Appleton <brad {AT} bradapp.net>
        Agile CM Environments (http://blog.bradapp.net/)
        & Software CM Patterns (www.scmpatterns.com)
        "And miles to go before I sleep" -- Robert Frost
      Your message has been successfully submitted and would be delivered to recipients shortly.