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

single threaded releases

Expand Messages
  • Ken Boucher
    As people have been talking about releasing with an integration token there seems to be some confusion. About releasing code with smalltalk: Under envy
    Message 1 of 2 , Oct 1, 2004
    • 0 Attachment
      As people have been talking about releasing with an "integration
      token" there seems to be some confusion.

      About releasing code with smalltalk:
      Under envy versioning takes place:
      1) At the application level.
      2) Again at the class level.
      3) Each method is also saved in the repository every time it's saved
      so pulling up old versions is very easy, even if these versions were
      never released.
      4) Applications, Classes, and methods can easily be compared to
      different versions making integration very easy if the volume of
      changes isn't too large. (Such as 3 days worth of work.)
      5) It's normal to add functions to the IDE in smalltalk. We have a
      small collection of functions in a drop down that make most of the
      things we do for releasing code "push button simple".

      About single threading releases:
      1) Common methods include a "release token" or a "release box".
      http://www.fairlygoodpractices.com/release.htm has some notes about
      it.
      2) I keep hearing things like "interrupts flow" and "wait for the
      box" and I'm not experiencing this problem that everyone else is
      talking about. I remember experiencing that problem in a multi-
      threaded release enviroment when collisions became too frequent.
      Either I've grown too used to it to see it happening, or it's not
      happening.
      3) What's funny to me about the "interrupts" part is that I seem to
      recall some people saying how "forcing idle time" on the team at odd
      moments was a good thing because it forced slack on us but
      now "interupting flow" seems to be a bad thing. I'm not sure what the
      difference is.
      4) The way we do it is just put our name on the release box and go
      load it up and kick it off when it's free. If we're going to keep
      working in the classes or we hit a point where we want to version a
      class we can do it immediately and then release that version on the
      box later (or have someone else do it for you). Since the box is
      single threaded, any merges that need to be done aren't complicated
      by someone else releasing code in the middle of your merge.
      5) Note that because of how smalltalk with envy works, if I version a
      class and haven't released it yet, you can choose to load it in
      anyway. (I'm assuming you'll know about it for a number of reasons,
      most of which have to do with communication and the fact that it's
      labeled.) This may be why the bit about it being "impossible do
      anything while the build is broken" didn't make a lot of sense to me.
      As long as the suite of unit tests revolving around this bit of code
      isn't broke we don't seem to worry about things.
    • Steve Berczuk
      ... It s all related, which is why Brad and I wrote the SCM Patterns as a Pattern Language as opposed to a list of best practices. If you have good testing
      Message 2 of 2 , Oct 2, 2004
      • 0 Attachment
        On Fri, 01 Oct 2004 23:42:29 -0000, Ken Boucher <yahoo@...> wrote:
        >
        > As people have been talking about releasing with an "integration
        > token" there seems to be some confusion.
        ...
        > This may be why the bit about it being "impossible do
        > anything while the build is broken" didn't make a lot of sense to me.
        > As long as the suite of unit tests revolving around this bit of code
        > isn't broke we don't seem to worry about things.

        It's all related, which is why Brad and I wrote the SCM Patterns as a
        "Pattern Language" as opposed to a list of best practices.

        If you have good testing practices and if you do private system builds
        before checkin, (among other things) you are less likely to have
        problems with parallel integration efforts, and if there is a
        conflict, then you will identify it in the integration build step.

        I'll be a minimalist here and say that the important thing is that
        code gets checked in and integrated frequently. If Integration Tokens
        and the resulting serialization leads to people doing fewer checkins,
        then I'd reconsider. If you are checking in code often (3, 4, 5, 10
        times a day?) while using the integration token approach, then ir's OK
        to use the integration token approach (but it may not be necessary).
        This is analogous to the "locking" debate... should you lock files
        while editing them? Often locking is band-aid to cover for other
        problems: lack of communication, an architecture that is too tightly
        coupled, people who don't check in code or update often enough. I'm an
        not sure that I can make that strong of a statement about serializing
        checkins but I'd consider it ;) ( btw, I'm talking about manual
        serialization. If you have a tool that supports a process where
        checkin 1 is built and tested before checkin 2 is done, etc, then that
        is different since it would not interrupt development work)

        Steve


        --
        Steve Berczuk | steve@... | http://www.berczuk.com
        SCM Patterns: Effective Teamwork, Practical Integration
        www.scmpatterns.com
      Your message has been successfully submitted and would be delivered to recipients shortly.