Looking towards a Builder parade and QA
Laurel A. Williams
laurel.williams at utoronto.ca
Wed Dec 2 20:35:41 UTC 2009
Thanks for the kudos Colin. That was my first attempt at ant scripts
from scratch. It was fun.
Colin Clark wrote:
> Hey all,
>
> I just had a chance to test drive the shiny new deployment scripts
> Laurel created for the Builder. They work great! I'm super impressed
> with how much simpler the deploy process has become.
>
> With the new deploy scripts in place, and a number of our prominent
> issues resolved, I think we're ready to look towards doing a mini bug
> parade and QA cycle specifically for Builder. Next steps:
>
> 1. Laurel, can you go through the list of JIRAs filed against Builder,
> ensure they're up to date, and suggest which ones of them need to get
> done before we release? I filed a few issues while doing code review,
> so you'll want to check those out too. Some for now, some for later, I
> expect. Justin and I can help you with prioritization if you need it.
>
I would appreciate some feedback on the following priorities:
The only blocker currently is:
http://issues.fluidproject.org/browse/FLUID-3359 - which I know Jacob is
working on now.
I would like to promote:
http://issues.fluidproject.org/browse/FLUID-3162 to a blocker. I would
like to chat with you about approaches to this.
Quick fixes:
http://issues.fluidproject.org/browse/FLUID-3395 - user friendly error
messages
http://issues.fluidproject.org/browse/FLUID-3396 - rename files to
InfusionBuilder. I notice that the project in the SVN incubator
directory is also called CustomBuild. Can I change that or does someone
else have to do that?
http://issues.fluidproject.org/browse/FLUID-3126 - load testing - it may
be worth re-running these tests, what do you think?
Also not sure if you want to add either of the two (potentially three)
Jiras listed below too.
> 2. Jacob, can you fill us in on your plans are for finishing up the
> new Builder look and feel? What's left to do?
>
> 3. Justin, how is the QA test plan for Builder looking? Is it
> comprehensive and good?
>
> Lastly, a couple of quick questions for you, Laurel, about places we
> might further streamline the deploy process:
>
> * Any thoughts on ways we might automate the cache priming process? A
> script using curl? A little web page that makes Ajax requests to the
> Builder?
http://issues.fluidproject.org/browse/FLUID-3399
The first option was what I had in mind. Maybe we can discuss the second
option more. Another thought might be to add the cache priming tasks to
the ant deploy script.
>
> * The only snag I hit with the process was when I accidently typed the
> DB password incorrectly. My first instinct was to just run the script
> again, but since the deploy process is destructive, it didn't work
> until I checked it all out again. Should we perhaps copy instead of
> move, or is there a reason to do it this way?
No, there is no reason to do a move instead of a copy. I can change that.
http://issues.fluidproject.org/browse/FLUID-3400
>
> * I'm thinking we might be able to whittle the deploy steps down to
> one if we created a little shell script that runs each of the first
> six steps outlined in your documentation, prompting the user to supply
> the DB username and password. What do you think?
Doable, but some questions come to mind. Where do we keep the script and
does the "deployer" need to check it out and chmod it to run it ? That
cuts down on the number steps but not very much. Also would we require
users to ssh into the server before running the script? I can see some
issues running such a script from a windows environment (ssh, cygwin,
etc). I thought about adding some of these steps to the ant script but
ended up not doing it A) because if the script is stored in the SVN then
the export step 2 has to be executed anyway but for fewer files and B)
because you can't delete the directory containing the ant script as part
of the ant script <grin>. I know realistically there are ways around
both those issues, but never really convinced myself of the benefit.
>
> Let's get this one out the door!
Yes please.
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurel_williams.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091202/6816d8ab/attachment.vcf>
More information about the fluid-work
mailing list