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

Let's Map CI in a Causal Loop Diagram

Expand Messages
  • Jay Flowers
    I think there is a lot to be gained from the perspective(s) that System Thinking has to offer. Please join me in an effort to map Continuous Integration in a
    Message 1 of 4 , May 30, 2007
    • 0 Attachment
      I think there is a lot to be gained from the perspective(s) that
      System Thinking has to offer. Please join me in an effort to map
      Continuous Integration in a Causal Loop Diagram. I have a small start
      up on my wiki here:
      http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.
      You can work with the diagram by installing the free software from
      the link at the top of the page, the map file link is just under the
      diagram.

      What do you think?

      --
      Jay Flowers
      ----------------------------------------------------------------------
      http://jayflowers.com
      ---------------------------------------------------------------------
    • Brad Appleton
      Interesting idea. You might want to take a peek at the following: * Codeline Merging and Locking: Continuous Updates and Two-Phased Commits
      Message 2 of 4 , May 30, 2007
      • 0 Attachment
        Interesting idea. You might want to take a peek at the following:

        * Codeline Merging and Locking: Continuous Updates and Two-Phased Commits
        (http://www.cmcrossroads.com/content/view/6893/202/)

        This paper mentions many of the same "froces" that your URL below does,
        as well as several different patterns for many of the same probelms and
        when each is/isnt most appropriate

        * Agile Build Promotion: Navigating the Ocean of Promotion Notions
        (http://www.cmcrossroads.com/content/view/6729/202/)

        Here the most useful diagrams pictures might be the table describing the
        different purposes/forces for the three different kinds of builds, and
        then the subsequent circular "bullseye" diagram that depicts it, and the
        different level of visibility/scale/frequency feedback each provides.
        The stuff it delves into later about "promotion levels" is less
        interesting for your purpose, other than the fact that each "promotion
        level" may correspond to another level of integration and hence
        visibility/frequency & feedback

        * Continuous Staging: Scaling Continuous Integration to Multiple
        Component Teams
        (http://www.cmcrossroads.com/content/view/6869/202/)

        This paper discusses patterns for one of the main approaches to
        "scaling" CI for a large system (or system of systems), [the other main
        approach involves integrating by "feature" rather than by
        subsystem/component]. Again, it mentions different patterns each
        resolving different combinations of forces and levels of
        feedback/scale/frequency

        Also notice in general that for each type/level of "build" there tends
        to be not just a pattern for it, but also a corresponding pattern for a
        same-typed workspace, integration, and even test. E.g.,
        * (private build, private workspace, private branch, rebasing/commit)
        * (team integration build, integration workspace, Active development
        line, mainlining)
        * (release build, release workspace (and/or staging area), release-line)

        Cheers!
        Jay Flowers wrote:
        >
        >
        > I think there is a lot to be gained from the perspective(s) that
        > System Thinking has to offer. Please join me in an effort to map
        > Continuous Integration in a Causal Loop Diagram. I have a small start
        > up on my wiki here:
        > http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.
        > <http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.>
        > You can work with the diagram by installing the free software from
        > the link at the top of the page, the map file link is just under the
        > diagram.
        >
        > What do you think?
        >
        > --
        > Jay Flowers
        > ----------------------------------------------------------
        > http://jayflowers.com <http://jayflowers.com>
        > ----------------------------------------------------------
        >
        >

        --
        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
      • Jay Flowers
        Thanks Brad. :-) ... -- Jay Flowers ... http://jayflowers.com ... [Non-text portions of this message have been removed]
        Message 3 of 4 , Jun 1, 2007
        • 0 Attachment
          Thanks Brad. :-)

          On 5/31/07, Brad Appleton <Brad.Appleton@...> wrote:
          >
          > Interesting idea. You might want to take a peek at the following:
          >
          > * Codeline Merging and Locking: Continuous Updates and Two-Phased Commits
          > (http://www.cmcrossroads.com/content/view/6893/202/)
          >
          > This paper mentions many of the same "froces" that your URL below does,
          > as well as several different patterns for many of the same probelms and
          > when each is/isnt most appropriate
          >
          > * Agile Build Promotion: Navigating the Ocean of Promotion Notions
          > (http://www.cmcrossroads.com/content/view/6729/202/)
          >
          > Here the most useful diagrams pictures might be the table describing the
          > different purposes/forces for the three different kinds of builds, and
          > then the subsequent circular "bullseye" diagram that depicts it, and the
          > different level of visibility/scale/frequency feedback each provides.
          > The stuff it delves into later about "promotion levels" is less
          > interesting for your purpose, other than the fact that each "promotion
          > level" may correspond to another level of integration and hence
          > visibility/frequency & feedback
          >
          > * Continuous Staging: Scaling Continuous Integration to Multiple
          > Component Teams
          > (http://www.cmcrossroads.com/content/view/6869/202/)
          >
          > This paper discusses patterns for one of the main approaches to
          > "scaling" CI for a large system (or system of systems), [the other main
          > approach involves integrating by "feature" rather than by
          > subsystem/component]. Again, it mentions different patterns each
          > resolving different combinations of forces and levels of
          > feedback/scale/frequency
          >
          > Also notice in general that for each type/level of "build" there tends
          > to be not just a pattern for it, but also a corresponding pattern for a
          > same-typed workspace, integration, and even test. E.g.,
          > * (private build, private workspace, private branch, rebasing/commit)
          > * (team integration build, integration workspace, Active development
          > line, mainlining)
          > * (release build, release workspace (and/or staging area), release-line)
          >
          > Cheers!
          > Jay Flowers wrote:
          > >
          > >
          > > I think there is a lot to be gained from the perspective(s) that
          > > System Thinking has to offer. Please join me in an effort to map
          > > Continuous Integration in a Causal Loop Diagram. I have a small start
          > > up on my wiki here:
          > > http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.
          > > <http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.>
          > > You can work with the diagram by installing the free software from
          > > the link at the top of the page, the map file link is just under the
          > > diagram.
          > >
          > > What do you think?
          > >
          > > --
          > > Jay Flowers
          > > ----------------------------------------------------------
          > > http://jayflowers.com <http://jayflowers.com>
          > > ----------------------------------------------------------
          > >
          > >
          >
          > --
          > 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
          >
          >



          --
          Jay Flowers
          ----------------------------------------------------------------------
          http://jayflowers.com
          ---------------------------------------------------------------------


          [Non-text portions of this message have been removed]
        • Jay Flowers
          I have made some progress. I have identified variables from the Article Continuous
          Message 4 of 4 , Jun 1, 2007
          • 0 Attachment
            I have made some progress. I have identified variables from the Article
            Continuous Integration<http://www.martinfowler.com/articles/continuousIntegration.html>and
            Software
            Configuration Management Patterns: Effective Teamwork, Practical
            Integration<http://www.amazon.com/Software-Configuration-Management-Patterns-Integration/dp/0201741172/ref=sr_1_1/102-1023087-7897755?ie=UTF8&s=books&qid=1180609369&sr=8-1>.
            I am assuming a trigger based CI setup, a build is trigger when changes to
            the source control repository are detected. These are what I have so far:

            - Commit/Build Frequency
            - Changeset Size
            - Speed of the Build
            - Stability of the Codeline
            - Size of the Team
            - Effectiveness of Tests
            - Availability of Product
            - Information Radiation
            - Risk of Break
            - Time to find and fix bugs
            - Rate of Change to Codeline
            - Size of Team
            - Avg Time to Fix a Broken Build
            - Frequency of Broken Builds
            - Build Availability
            - Workspace tractability
            - Task Size

            The diagram has gotten a bit complex, as was expected.

            <http://jayflowers.com/doku/lib/exe/detail.php?id=creating_a_loop_diagram_for_ci&cache=cache&media=ci-loop-diagram-1.png>

            It is by no means complete. What is missing?

            To get a better understanding of what is going on I have started trying to
            identify one or more Systems Archetypes.

            Here are a few resources for identifying Archetypes:

            http://www.systems-thinking.org/arch/arch.htm
            http://www.exponentialimprovement.com/cms/uploads/ArchetypesGeneric02.pdf
            http://www.exponentialimprovement.com/cms/uploads/Archetypes%20Gang%20Up7.pdf

            What archetypes do you see?


            On 5/30/07, Jay Flowers <jay.flowers@...> wrote:
            >
            > I think there is a lot to be gained from the perspective(s) that
            > System Thinking has to offer. Please join me in an effort to map
            > Continuous Integration in a Causal Loop Diagram. I have a small start
            > up on my wiki here:
            > http://jayflowers.com/doku/doku.php?id=creating_a_loop_diagram_for_ci.
            > You can work with the diagram by installing the free software from
            > the link at the top of the page, the map file link is just under the
            > diagram.
            >
            > What do you think?
            >
            > --
            > Jay Flowers
            > ----------------------------------------------------------------------
            > http://jayflowers.com
            > ---------------------------------------------------------------------
            >



            --
            Jay Flowers
            ----------------------------------------------------------------------
            http://jayflowers.com
            ---------------------------------------------------------------------


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