OT: Method of packaging software for shipment

[Eric Cope]

Alex,
Can you share more about how you operate this testing machine? Does this
machine do automatic daily testing? how do you control it? Is it cron/bash
based? I am working on a web application. Would it be possible to port my
PHP unit tests and Selenium integration tests? I am very interested in your
process. Craig, if you have a process, I am also interested in yours as
well.

Thanks,
Eric

On Fri, Mar 12, 2010 at 8:03 AM, Alex Dean <alex at crackpot.org> wrote:

>
> On Mar 11, 2010, at 8:04 PM, Craig White wrote:
>
>  On Thu, 2010-03-11 at 19:53 -0600, Alex Dean wrote:
>>
>>> On Mar 11, 2010, at 4:08 PM, Craig White wrote:
>>>
>>>  On Thu, 2010-03-11 at 14:47 -0700, Eric Cope wrote:
>>>>
>>>>> It needs to be deployed to Linux and Windows. I can't just tar /dir
>>>>> because I have .svn files I don't want to include as well as test
>>>>> directories. I planned on using a form of tar/zip.
>>>>>
>>>>>  ----
>>>> ignoring that this really should have been on the development mail
>>>> list...
>>>>
>>>> svn help export
>>>>
>>>> I can't imagine a single good reason for using an existing directory
>>>> instead of exporting specific 'tags' from svn and using that for
>>>> packaging except that there really wasn't much understanding and
>>>> planning in svn.
>>>>
>>>
>>> Can't speak for anyone else, but at least in my case I think there was
>>> quite a lot of understanding and planning.
>>>
>>> If the build machine already has a recent working copy of the branch
>>> you want to build, switching to a different branch or getting the last
>>> bug fix with 'svn up' or 'svn switch' is a lot simpler and faster than
>>> getting another full 'svn export'.
>>>
>> ----
>> I tend to think bigger picture and don't resort to simplifications just
>> because they are simpler or faster.
>>
>
> Now really, that's a self-serving assertion if ever I've read one.  I don't
> think I've 'resorted' to anything.  My company has a process that works
> quite well for us, and I shared it.  You're free to disagree, and I welcome
> the discussion, but your choice of words is unhelpful.
>
>
>
>> Reasons that come immediately to my mind to only use an svn export (from
>> a specific 'tag':
>>
>> - stability - you can always see what was packaged by doing a checkout
>> in another directory or on another computer.
>>
>
> You can do that with just a revision number.  You don't need a tag.  If you
> like to use tags, that's of course fine, but all the points you make are
> satisfied just by knowing a branch and revision number.
>
> Don't misunderstand.  The working copies we do builds from have no local
> modifications.  I'm not talking about a developer doing a build on his local
> machine from a working copy which is also used for development.  That's not
> the case.  I'm talking about machines which are dedicated to doing nothing
> but builds, and have working copies of release branches.  But if you just
> built r10198, and some last-minute bugs were found and fixed in r10199, it's
> much faster (and no less accurate or repeatable) to 'svn up' rather than
> doing another 'svn export'.
>
> This is a common pattern for integrating cruisecontrol.rb with subversion.
>  You keep a local working copy on the test machine.  Nobody makes
> modifications to it, it's just a local cache of the software under test.
>  Every time a new revision is detected, CC runs 'svn up' and re-runs all the
> unit tests.  You get results fast, and developers know quickly if something
> they've done has broken a test.
>
>
>
>> There's a reason that management systems and practices are developed and
>> rarely do they focus on simpler or faster.
>>
>
> You speak of 'management systems and practices' as if that were some
> monolithic thing.  This is a vast oversimplification of a complex topic.
>
> Further, emphasizing process simplicity and speed (while maintaining
> repeatability, of course) is quite legitimate.  Complex and unnecessarily
> time-consuming processes are those which encourage mistakes and increase
> expenses.  The whole agile approach to software is about making the process
> simpler and faster, while improving quality and value.
>
> alex
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100312/e4a0b25b/attachment.htm