Looking towards a Builder parade and QA

[Colin Clark]

Hi Laurel,

On 2-Dec-09, at 3:35 PM, Laurel A. Williams wrote:
> 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.

Makes sense to me.

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

You can change this yourself.

> http://issues.fluidproject.org/browse/FLUID-3126 - load testing - it  
> may be worth re-running these tests, what do you think?

Yes, I agree. It would be good to run them, and record the stats in  
the wiki.

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

Yesterday we chatted in person about a variety of options we could  
use, but the most promising seem to be either the Web page or a script  
using curl. However, Michelle pointed out that we can probably make  
some tweaks to the build script in order to make the minification step  
a one-time activity. Since it appears to be minification that is most  
CPU intensive, if we can take that step out of a dynamic build, we'll  
be feeling a lot less pressure to comprehensively prime the cache  
before releasing.

You're going to look into that over the next few days, right?

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

I was thinking that the process was simple enough that we could simply  
have a script that lives on the server itself, and checked into SVN in  
our infrastructure space just to ensure it doesn't get lost. Should be  
pretty simple.

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org