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

Re: [XP] "Ownership" of build scripts

Expand Messages
  • wecaputo@thoughtworks.com
    ... Having a release management person involved is sometimes more a fact than a preference, especially in higher-than-project level (i.e. enterprise)
    Message 1 of 8 , Apr 1, 2003
      Steve:
      >For example, if you want to add a new source file to
      >the build, do developers do it, or is there a 'release management'
      >person involved?

      Having a "'release management' person involved" is sometimes more a fact
      than a preference, especially in higher-than-project level (i.e.
      enterprise) situations. Nigel and Andrew have already said what I would
      have said concerning project-level concerns (e.g. IDE's seem to get
      outgrown, and the less maintenance the better), so I am going to focus on
      this larger 'enterprise' question.

      In many ways, XP is a project level methodology, but considering the
      principles and values (and even some of the practices) of XP when designing
      aggregate level operations is still very valuable IMHO. The way I do this
      is to envision myself on an XP project working in that environment. I know
      what I want to be able to do as an XP practitioner, and so when I am
      working with the corporate 'release management' folks I try to help them
      think in terms of enabling practices, and defining expectations instead of
      trying to define and perform the actual procedures themselves which
      requires them to thenpush the entire organization toward this set.

      My theory is simple: Scalability of Agility can be obtained by
      decentralization of control and centralization of expectations and
      adherence to the principles of Agile and XP.

      My current thoughts on enterprise build process (I am working on such a
      project now, its been tough but rewarding) is that if a central group is
      responsible for performing 'official builds' (defined here as building and
      deploying the release version of a system, possibly including management of
      an integration environment with many other applications) they need to
      define a standard *executable* deliverable that each project team should
      provide along with their application. This can be a Make/Ant/NAnt script
      (my preference), a standard IDE file (e.g. VS.NET solution file), some
      custom batch/shell script or some combination or other, but the keys are
      that the script needs to account for *both* the project's needs and the
      enterprise needs, be executable and be maintainable by the app team.The
      central group is thus responsible for saying what needs to be in the script
      for the application to build/deploy nice with everyone else, and enable the
      project team to do what they need to do otherwise.

      So, there are some concrete things that this requires:
      1) Decentralized management of the script itself. Having the central group
      responsible for maintaining the script produces unnecessary overhead (and
      often results in build information being transmitted by nonspecific means
      (e.g. email or Word docs) or overly constraining means (e.g. custom web
      application forms). Specifying that an Ant script must exist with certain
      requirements, but leaving the creation and maintenance to the individual
      teams is much more scalable.

      2) The central group needs to shift from saying what people must do to
      specifying how things should look. This means testing and auditing instead
      of attempting to exhaustively define a list of do's and don'ts for the
      application teams to follow. This is probably the hardest part (apart from
      culture shifts) because the central group will have to find ways to
      automate the testing of builds in order to make this work.

      3) Application teams have to grow up, and the central group has to find
      humility. This is a two part problem. If the organization thinks the
      central group is the braintrust they give them the responsibility -- and
      often the app teams relinquish it (i.e. saying "that's your problem"). In
      addition, the central group usually doesn't really have the monopoly on
      talent, and they certainly don't have all the information. Getting rid of
      such anti-patterns is important to making enterprise Agility work. App
      teams need to reclaim their responsibility, and the central group has to
      recognize that they are there to facilitate communication, not to define
      some magic one-size-fits-all solution.

      4) the central group runs the official builds using the scripts, and
      otherwise restrict access to the integration environment, but they must
      disseminate information about what that environment requires (ideally via
      tests). I also think the whole thing can be automated (Enterprise CI) but I
      haven't gotten that implemented yet -- but whether the triggering event is
      a code change, or a build requrest, the central group can still run the
      build (and restrict what gets into production) they just shouldn't define
      what the build script itself looks like.

      So why is this related to XP? Because:
      1 its facilitated by bringing the customer into the equation (that's the
      best way to figure out what the true requirements of the build process are)
      2.it accomplished by focusing on the same four principles of simplicity,
      courage, feedback and communication.
      3. Its essentially taking CI to the enterprise
      4. There is still an adherence to the various bill of rights
      5. The goal is to enable XP (really any process) at the project level by
      defining requirements that the project must meet instead of procedures the
      project must follow.

      OK, that's long enough. Hopefully I will more concrete facts to report
      after I get this project done!

      Best,
      Bill

      William E. Caputo
      ThoughtWorks, Inc.
      --------
      Cynicism is not realistic and tough. It's unrealistic and kind of cowardly
      because it means you don't have to try. -- Peggy Noonan
    • Tony Milici
      Steve: There are only two of us developers, so we edit the build scripts and check them in. We use 2 IDEs (Visual Studio.Net for Windows and CodeWarrior for
      Message 2 of 8 , Apr 1, 2003
        Steve:

        There are only two of us developers, so we edit the build scripts and
        check them in. We use 2 IDEs (Visual Studio.Net for Windows and
        CodeWarrior for macintos), and the build scripts call the IDEs - devenv
        via the Automation interface from JScript for Windows and CodeWarrior
        from AppleScript on the Macintosh. Both use the same project file that
        we use for development.

        I guess we have collective ownership of build scripts.

        Tony

        -----Original Message-----
        From: Steve Berczuk [mailto:berczuk@...]
        Sent: Tuesday, April 01, 2003 5:30 AM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] "Ownership" of build scripts

        This is probably more of a question for those who are "sort of" doing XP

        rather those actually "doing XP", but maybe not.

        How do you manage changes to integration build scripts (ANT Scripts,
        Makefiles, etc...). For example, if you want to add a new source file to

        the build, do developers do it, or is there a 'release management'
        person involved? What about adding a new library jar (or a new version
        of one)?
        Some possibilities that come to mind are:
        - Developer Edits the build script in checks it in.
        - Developer adds the file to an appropriate folder and it gets
        included in the build automatically.
        - Developer sends a request to someone else who 'manages' the build
        script.
        - (something other, perhaps byzantine, procedure...)

        On a related note: if you use an IDE, how do you reconcile the IDE build

        with the build mechanism on the integration machine? (or are they the
        same? Or is the build script generated from the IDE? or ???)

        I have thoughts about what works well in many cases, but I am curious
        about what people actually do in their teams.

        Thanks,
        Steve

        --
        Steve Berczuk | steve@... | http://www.berczuk.com
        SCM Patterns: Effective Teamwork, Practical Integration
        www.scmpatterns.com



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

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

        ad-free courtesy of objectmentor.com

        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      • Steve Berczuk
        Bill s story describes my experiences about this very well (both in terms of problems and solutions). ... This matches my experience. Often places that have
        Message 3 of 8 , Apr 2, 2003
          Bill's story describes my experiences about this very well (both in
          terms of problems and solutions).

          wecaputo@... wrote:
          > Having a "'release management' person involved" is sometimes more a fact
          > than a preference, especially in higher-than-project level (i.e.
          > enterprise) situations.

          This matches my experience. Often places that have troubles delivering
          good software place an emphasis on control from the 'release
          engineering' end rather than fixing the problems with development.

          For example, the last place I worked (which effectively does not exist
          any more) had a build person who insisted on controlling build scripts
          and adding or removing files from the build was a long process. This led
          to a duplicate build process on the developer side, which never matched
          the release process. (The real problem here was organizational and
          social, but an obvious symptom was the multiple build processes.)

          The other interesting thing was that this company had T shirts made that
          said '<company name> XP' after having had (before my time) a few
          training sessions on XP :) (And yes, having T shirts that say XP does
          not mean that you DO XP :) )

          > My theory is simple: Scalability of Agility can be obtained by
          > decentralization of control and centralization of expectations and
          > adherence to the principles of Agile and XP.

          Yes. Things seem to work best when the people working with the code own
          the process that builds the app. Things work better when the 'release
          engineering' group is integrated with the developer team enough that
          there really isn't a distinction between them in most cases. I generally
          argue (with mixed results) that most of the 'bad things' that release
          people fear can happen when developers own build scripts can be avoided
          by communication. (Both things like simply talking to one another, and
          also by auditing checkins if they are really paranoid...). Of course,
          admitting this often takes 'courage.'

          The best solution is, as Bill said,
          > 3) Application teams have to grow up, and the central group has to find
          > humility.

          So, the reason I asked this question is that I have seem many situations
          where the developers try to be agile and it breaks down because the
          'release engineering group' trys to be rigid. When you look at it from a
          distance this whole thing seems silly, since parts of release
          engineering (build, version control, etc) are just part of developing
          software.
          Anyway, I was curious about people's experiences with this situation,
          and how they addressed it.

          -Steve



          --
          Steve Berczuk | steve@... | http://www.berczuk.com
          SCM Patterns: Effective Teamwork, Practical Integration
          www.scmpatterns.com
        • Phlip
          ... Pick a company s second or third biggest problem (not the first), and dramatically position myself as a champion avenger who will slay it publically. ;-)
          Message 4 of 8 , Apr 2, 2003
            > Anyway, I was curious about people's experiences with this situation,
            > and how they addressed it.
            >
            > -Steve

            Pick a company's second or third biggest problem (not the first), and
            dramatically position myself as a champion avenger who will slay it
            publically. ;-)

            --
            Don Quixote
          • Edmund Schweppe
            ... On my most recent project, I didn t bother. I m sure that there were similarities between the Ant script that actually built stuff and the Eclipse settings
            Message 5 of 8 , Apr 2, 2003
              Steve Berczuk wrote:

              > On a related note: if you use an IDE, how do you reconcile the IDE build
              > with the build mechanism on the integration machine? (or are they the
              > same? Or is the build script generated from the IDE? or ???)

              On my most recent project, I didn't bother. I'm sure that there were
              similarities between the Ant script that actually built stuff and the
              Eclipse settings I used for development, but as long as the Ant tasks
              ran properly I didn't care. It wasn't quite one-button testing, but it
              was plenty quick enough for my needs.

              (Of course, the VB portion of the project had its own settings; but all
              Ant had to do was invoke vb6exe /makedll and let VB do its own
              worrying.)

              --
              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.
            • Phlip
              ... Farbeit from me to interrupt an MS flame, but my Makefiles routinely say this: msdev cpptests test.dsp /MAKE test - Win32 Debug The point is that the
              Message 6 of 8 , Apr 2, 2003
                > >On a related note: if you use an IDE, how do you reconcile the IDE build
                > >with the build mechanism on the integration machine? (or are they the
                > >same? Or is the build script generated from the IDE? or ???)
                >
                > Not all IDEs are Microsoft Visual Studio. I have two principal IDEs,
                > Apple Project Builder and Metrowerks CodeWarrior. (Which one is used
                > depends on the needs of the project.)

                Farbeit from me to interrupt an MS flame, but my Makefiles routinely say
                this:

                msdev cpptests\test.dsp /MAKE "test - Win32 Debug"

                The point is that the "makefile" you get while editing (in this case the DSP
                file) is exactly the same as you get when building in batches.

                I have stretched DSP files far beyond their defaults, typically by my many
                years experience knowing how to edit them by hand without wrecking them for
                the Settings dialog.

                --
                Phlip
              • Pierre Boudreau
                ... I had several of these in my Ant files. I recently created a new Ant task (others have probably done this before, but I could not find any) for MSDev (and
                Message 7 of 8 , Apr 3, 2003
                  > Farbeit from me to interrupt an MS flame, but my Makefiles routinely say
                  > this:
                  >
                  > msdev cpptests\test.dsp /MAKE "test - Win32 Debug"

                  I had several of these in my Ant files. I recently created a new Ant task (others have probably done this before, but I could not
                  find any) for MSDev (and devenv for VS.NET). I have this running with Cruise Control to show build errors on the continous
                  integration web site.
                Your message has been successfully submitted and would be delivered to recipients shortly.