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

Re: [XP] Continuous Staging vs Versioned Binary Libraries

Expand Messages
  • 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 1 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.