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

"Ownership" of build scripts

Expand Messages
  • Steve Berczuk
    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
    Message 1 of 17 , Apr 1, 2003
    • 0 Attachment
      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
    • Andrew McDonagh
      ... This is how our C++ makefiles and Java Ant scripts work. The thought of having to add a file (whether manually or automatically to the build script is
      Message 2 of 17 , Apr 1, 2003
      • 0 Attachment
        > -----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.

        This is how our C++ makefiles and Java Ant scripts work. The thought of
        having to add a file (whether manually or automatically to the build script
        is just wrong IMHO.

        Our makefiles recurse down the directory structures compiling anything in
        there that is of the right file type.



        > - 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 ???)

        In the early days the IDE build system could cope with building our system,
        but as time went along, additional targets were required (IDL compilation,
        java source generation, etc) that the IDE couldn't do. So we hooked our
        (already developed) build script into the IDE.


        >
        > 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/
        >
        >
        >
        >
      • Bill de hÓra
        ... Going through this one at work. Most Java IDEs will let you use Ant these days (or you can just alt-tab onto a console). The main thing if they are
        Message 3 of 17 , Apr 1, 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 ???)

          Going through this one at work. Most Java IDEs will let you use Ant
          these days (or you can just alt-tab onto a console). The main thing
          if they are different is to make absolutely sure the IDE and
          Ant/make are picking the same jar files for dependency management,
          ie if you don't own the classpath in a 'enterprise' setup you're
          stuffed sooner or later.

          Somewhat unrelated factoid: you can fire up jboss and tomcat with an
          Ant script instead of their shell scripts; very handy for managing
          classpath issues.


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

          The awkard one, for Ant scripts, is propagating a task change or new
          task across multiple projects (Ant invites duplication). Because
          of this, lately I've been thinking about having the build scripts in
          their own CVS module, setting .cvspass in each to ignore build.xml
          and exporting the build onto the projects (otherwise you screw up
          the project's CVS directory). Local configurations beyond a
          .properties file can be managed through an external entity hook.

          I'm far from convinced that build scripts need to be per-project, or
          that there is much value in having a thousand project layouts bloom.
          Having worked with a single build system for all projects a year or
          so ago (a gnumake system for Java and C++), and moved to per project
          builds in Java. all I can say is per project setups aren't of any
          obvious value; in fact they're a massive timewaster.

          Once you tie down the project layout, one uber-buildfile will do the
          lot. I've got this going in Ant for my own code; I'd like to see
          work adopt it for future projects. If anyone's interested in seeing
          this I could throw a web page together real soon now and upload the
          files.

          Anyway I think if you have the Ant scripts in their own project, and
          a single layout for projects, it makes you think differently about
          these matters. To my mind a standard layout is just a coding convention.

          Bill de hÓra
        • csmajohnson
          ... build ... the ... curious ... We used to have a lot of duplication until we re-factored our scripts into XML and XSL and then use the task in Ant
          Message 4 of 17 , Apr 1, 2003
          • 0 Attachment
            > -----Original Message-----
            > From: Bill de hÓra [mailto:dehora@...]
            > Sent: Tuesday, April 01, 2003 6:41 PM
            > To: extremeprogramming@yahoogroups.com
            > Subject: Re: [XP] "Ownership" of build scripts
            >
            > 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 ???)
            >
            > Going through this one at work. Most Java IDEs will let you use Ant
            > these days (or you can just alt-tab onto a console). The main thing
            > if they are different is to make absolutely sure the IDE and
            > Ant/make are picking the same jar files for dependency management,
            > ie if you don't own the classpath in a 'enterprise' setup you're
            > stuffed sooner or later.
            >
            > Somewhat unrelated factoid: you can fire up jboss and tomcat with an
            > Ant script instead of their shell scripts; very handy for managing
            > classpath issues.
            >
            >
            > > I have thoughts about what works well in many cases, but I am
            curious
            > > about what people actually do in their teams.
            >
            > The awkard one, for Ant scripts, is propagating a task change or new
            > task across multiple projects (Ant invites duplication).

            We used to have a lot of duplication until we re-factored our scripts
            into XML and XSL and then use the <style> task in Ant to generate the
            subordinate Ant files at the beginning of the build. It helped a lot on
            cutting down on duplication of things we maintained such as paths,
            output folders etc.

            --Mike
          • csmajohnson
            ... build ... I am the keeper of the build. If someone checks in something that hoses the build (doesn t compile, dependency not found etc), they become the
            Message 5 of 17 , Apr 1, 2003
            • 0 Attachment
              > 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.

              I am the keeper of the build. If someone checks in something that hoses
              the build (doesn't compile, dependency not found etc), they become the
              keeper of the build.

              > - (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 ???)

              We wrote a tool that builds the initial build script from the IDE config
              files into ANT, but once built we lovingly manage it by hand. We could
              probably automate this, but I feel (maybe out of fear) that by updating
              by hand I have a pulse on the dependencies being added to the product
              (why is DX9 being linked into our openGL version?). By historical
              tradition we gave too much freedom over the configuration of developer
              workstations and how they were set up for compiling/building. With this
              setup we got varying degrees of "quality" in the old days depending on
              who did the build. we tried forcing developers to the
              oneTrueConfiguration, but that failed miserably in lost productivity and
              worse morale. In the end we got a build machine and everyone smiled
              because it was good...

              I wonder how long or involved is the build pipeline for other projects
              out there...

              --mike
            • Tom Copeland
              ... I ve set up a similar gizmo for ~20 hourly builds using a parameterized Ant script: https://cvs.ultralog.net/ As you say, if you can enforce a standard
              Message 6 of 17 , Apr 2, 2003
              • 0 Attachment
                > Once you tie down the project layout, one uber-buildfile will do the
                > lot. I've got this going in Ant for my own code; I'd like to see
                > work adopt it for future projects. If anyone's interested in seeing
                > this I could throw a web page together real soon now and upload the
                > files.

                I've set up a similar gizmo for ~20 hourly builds using a parameterized
                Ant script:

                https://cvs.ultralog.net/

                As you say, if you can enforce a standard directory structure you can
                get a lot of stuff done with one Ant script...

                Yours,

                Tom
              • Chris Hanson
                ... Developers. ... Developers. ... Not all IDEs are Microsoft Visual Studio. I have two principal IDEs, Apple Project Builder and Metrowerks CodeWarrior.
                Message 7 of 17 , Apr 2, 2003
                • 0 Attachment
                  At 8:29 AM -0500 4/1/03, Steve Berczuk wrote:
                  >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?

                  Developers.

                  >What about adding a new library jar (or a new version
                  >of one)?

                  Developers.

                  >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.)

                  Project Builder includes a "pbxbuild" command that can be used
                  trivially from shell scripts or the Mac OS X (Unix) command line to
                  build a target in a project file.

                  Metrowerks CodeWarrior is trivially scriptable via AppleScript to
                  open a project and build a specific target within it, and is *very*
                  fast at it. (It really screams.) And AppleScripts can be run via
                  both the Mac OS X command line and shell scripts using
                  /usr/bin/osascript.

                  -- Chris

                  --
                  Chris Hanson, bDistributed.com, Inc. | Email: cmh@...
                  Custom Application Development | Phone: +1-847-372-3955
                  http://bdistributed.com/ | Fax: +1-847-589-3738
                  http://bdistributed.com/Articles/ | Personal Email: cmh@...
                • Martin Fowler
                  I suggest making sure that there is one build script that is the mainline build script. This is the one that s used for the Integration Build. As a result it s
                  Message 8 of 17 , Apr 3, 2003
                  • 0 Attachment
                    I suggest making sure that there is one build script that is the
                    mainline build script. This is the one that's used for the Integration
                    Build. As a result it's one that you'll want to be able to run from a
                    command line. Typically Ant on Java, Nant perhaps on .NET (not sure what
                    we've actually used). Good rules / tasks should make it so that you
                    don't have to edit it often. Our bigger projects have actually generated
                    ant scripts from another textual form. Build scripts are under the
                    control of the development team - for XP it falls under CCO.

                    If people use IDE's they look after them individually. When they do a
                    private build before committing they should use the mainline build
                    script. If an IDE is very common (as IntellJ is around our neck of the
                    woods) then those files can be checked in to for everyone's convenience.
                    (Thankfully much easier now tools vendors like IntelliJ use text based
                    XML for their config files now.)

                    Martin

                    Steve Berczuk wrote:
                    > 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
                    >

                    --
                    Martin Fowler
                    http://martinfowler.com
                  • Bill de hÓra
                    ... +1 ... Sure, but then again IntelliJ integrates Ant; as does Eclipse, JpadPro (and probably TogetherJ by now). Is there any reason to not use the mainline
                    Message 9 of 17 , Apr 3, 2003
                    • 0 Attachment
                      Martin Fowler wrote:

                      > If people use IDE's they look after them individually.

                      +1

                      > When they do a
                      > private build before committing they should use the mainline build
                      > script. If an IDE is very common (as IntellJ is around our neck of the
                      > woods) then those files can be checked in to for everyone's convenience.
                      > (Thankfully much easier now tools vendors like IntelliJ use text based
                      > XML for their config files now.

                      Sure, but then again IntelliJ integrates Ant; as does Eclipse,
                      JpadPro (and probably TogetherJ by now). Is there any reason to not
                      use the mainline build script all the time? this way you just can't
                      drift away from the mainline. At worst, each developer can hook
                      their own private 'must-have' tasks into the mainline script using
                      an entity declaration.

                      Bill de hÓra
                    • geoff_sobering
                      ... Can you give an example of a private must-have task that doesn t belong in the full build? I can t imagine what magic I would want to do in my (and
                      Message 10 of 17 , Apr 4, 2003
                      • 0 Attachment
                        --- In extremeprogramming@yahoogroups.com, Bill de hÓra <dehora@e...>
                        wrote:
                        > Sure, but then again IntelliJ integrates Ant; as does Eclipse,
                        > JpadPro (and probably TogetherJ by now). Is there any reason to not
                        > use the mainline build script all the time? this way you just can't
                        > drift away from the mainline.

                        > At worst, each developer can hook
                        > their own private 'must-have' tasks into the mainline script using
                        > an entity declaration.

                        Can you give an example of a "private 'must-have' task" that doesn't
                        belong in the full build? I can't imagine what magic I would want to
                        do in my (and only my) development evironment during a build.

                        In any case, how do I configure "my" settings when I'm working at a
                        different development workstation with a different pair (and
                        his/her "private 'must-have' tasks") every couple of hours?

                        Cheers,

                        Geoff S.
                      • Bill de hÓra
                        ... Jsp only deploy. Touch web.xml to have the container reload the application. I don t need those in a full build, but they re damn handy when I m working
                        Message 11 of 17 , Apr 4, 2003
                        • 0 Attachment
                          geoff_sobering wrote:

                          >
                          > Can you give an example of a "private 'must-have' task" that doesn't
                          > belong in the full build? I can't imagine what magic I would want to
                          > do in my (and only my) development evironment during a build.

                          Jsp only deploy. Touch web.xml to have the container reload the
                          application. I don't need those in a full build, but they're damn
                          handy when I'm working with Jsps.

                          Really I'm thinking about situations where you have developers who
                          are emotional about their programming environments. But this is is
                          the stuff of angle brackets. Personally I think having a standard
                          system configuration on a project is immensely valuable, IDEs be damned.

                          > In any case, how do I configure "my" settings when I'm working at a
                          > different development workstation with a different pair (and
                          > his/her "private 'must-have' tasks") every couple of hours?

                          For XP and other sane enviroments, you don't.

                          Otherwise use a system entity to pull in yours or her tasks.

                          This item was done to death two years ago here; back then it was
                          about code layouts, keyboard layouts, screen sizes and whatever else
                          it is people think are important to them. I condsider arguing about
                          build setups progress, of a sort.

                          Bill de hÓra
                        • geoff_sobering
                          ... else ... I have to admit I was confused by the thread for that very reason. I thought in the context of XP/Agile this was pretty much decided. Hence, my
                          Message 12 of 17 , Apr 5, 2003
                          • 0 Attachment
                            --- Bill de hÓra <dehora@e...> wrote:
                            > geoff_sobering wrote:
                            >
                            > This item was done to death two years ago here; back then it was
                            > about code layouts, keyboard layouts, screen sizes and whatever
                            else
                            > it is people think are important to them. I condsider arguing about
                            > build setups progress, of a sort.

                            I have to admit I was confused by the thread for that very reason.
                            I thought in the context of XP/Agile this was pretty much decided.
                            Hence, my question; I was wondering if I'd missed something.


                            > > Can you give an example of a "private 'must-have' task" that
                            doesn't
                            > > belong in the full build? I can't imagine what magic I would
                            want to
                            > > do in my (and only my) development evironment during a build.
                            >
                            > Jsp only deploy. Touch web.xml to have the container reload the
                            > application. I don't need those in a full build, but they're damn
                            > handy when I'm working with Jsps.

                            Agreed. On my current project we've had various automation scripts
                            for supporting development tasks. Keeping those separate from the
                            "one true build" is absolutely necessary. Having them in the same
                            configuration management system as the rest of the project is probably
                            a good thing so that they can be shared among the team and don't
                            become "private".


                            > Really I'm thinking about situations where you have developers who
                            > are emotional about their programming environments. But this is is
                            > the stuff of angle brackets. Personally I think having a standard
                            > system configuration on a project is immensely valuable, IDEs be
                            damned.
                            >
                            > > In any case, how do I configure "my" settings when I'm working at
                            a
                            > > different development workstation with a different pair (and
                            > > his/her "private 'must-have' tasks") every couple of hours?
                            >
                            > For XP and other sane enviroments, you don't.

                            I wasn't suggesting that having/allowing/encouraging personalized
                            development environments is a good thing. Quite the opposite. I
                            believe that development environments should be as standardized as
                            possible on the shared development workstations.

                            This is one of the major reasons (IMO) to separate personal
                            workstations from the project's workstations. I strongly believe that
                            people need to have a place (machine) that is their "personal
                            computer" with their own personal mix of tools. One of the advantages
                            of this separation of team from personal workstations is that some
                            tool that one developer discovers or favors may become a standard tool
                            for the team based on demonstration of it's benefits on someone's PC.

                            Cheers,

                            Geoff S.
                          • Charlie Poole
                            Geoff, ... When possible I like to have a core build script which can be (1) used as-is by developers (2) called from individual scripts that developers write
                            Message 13 of 17 , Apr 6, 2003
                            • 0 Attachment
                              Geoff,

                              > Agreed. On my current project we've had various automation scripts
                              > for supporting development tasks. Keeping those separate from the
                              > "one true build" is absolutely necessary. Having them in the same
                              > configuration management system as the rest of the project is probably
                              > a good thing so that they can be shared among the team and don't
                              > become "private".

                              When possible I like to have a core build script which can
                              be (1) used as-is by developers (2) called from individual scripts
                              that developers write for themselves (3) called from the "real" build
                              script. The core script tends to shed any unnecessary functions when
                              used this way as they get refactored into one of the calling scripts
                              or - if the function is needed in more than one place - into a separate
                              script that can be used where needed. Developers will usually do most
                              compiling in the IDE but will run the script before trying to integrate.

                              Charlie Poole
                              cpoole@...
                              www.pooleconsulting.com
                              www.charliepoole.org
                            • geoff_sobering
                              ... scripts ... probably ... build ... when ... separate ... most ... integrate. Absolutely. The core-build-script is factored into a collection of
                              Message 14 of 17 , Apr 7, 2003
                              • 0 Attachment
                                --- In extremeprogramming@yahoogroups.com, "Charlie Poole"
                                <cpoole@p...> wrote:
                                > Geoff,
                                >
                                > > Agreed. On my current project we've had various automation
                                scripts
                                > > for supporting development tasks. Keeping those separate from the
                                > > "one true build" is absolutely necessary. Having them in the same
                                > > configuration management system as the rest of the project is
                                probably
                                > > a good thing so that they can be shared among the team and don't
                                > > become "private".
                                >
                                > When possible I like to have a core build script which can
                                > be (1) used as-is by developers (2) called from individual scripts
                                > that developers write for themselves (3) called from the "real"
                                build
                                > script. The core script tends to shed any unnecessary functions
                                when
                                > used this way as they get refactored into one of the calling scripts
                                > or - if the function is needed in more than one place - into a
                                separate
                                > script that can be used where needed. Developers will usually do
                                most
                                > compiling in the IDE but will run the script before trying to
                                integrate.

                                Absolutely. The core-build-script is factored into a collection
                                of building-blocks, one assembly which is the "production-build".
                                Ant is particularly good for this because any developer can add
                                a "personal" (better stated, a "specific") task to combine some
                                series of build tasks for a particular development purpose
                                (although it does tend to make 'build.xml' a bit large...)

                                Cheers,

                                Geoff S.
                              • Brad Appleton
                                ... Am I reading some build-script (re)factoring patterns? Those could be an interesting and useful bunch - particularly if part of the factoring is to
                                Message 15 of 17 , Apr 8, 2003
                                • 0 Attachment
                                  On Tue, Apr 08, 2003 at 05:07:31AM -0000, geoff_sobering wrote:
                                  > Absolutely. The core-build-script is factored into a collection
                                  > of building-blocks, one assembly which is the "production-build".
                                  > Ant is particularly good for this because any developer can add
                                  > a "personal" (better stated, a "specific") task to combine some
                                  > series of build tasks for a particular development purpose
                                  > (although it does tend to make 'build.xml' a bit large...)

                                  Am I reading some build-script (re)factoring patterns? Those could be an interesting and useful bunch - particularly if part of the factoring is to meet/balance the needs of different roles (development build, integration build, final production build, etc.)
                                  --
                                  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
                                • Phlip
                                  ... interesting and useful bunch - particularly if part of the factoring is to meet/balance the needs of different roles (development build, integration build,
                                  Message 16 of 17 , Apr 8, 2003
                                  • 0 Attachment
                                    Brad Appleton sez:

                                    > Am I reading some build-script (re)factoring patterns? Those could be an
                                    interesting and useful bunch - particularly if part of the factoring is to
                                    meet/balance the needs of different roles (development build, integration
                                    build, final production build, etc.)

                                    This is a ... ripe ... topic for a little documentation.

                                    Here's my post to an otherwise quiet newsgroup:

                                    ----8<-------------------------
                                    >Newsgroupies:
                                    >
                                    >I have a top-level Makefile that calls MSDEV to build several
                                    >"flavors" of a project:
                                    >
                                    >FLAVORSmake= cherry.make chocolate.make albatross.make
                                    >FLAVORStest= cherry.test chocolate.test albatross.test
                                    >
                                    >$(FLAVORSmake) :
                                    > msdev iceCream.dsp /MAKE "iceCream - Win32 $*"
                                    >
                                    >$(FLAVORStest) : $*.make
                                    > $*_Debug/iceCream.exe --test
                                    >
                                    ..

                                    >How do I let programmers add flavors by changing only >one< line?

                                    Hi Phillip,

                                    Try this:

                                    FLAVORSmake= cherry.make chocolate.make albatross.make

                                    FLAVORStest= $(FLAVORSmake:make=test)


                                    This is explained in help for "macro substitution".

                                    --
                                    smortaz, Visual C++ Team
                                    ----8<-------------------------

                                    He shoots he scores! An RTFM from the very top!

                                    --
                                    Phlip
                                  • Steve Berczuk
                                    ... Perhaps... At the very least, I think this discussion makes the point that the build scripts are part of the code for the project and can be refactored,
                                    Message 17 of 17 , Apr 8, 2003
                                    • 0 Attachment
                                      Brad Appleton wrote:
                                      > Am I reading some build-script (re)factoring patterns? Those could be
                                      > an interesting and useful bunch - particularly if part of the
                                      > factoring is to meet/balance the needs of different roles
                                      > (development build, integration build, final production build, etc.)

                                      Perhaps...
                                      At the very least, I think this discussion makes the point that the
                                      build scripts are part of the 'code' for the project and can be
                                      refactored, etc just like code.... (Perhaps we could call them
                                      'metadata' of a sort, but that might just start an old argument ;) )

                                      True Story: One place I worked the release team was very reluctant to
                                      make changes that "development" needed because it would be hard to
                                      change the large and fragile (ANT) build scripts. When I looked at the
                                      scripts I found that they were full of cut-paste-modify bits rather than
                                      attempting to use parameters or anything else like that. Turns out
                                      that it was easy enough to "refactor" the scripts, but we had spent more
                                      time arguing about whether or not we should do it than it actually took
                                      to do it ;)

                                      (the fact that I am talking about 'release' and 'development' was part
                                      of the problem... )

                                      Anyway, don't let this happen to your team...;) think of the build
                                      scripts as part of the project and understand them well enough that they
                                      can support the way that you need to work... (I know that it /sounds/
                                      obvious, but ...)

                                      -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.