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

Rationale behind one step build process.

Expand Messages
  • John Carter
    I have just realized that a major source of conflict between myself and another developer on the team is the following. I think having a one step build process
    Message 1 of 15 , Feb 29, 2004
      I have just realized that a major source of conflict between myself and
      another developer on the team is the following.

      I think having a one step build process is very important, and he thinks
      having versioned libraries are important.

      I believe you should be able to build the entire product directly from the
      source code in one step, ensuring no breakage. (Bitrot)

      He believes that each subteam should deliver "tested, closed, sealed and
      signed, versioned binary libraries" to the rest of the team.

      I believe that when you check into CVS mainline you are versioning,
      signing and sealing that you have compiled, tested and it works.

      I believe the only thing binary libraries gives you these days is a
      screwed up dependency tree at "make" time and maybe a second or two at
      link time.

      Does anyone have any opinions, pointers to "Best Practice" literature /
      web sites to support either view.



      John Carter Phone : (64)(3) 358 6639
      Tait Electronics Fax : (64)(3) 359 4632
      PO Box 1645 Christchurch Email : john.carter@...
      New Zealand

      Note to all marketers. If you want to sell things to me, buy Google words.

      I refuse on principle to buy anything sold by spam or popup and I
      never follow any links found in a spam. I do however use Google and
      will often follow the neat non-irritating Google Word ads that are of
      interest to me.
    • Edmund Schweppe
      ... Is there a particularly good reason why your team should not have *both* versioned libraries *and* a one-step build process? -- Edmund Schweppe --
      Message 2 of 15 , Feb 29, 2004
        John Carter wrote:
        > I have just realized that a major source of conflict between myself
        > and another developer on the team is the following.
        >
        > I think having a one step build process is very important, and he
        > thinks having versioned libraries are important.

        Is there a particularly good reason why your team should not have *both*
        versioned libraries *and* a one-step build process?

        --
        Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
        The opinions expressed herein are at best coincidentally related to
        those of any past, present or future employer.
      • John Carter
        ... Well, in my opinion the having blest binaries gives you nothing but complexity. Version the source and the versioning the binaries comes for free. Pull
        Message 3 of 15 , Feb 29, 2004
          On Sun, 29 Feb 2004, Edmund Schweppe wrote:

          > Is there a particularly good reason why your team should not have *both*
          > versioned libraries *and* a one-step build process?

          Well, in my opinion the having "blest" binaries gives you nothing but
          complexity.

          Version the source and the versioning the binaries comes for free. Pull
          the "libraries" source into seperate CVS modules that allows them to
          evolve at different rates, and who cares if you pack the .object files
          into a "lib" file or not?

          In fact, the only thing you have is the "make" dependency tracking from
          source file to executable via lib file is usually broken in most build
          systems I have seen. ie. How many times have you seen someone pulling
          their hair out, "we made the change in the source, but it is not in the
          executable!"? (They forgot to rebuild the library)

          In my view is "library" or not is an artifact of the CVS module structure
          and source level interfaces, and has nothing to do with the build system.

          In his view, the build system should package things into libBlah.a's and
          refer to libBlah.a's.

          As far as I can see, the _only_ advantage is slightly (very
          slightly) faster linking times.


          John Carter Phone : (64)(3) 358 6639
          Tait Electronics Fax : (64)(3) 359 4632
          PO Box 1645 Christchurch Email : john.carter@...
          New Zealand

          Note to all marketers. If you want to sell things to me, buy Google words.

          I refuse on principle to buy anything sold by spam or popup and I
          never follow any links found in a spam. I do however use Google and
          will often follow the neat non-irritating Google Word ads that are of
          interest to me.
        • Larry Brunelle
          I can conceive versioning BINARIES if and only if you find (as we recently did with externally-developed library libwwwblahblahwhateveritwas) that the build is
          Message 4 of 15 , Feb 29, 2004
            I can conceive versioning BINARIES if and only if you
            find (as we recently did with externally-developed library
            libwwwblahblahwhateveritwas) that the build is very fragile
            (due to supplied configure scripts) and hard to build, and
            you fear losing the binary.

            In our case, it was wisely decided that this also was not
            a reason for versioning a binary. (You have to back it up,
            never mind the versioning.)

            Dunno about CVS, but in Clearcase, the binaries are usually
            view-private, not VOB elements. I have never worked where
            binaries were versioned. Unless you count the version-
            numbered complete builds on CD. And for release builds,
            a clean build (make clean, delete those binaries) has
            always been a requirement, large firm or small.



            John Carter wrote:
            > I have just realized that a major source of conflict between myself and
            > another developer on the team is the following.
            >
            > I think having a one step build process is very important, and he thinks
            > having versioned libraries are important.
            >
            > I believe you should be able to build the entire product directly from the
            > source code in one step, ensuring no breakage. (Bitrot)
            >
            > He believes that each subteam should deliver "tested, closed, sealed and
            > signed, versioned binary libraries" to the rest of the team.
            >
            > I believe that when you check into CVS mainline you are versioning,
            > signing and sealing that you have compiled, tested and it works.
            >
            > I believe the only thing binary libraries gives you these days is a
            > screwed up dependency tree at "make" time and maybe a second or two at
            > link time.
            >
            > Does anyone have any opinions, pointers to "Best Practice" literature /
            > web sites to support either view.
            >
            >
            >
            > John Carter Phone : (64)(3) 358 6639
            > Tait Electronics Fax : (64)(3) 359 4632
            > PO Box 1645 Christchurch Email : john.carter@...
            > New Zealand
            >
            > Note to all marketers. If you want to sell things to me, buy Google words.
            >
            > I refuse on principle to buy anything sold by spam or popup and I
            > never follow any links found in a spam. I do however use Google and
            > will often follow the neat non-irritating Google Word ads that are of
            > interest to me.
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
          • James Cloughley
            It sounds like the motivation behind this developer has nothing to do with building or CVS. In my opinion, this developer wants to draw a box around
            Message 5 of 15 , Mar 1, 2004
              It sounds like the motivation behind this developer has nothing to do with building or CVS. In my opinion, this developer wants to draw a box around themselves such that they're only responsible for their "tested, closed, sealed and signed binaries". So if an issue occurs, they can clearly delineate the cause and point it away from their "hidden" code. This seems very un-XP to me.

              Another motivation may be some notion of job security such that only this subteam would understand how this library works. This seems very un-XP to me.

              It sounds like this developer has been burned in the past (most likely imappropriately) and perhaps is trying to mitigate risk by drawing a line in the sand. This behaviour seems very un-XP to me.

              We have one source repository from where many products are built. We have at least 3 dlls that I can think of that are built from this code. The code is packaged as a dll because we share it across applications (in C and in Java). One dll is an encryption dll that our clients can replace with their own method of encryption. In these cases, it makes sense to encapsulate the functionality into a dll because the purpose is to share it or replace it. However, the code is still built from a common library that everyone has access to.

              Maybe they're just more comfortable with the application layer mimicing the architecture layer. Although these should remain decoupled in case either changes.

              Every developer I've met has their own 'isms (Fredisms, Johnisms, etc) that you need to learn how to deal with. I'd see this as an opportunity to speak with the individual and let the disagreement evolve to perhaps a better design than what either side currently desires.

              Jim

              -----Original Message-----
              From: John Carter [mailto:john.carter@...]
              Sent: Sun 2/29/2004 7:56 PM
              To: extremeprogramming@yahoogroups.com
              Cc:
              Subject: [XP] Rationale behind one step build process.



              I have just realized that a major source of conflict between myself and
              another developer on the team is the following.

              I think having a one step build process is very important, and he thinks
              having versioned libraries are important.

              I believe you should be able to build the entire product directly from the
              source code in one step, ensuring no breakage. (Bitrot)

              He believes that each subteam should deliver "tested, closed, sealed and
              signed, versioned binary libraries" to the rest of the team.

              I believe that when you check into CVS mainline you are versioning,
              signing and sealing that you have compiled, tested and it works.

              I believe the only thing binary libraries gives you these days is a
              screwed up dependency tree at "make" time and maybe a second or two at
              link time.

              Does anyone have any opinions, pointers to "Best Practice" literature /
              web sites to support either view.



              John Carter Phone : (64)(3) 358 6639
              Tait Electronics Fax : (64)(3) 359 4632
              PO Box 1645 Christchurch Email : john.carter@...
              New Zealand

              Note to all marketers. If you want to sell things to me, buy Google words.

              I refuse on principle to buy anything sold by spam or popup and I
              never follow any links found in a spam. I do however use Google and
              will often follow the neat non-irritating Google Word ads that are of
              interest to me.


              To Post a message, send it to: extremeprogramming@...

              To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

              ad-free courtesy of objectmentor.com
              Yahoo! Groups Links









              [Non-text portions of this message have been removed]
            • Keith Ray
              ... More important is to have a set of libraries whose dependancy tree is not cyclic. Having all the source accessible in ClearCase or CVS can result in big
              Message 6 of 15 , Mar 1, 2004
                >> having versioned libraries are important.

                More important is to have a set of libraries whose dependancy tree is
                not cyclic. Having all the source accessible in ClearCase or CVS can
                result in big system-wide balls of mud and long build times, if the
                team(s) don't have a lot of discipline.

                --
                C. Keith Ray
                <http://homepage.mac.com/keithray/blog/index.html>
                <http://homepage.mac.com/keithray/xpminifaq.html>
                <http://homepage.mac.com/keithray/resume2.html>
              • BETIS Alexandre
                Hi, I don t know if this will help sort out the debate much, but on our project we had that binary that was delivered by an external person and that we kept
                Message 7 of 15 , Mar 1, 2004
                  Hi,

                  I don't know if this will help sort out the debate much, but on our project we had that binary that was delivered by an external person and that we kept out of the CVS tree.

                  With no acceptance testing of any sort. All right. Stop smirking.

                  So, all was fine as long as we did not have any change to make.

                  And then (ominous sound playing here), we had to modify the code. Of course, we modified the binary off-CVS, and when doing this, we instantly lost the hability to go back to a previous released version.

                  And then (thunderbolts), the external person lost the "quickly hacked" source code for the release patch. When we wanted to add additional patches, we could not guarantee non-regression.

                  So finally (grunt), we CVS'ed whatever source code we could obtain, and painfully re-factored until requested patching level was reached.

                  SO, my personal conclusion on the topic could be along these lines:

                  * If, for whatever reason, you HAVE to deal with binary libraries or apps in your build process, CVS'em BUT /do/ acceptance test'em!

                  * Better is to have everything as source under CVS and be able to build it using a single 'make' command.

                  -- Alex

                  > -----Message d'origine-----
                  > De : Larry Brunelle [mailto:brunelle@...]
                  > Envoyé : lundi 1 mars 2004 04:08
                  > À : extremeprogramming@yahoogroups.com
                  > Objet : Re: [XP] Rationale behind one step build process.
                  >
                  >
                  > I can conceive versioning BINARIES if and only if you
                  > find (as we recently did with externally-developed library
                  > libwwwblahblahwhateveritwas) that the build is very fragile
                  > (due to supplied configure scripts) and hard to build, and
                  > you fear losing the binary.
                  >
                  > In our case, it was wisely decided that this also was not
                  > a reason for versioning a binary. (You have to back it up,
                  > never mind the versioning.)
                  >
                  > Dunno about CVS, but in Clearcase, the binaries are usually
                  > view-private, not VOB elements. I have never worked where
                  > binaries were versioned. Unless you count the version-
                  > numbered complete builds on CD. And for release builds,
                  > a clean build (make clean, delete those binaries) has
                  > always been a requirement, large firm or small.
                  >
                  >
                  >
                  > John Carter wrote:
                  > > I have just realized that a major source of conflict
                  > between myself and
                  > > another developer on the team is the following.
                  > >
                  > > I think having a one step build process is very important,
                  > and he thinks
                  > > having versioned libraries are important.
                  > >
                  > > I believe you should be able to build the entire product
                  > directly from the
                  > > source code in one step, ensuring no breakage. (Bitrot)
                  > >
                  > > He believes that each subteam should deliver "tested,
                  > closed, sealed and
                  > > signed, versioned binary libraries" to the rest of the team.
                  > >
                  > > I believe that when you check into CVS mainline you are versioning,
                  > > signing and sealing that you have compiled, tested and it works.
                  > >
                  > > I believe the only thing binary libraries gives you these days is a
                  > > screwed up dependency tree at "make" time and maybe a
                  > second or two at
                  > > link time.
                  > >
                  > > Does anyone have any opinions, pointers to "Best Practice"
                  > literature /
                  > > web sites to support either view.
                  > >
                  > >
                  > >
                  > > John Carter Phone : (64)(3) 358 6639
                  > > Tait Electronics Fax : (64)(3) 359 4632
                  > > PO Box 1645 Christchurch Email :
                  > john.carter@...
                  > > New Zealand
                  > >
                  > > Note to all marketers. If you want to sell things to me,
                  > buy Google words.
                  > >
                  > > I refuse on principle to buy anything sold by spam or popup and I
                  > > never follow any links found in a spam. I do however use Google and
                  > > will often follow the neat non-irritating Google Word ads
                  > that are of
                  > > interest to me.
                  > >
                  > >
                  > > To Post a message, send it to: extremeprogramming@...
                  > >
                  > > To Unsubscribe, send a blank message to:
                  > extremeprogramming-unsubscribe@...
                  > >
                  > > ad-free courtesy of objectmentor.com
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  > >
                  > >
                  >
                  >
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  > extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                • Ayerst, Tom
                  I would rather require the discipline (and perhaps jdepends with junit in the build). In my experience pre-built, team-owned binaries, leads to confusion and
                  Message 8 of 15 , Mar 1, 2004
                    I would rather require the discipline (and perhaps jdepends with junit in
                    the build). In my experience pre-built, team-owned binaries, leads to
                    confusion and misconfigured systems rather than the reverse.

                    Isn't this really just a build optimisation? Shouldn't it go the route of
                    all optimisations?

                    Rgds

                    Tom

                    -----Original Message-----
                    From: Keith Ray [mailto:keithray@...]
                    Sent: 01 March 2004 15:20
                    To: extremeprogramming@yahoogroups.com
                    Subject: Re: [XP] Rationale behind one step build process.


                    >> having versioned libraries are important.

                    More important is to have a set of libraries whose dependancy tree is
                    not cyclic. Having all the source accessible in ClearCase or CVS can
                    result in big system-wide balls of mud and long build times, if the
                    team(s) don't have a lot of discipline.

                    --
                    C. Keith Ray
                    <http://homepage.mac.com/keithray/blog/index.html>
                    <http://homepage.mac.com/keithray/xpminifaq.html>
                    <http://homepage.mac.com/keithray/resume2.html>



                    To Post a message, send it to: extremeprogramming@...

                    To Unsubscribe, send a blank message to:
                    extremeprogramming-unsubscribe@...

                    ad-free courtesy of objectmentor.com
                    Yahoo! Groups Links






                    --------------------------------------------------------------------------------
                    The information contained herein is confidential and is intended solely for the
                    addressee. Access by any other party is unauthorised without the express
                    written permission of the sender. If you are not the intended recipient, please
                    contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
                    via e-mail return. If you have received this e-mail in error or wish to read our
                    e-mail disclaimer statement and monitoring policy, please refer to
                    http://www.drkw.com/disc/email/ or contact the sender.
                    --------------------------------------------------------------------------------
                  • Brad Appleton
                    ... You are both correct :-) ... Highly desirable. Not always feasible. It depends upon relationships between subteams, and their respective rhythms , as well
                    Message 9 of 15 , Mar 1, 2004
                      On Mon, Mar 01, 2004 at 01:56:13PM +1300, John Carter wrote:
                      > I think having a one step build process is very important,
                      > and he thinks having versioned libraries are important.

                      You are both correct :-)

                      > I believe you should be able to build the entire product
                      > directly from the source code in one step, ensuring no
                      > breakage. (Bitrot)

                      Highly desirable. Not always feasible. It depends upon
                      relationships between subteams, and their respective "rhythms",
                      as well as geographical dispersement (and timezone), repository
                      size and performance, system-build performance and available
                      network resources, etc.

                      > He believes that each subteam should deliver "tested, closed,
                      > sealed and signed, versioned binary libraries" to the rest of the team.

                      If the team is large or dispersed enough to actually warrant
                      "subteams", he may be right - to a point. I believe each team
                      should be responsible for ensuring it delivers working code
                      *and* executables to other internal stakeholders. In XP, I do
                      this with Continuous Integration by ensuring every commit to
                      the codebase builds and passes all the tests PLUS explicitly
                      identifying any version of the codebase that needs to be
                      accessed by internal stakeholders (e.g., using a label/tag so
                      that if anyone needs to look at it even after its no longer
                      "latest and greatest" they can easily do so - as is often the
                      case when a "build" must be handed-off to a QA/V&V group who
                      require more time to do "their job" with it than it takes to
                      complete and commit the next "task")

                      > I believe that when you check into CVS mainline you are versioning,
                      > signing and sealing that you have compiled, tested and it works.

                      Yes (assuming continuous integration) - for the set of things that
                      are in that repository and which are built and tested in that repository.
                      If the repository contains several independently buildable components,
                      and people only build their components rather than the "whole shmeer",
                      you are doing this only for that component.

                      Ideally - you have the storage capacity, and network bandwidth,
                      and processing power, and load distribution, to build the whole
                      system (or at least incrementally build the whole system) everytime
                      before you commit.

                      Sometimes, for reasons of build-cycle-time, or network resource load,
                      or schedule coordination (e.g, multiple timezones, or interdependent
                      delivery schedules of components), or other reasons, this is not
                      always feasible.

                      A common best-practice used here that tries to balance the
                      best of both is what is called a "Staging Area" or "Staging
                      Environment". A Staging Environment is like a "sandbox" or
                      "workspace" reserved for sharing build+test dependent artifacts
                      (headers, libraries, executables, etc.). It works something
                      like this (note, this is NOT specific to XP/Agile development):
                      * Each subteam "does its thing" and builds and compiles its
                      code as they should and commits it to their repository

                      * At agreed-upon points in time, the subteam "delivers" any
                      artifacts that other teams require in order to build (headers,
                      APIs, libraries, configs, etc.) into the staging area
                      (and ideally some additional level of build+test is done)

                      * When building in ones private developer workspace or even
                      a subteams integration workspace/machine, the compilers and
                      linkers (etc.) point to the "official" staging area for the
                      non-subteam owned artifacts needed for the subteam to build

                      The issue of versioning comes into play if it is necessary to
                      know which version of a component is the "current" one in the
                      staging area. If necessary, then:
                      * When a subteam build has its executables delivered to the
                      staging area, it also creates a corresponding tag/label,
                      and perhaps writes it to a file (e.g., README or whatever)
                      for that component in the staging area (this is a "simple
                      persons" implementation of what might be more formally called
                      a "version description document" or VDD at the component-level

                      If versioning is required, then it is typically handled one of
                      two ways:
                      * SAME REPOSITORY: a separate directory tree in the repository
                      is used to house any "installed" staging artifacts (staged
                      artifacts). Developers will typically use the staging area
                      plus the top-level directory for their own components in their
                      sandbox (and don't extract/checkout anything else unless and
                      until they need to view the source for something outside their
                      owned component)

                      * STAGING REPOSITORY: a separate repository is used to house
                      all staged artifacts. It can therefore accommodate separate
                      sets of versions and tags/labels (which has good points and
                      bad points)

                      Sometimes granularity of access-control, administration,
                      mirroring/synchronizing will determine which of the above
                      two approaches is best. If each component is large enough
                      to already warrant its own separate repository from the
                      others, then a separate staging repository is typically used.

                      Sometimes, for local performance, a staging area might be
                      mirrored or replicated to local sites/storage to cut-down on
                      their network bandwidth for their build-cycle time.

                      So that is the general (non-agile-specific) best practice. How
                      might we apply an "agile" adaptation of it? Well, the
                      "simple" case is when no separate staging area is needed because
                      the whole "one team" can peacefully co-exit in "one repository"
                      and each work at their own "sustainable pace" without unduly
                      impacting the others. So there is little need to think so
                      much about subparts and subteams and instead more easily focus
                      on "the whole"

                      Other times, factors of scale rear their ugly head! They may
                      be issues of system/build scale, organization and organizational
                      process, issues of ownership over computing resources, etc.
                      (or maybe not all the subteams are using "agile" and some of them
                      can't tolerate such high-frequency of changes/deliveries from the
                      agile-teams into their own part of the codebase :-)

                      The "Staging Environment" is a specific technique for separating
                      (sub)team build-dependency interface from implementation for
                      the benefit of the rest of the team(s). The "Staging Environment"
                      is the component-version "mediator" (coordinator really) that
                      houses the common interface and necessary artifacts to satisfy
                      build+test dependencies across subteams.

                      One of the key problems to solve is when and how-often a subteam
                      should do a "signed+sealed" deliver to the staging area. If every
                      commit to the codebase is too frequent for a staging delivery, then
                      something needs to be negotiated between the other subteams. This
                      is where some agile methods try to "scale" by using a team of teams
                      (e.g. a "Scrum of Scrums") to manage the staging frequency and
                      coordination.

                      If it is necessary to "scale-up" my build process & resources to
                      use a Staging Environment, how might I "scale-up" a practice like
                      "Continuous Integration" to approximate "Continuous Staging" into
                      the staging area? This would avoid, or at least minimize the
                      need to tag/label every delivery into the staging area, and hence
                      minimize the need to manage build-version-dependencies between
                      components and the subteams that work on them. Even if it were
                      no longer practical to use a single repository or full system build
                      for every commit across the whole team, it might be feasible to:
                      - Have every commit (or even just once or twice daily) "trigger"
                      a delivery to the staging area.

                      - Another trigger (or perhaps the same one) detects an update
                      to the staging area and does the next-level of build+link+test
                      (automated of course) using the current set of stuff in the
                      staging area.
                      - If it breaks, you take the appropriate course of action and
                      notifications (just as one does for CI at smaller scale)

                      Even in those cases where you might still need to "version" the
                      codebase (and component) for what you delivered to the staging
                      area, the staging area itself can be used to manage the current
                      latest and greatest set of "system buildworthy" components and
                      their versions (both source and binaries).

                      Hope that helps! (sorry about the length. wonder if I should
                      try to publish this somewhere, like that new "fundamentals"
                      section of Agile Times? Any feedback would be appreciated)

                      --
                      Brad Appleton <brad@...> www.bradapp.net
                      Software CM Patterns (www.scmpatterns.com)
                      Effective Teamwork, Practical Integration
                      "And miles to go before I sleep." -- Robert Frost
                    • Paul Campbell
                      ... and ... thinks ... from the ... sealed and ... at ... literature / ... Never keep product/intermediate/generated files under version control. If you ever
                      Message 10 of 15 , Mar 1, 2004
                        --- In extremeprogramming@yahoogroups.com, John Carter
                        <john.carter@t...> wrote:
                        > I have just realized that a major source of conflict between myself
                        and
                        > another developer on the team is the following.
                        >
                        > I think having a one step build process is very important, and he
                        thinks
                        > having versioned libraries are important.
                        >
                        > I believe you should be able to build the entire product directly
                        from the
                        > source code in one step, ensuring no breakage. (Bitrot)
                        >
                        > He believes that each subteam should deliver "tested, closed,
                        sealed and
                        > signed, versioned binary libraries" to the rest of the team.
                        >
                        > I believe that when you check into CVS mainline you are versioning,
                        > signing and sealing that you have compiled, tested and it works.
                        >
                        > I believe the only thing binary libraries gives you these days is a
                        > screwed up dependency tree at "make" time and maybe a second or two
                        at
                        > link time.
                        >
                        > Does anyone have any opinions, pointers to "Best Practice"
                        literature /
                        > web sites to support either view.

                        Never keep product/intermediate/generated files under version
                        control. If you ever think to yourself "maybe we wont be able to
                        reproduce this in future" then you have a fundamental build
                        reproduceablity problem that you must solve.

                        Dont give in to irrational fears (his presumably) about lack of
                        software tool determinism.

                        "if you cant rebuild it - it doesnt exists" - me.

                        Paul C.
                      • John Brewer
                        ... You re both right, depending on the design forces involved. See chapter 14 of Eric Evans Domain-Driven Design for when to use these and other
                        Message 11 of 15 , Mar 1, 2004
                          At 1:56 PM +1300 3/1/04, John Carter wrote:
                          >I think having a one step build process is very important, and he thinks
                          >having versioned libraries are important.

                          You're both right, depending on the design forces involved. See
                          chapter 14 of Eric Evans' "Domain-Driven Design" for when to use
                          these and other integration patterns.
                          --

                          John Brewer
                          Jera Design

                          Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
                        • Jim Standley
                          We have a fantasy, er, plan yet to be executed, that we can have subsytems in our system on different release schedules. The stable core should change as
                          Message 12 of 15 , Mar 1, 2004
                            We have a fantasy, er, plan yet to be executed, that we can have subsytems
                            in our system on different release schedules. The "stable core" should
                            change as infrequently as possible and we can add or update different
                            product lines on business group schedules. One thought is we'll pretend the
                            core is a shrink-wrap product delivered to the rest of the team. They only
                            see pretty solid beta's and production cores. Product line components can
                            be developed and shipped on a particular version of core.

                            Are we completely nuts?

                            At 09:29 PM 3/1/04 +0000, you wrote:

                            >--- In extremeprogramming@yahoogroups.com, John Carter
                            ><john.carter@t...> wrote:
                            > > I have just realized that a major source of conflict between myself and
                            > > another developer on the team is the following.
                            > >
                            > > I think having a one step build process is very important, and he thinks
                            > > having versioned libraries are important.
                            > >
                            > > I believe you should be able to build the entire product directly from the
                            > > source code in one step, ensuring no breakage. (Bitrot)
                            > >
                            > > He believes that each subteam should deliver "tested, closed, sealed and
                            > > signed, versioned binary libraries" to the rest of the team.
                            > >
                            > > I believe that when you check into CVS mainline you are versioning,
                            > > signing and sealing that you have compiled, tested and it works.
                            > >
                            > > I believe the only thing binary libraries gives you these days is a
                            > > screwed up dependency tree at "make" time and maybe a second or two at
                            > > link time.
                            > >
                            > > Does anyone have any opinions, pointers to "Best Practice"
                            >literature /
                            > > web sites to support either view.
                          • Ron Jeffries
                            ... No one is completely nuts. But you re on your way. ;- Why not just stay integrated, make whatever changes are needed by the business, and peel off a
                            Message 13 of 15 , Mar 1, 2004
                              On Monday, March 1, 2004, at 9:45:12 PM, Jim Standley wrote:

                              > We have a fantasy, er, plan yet to be executed, that we can have subsytems
                              > in our system on different release schedules. The "stable core" should
                              > change as infrequently as possible and we can add or update different
                              > product lines on business group schedules. One thought is we'll pretend the
                              > core is a shrink-wrap product delivered to the rest of the team. They only
                              > see pretty solid beta's and production cores. Product line components can
                              > be developed and shipped on a particular version of core.

                              > Are we completely nuts?

                              No one is completely nuts. But you're on your way. ;->

                              Why not just stay integrated, make whatever changes are needed by the
                              business, and peel off a version when someone wants one?

                              Ron Jeffries
                              www.XProgramming.com
                              Wisdom begins when we discover the difference between
                              "That makes no sense" and "I don't understand". --Mary Doria Russell
                            • Jeff Grigg
                              (Very nice post, Brad.) I think a good question to ask at this point is... Are you building one application, with a number of subsystems? Or are you building
                              Message 14 of 15 , Mar 1, 2004
                                (Very nice post, Brad.)


                                I think a good question to ask at this point is...

                                Are you building one application, with a number of subsystems?

                                Or are you building independent libraries, with different release
                                schedules, that are assembled by application teams (with their own
                                release schedules)?


                                If the end result of your work is one coordinated release of a
                                single application, then it would be best to version the source
                                files, not the compiled libraries.

                                On the other hand, if your shop is managing multiple projects that
                                feed each other, with library reuse and independent release
                                schedules, then you should probably version control the library
                                releases. Think of it like this: Your operating system, IDE,
                                compile tools, and third party component libraries are versioned
                                independently of your releases. If some of your internal projects
                                deliver "components" or libraries that are used "as if" they were
                                third party libraries, then separate version control and an
                                independent release schedule may be appropriate.


                                At a previous employer, I ran the "distributed database" team,
                                releasing our library to several application development teams that
                                ran concurrently. While our requirements were driven by the
                                application teams, our release schedules were only loosely
                                coordinated. I think this was an appropriate situation for "signed
                                and sealed" versioned library releases. It worked well for us.


                                P.S. Something to be wary of:
                                Some people will say that libraries with formal release controls
                                improve reuse, ...as they improve "confidence" or something. They
                                do not. The independent release schedules make it difficult to
                                refactor useful reusable code into the libraries. Things that are
                                difficult are, in effect, discouraged.


                                --- Brad Appleton <brad@b...> wrote:
                                > --- John Carter wrote:
                                > > I think having a one step build process is very important,
                                > > and he thinks having versioned libraries are important.
                                >
                                > You are both correct :-)
                                >
                                > > I believe you should be able to build the entire product
                                > > directly from the source code in one step, ensuring no
                                > > breakage. (Bitrot)
                                >
                                > Highly desirable. Not always feasible. It depends upon
                                > relationships between subteams, and their respective "rhythms",
                                > as well as geographical dispersement (and timezone), repository
                                > size and performance, system-build performance and available
                                > network resources, etc.
                                >
                                > > He believes that each subteam should deliver "tested, closed,
                                > > sealed and signed, versioned binary libraries" to the rest of
                                the team.
                                >
                                > [...]
                              • Brad Appleton
                                ... Excellent question! I think I was probably assuming the first of the two cases above. ... Agree. Even when versions are associated with what gets
                                Message 15 of 15 , Mar 1, 2004
                                  On Tue, Mar 02, 2004 at 03:30:58AM -0000, Jeff Grigg wrote:
                                  > I think a good question to ask at this point is...
                                  >
                                  > Are you building one application, with a number of subsystems?
                                  >
                                  > Or are you building independent libraries, with different release
                                  > schedules, that are assembled by application teams (with their own
                                  > release schedules)?

                                  Excellent question! I think I was probably assuming the first of
                                  the two cases above.

                                  > If the end result of your work is one coordinated release of a
                                  > single application, then it would be best to version the source
                                  > files, not the compiled libraries.

                                  Agree. Even when "versions" are associated with what gets
                                  delivered to the staging area, they typically refer to versions
                                  of the source that produced the "staged" deliverables.

                                  > On the other hand, if your shop is managing multiple projects that
                                  > feed each other, with library reuse and independent release
                                  > schedules, then you should probably version control the library
                                  > releases. Think of it like this: Your operating system, IDE,
                                  > compile tools, and third party component libraries are versioned
                                  > independently of your releases. If some of your internal projects
                                  > deliver "components" or libraries that are used "as if" they were
                                  > third party libraries, then separate version control and an
                                  > independent release schedule may be appropriate.

                                  Another excellent point, and one I also agree with. There is
                                  vendor and third-party stuff, and then there is stuff that may
                                  be internal to your organization, but should be regarded as
                                  internally vendor/3rd-party supplied to your particular
                                  product and team. And in those cases versioning the delivered
                                  binaries is recommended.

                                  Some folks use a separate ThirdPartyRepository for such
                                  purposes. One of the reasons is because its supplier and
                                  release schedule is independent of the rest of the application.
                                  Another reason is that if most of the elements are binary
                                  in nature, it is often desirable to have a distinct storage
                                  area with more efficient storage parameters/capacity (and
                                  sometimes the repository can be configured so it is "tuned"
                                  for performance based on knowledge of the kinds of elements
                                  it will predominantly store).

                                  And of course, if you get code delivered from any of those
                                  third parties, you probably want to version it along with the
                                  delivered binaries unless the binaries can be reproduced from
                                  the code you were given (sometimes the source delivered is
                                  insufficient for that).

                                  If you have to modify any of that code from the third-party
                                  for your own custom, value-added purpose, you will probably
                                  want to use the ThirdPartyCodeline pattern (plus, get them
                                  to incorporate your changes, unless the organization deems
                                  them proprietary and is unwilling to submit them back to
                                  the vendor).

                                  > At a previous employer, I ran the "distributed database" team,
                                  > releasing our library to several application development teams that
                                  > ran concurrently. While our requirements were driven by the
                                  > application teams, our release schedules were only loosely
                                  > coordinated. I think this was an appropriate situation for "signed
                                  > and sealed" versioned library releases. It worked well for us.

                                  Definitely! (Good story too!)

                                  > P.S. Something to be wary of:
                                  > Some people will say that libraries with formal release controls
                                  > improve reuse, ...as they improve "confidence" or something. They
                                  > do not. The independent release schedules make it difficult to
                                  > refactor useful reusable code into the libraries. Things that are
                                  > difficult are, in effect, discouraged.

                                  --
                                  Brad Appleton <brad@...> www.bradapp.net
                                  Software CM Patterns (www.scmpatterns.com)
                                  Effective Teamwork, Practical Integration
                                  "And miles to go before I sleep." -- Robert Frost
                                Your message has been successfully submitted and would be delivered to recipients shortly.