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

RE: [XP] "Ownership" of build scripts

Expand Messages
  • Aston, Nigel
    Steve We allow development through the IDE with local building. For a controlled build we go through the command line version of the build, and have just moved
    Message 1 of 8 , Apr 1, 2003
    • 0 Attachment
      Steve

      We allow development through the IDE with local building.
      For a controlled build we go through the command line version of the build,
      and have just moved to using Kinooks VisualBuild tool. The procedure for
      build a component and an Application is help in a document, although this
      may be as simple as run the build script.
      Our development is through Visual Studio in C# MC++ and UMC++.

      Nigel

      -----Original Message-----
      From: Steve Berczuk [mailto:berczuk@...]
      Sent: 01 April 2003 14:30
      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/



      DISCLAIMER: This message may contain privileged and confidential
      information. If you think for any reason this message has been addressed in
      error you must not copy or disseminate it and we would ask you to notify us
      immediately by return email to postmaster@.... Internet emails
      are not necessarily secure. Taylor Hobson Holdings plc is the holding
      company for the Taylor Hobson group of companies and is registered in
      England No. 3230332, with its address at 2 New Star Road, Leicester, LE4
      9JQ, England.
    • 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 2 of 8 , Apr 1, 2003
      • 0 Attachment
        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 3 of 8 , Apr 1, 2003
        • 0 Attachment
          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 4 of 8 , Apr 2, 2003
          • 0 Attachment
            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 5 of 8 , Apr 2, 2003
            • 0 Attachment
              > 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 6 of 8 , Apr 2, 2003
              • 0 Attachment
                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 7 of 8 , Apr 2, 2003
                • 0 Attachment
                  > >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 8 of 8 , Apr 3, 2003
                  • 0 Attachment
                    > 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.