in our experience of using shared development the downtime is minimal. and who do you have to explain it to ? downtime on testing and production servers is another issue, but while your in development if someone changes something that breaks what your working on, they will know about it very quickly.
The difference is in the time to integrate changes. Your delaying your integration to (usally) daily we are doing our integration instantly. If your having major integration issues its usually a symptom of project management and a problem with work breakdown structure. maybe this model doesn't work in every development scenario, but it appears to work for us. I wouldn't dismiss it just because its not the standard approach. Pat On Apr 27, 10:18 am, Andrew Scott <[EMAIL PROTECTED]> wrote: > Pat, > > That is very bad and here is why!! > > First of all, it isn't very hard to setup up a staging server, and when that > is done and your happy that the build is stable you can export to the > staging server. > > But the biggest headache for this model is down time, every time I have come > across this development scenario I have quickly changed it there is nothing > worse than another developer with broken code that effects you from doing > your work. And how are you going to explain the downtime due to another > developer breaking a stable build? > > There are no excuses for not having a separate development (developer > workstation) and a separate staging/testing server. > > Andrew Scott > Senior Coldfusion Developer > Aegeon Pty. Ltd.www.aegeon.com.au > Phone: +613 8676 4223 > Mobile: 0404 998 273 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
