I suggest you if you are running live on linux, then developing on linux, could be the same dist or not.. but definitely don't mix OS, because the extensions could fail, etc. one big issue it's the case insensitive in windows.
definitely some version control system such as SVN or GIT you can use Hudson for continuous integration and selenium for automatics QA test over browsers again, try to don't mix OS. saludos gabriel On Sat, May 10, 2008 at 1:44 PM, David Otton <[EMAIL PROTECTED]> wrote: > 2008/5/10 robert mena <[EMAIL PROTECTED]>: > >> I am looking for tips regarding improving the development process. I'll >> explain my current setup and please feel free to comment. >> >> My developers all use windows + eclipse PDT, the workspace is hosted (via >> samba) in a Linux server with Apache/PHP/MySQL. I am in the process of >> adopting Unit testing (PHPUnit2) and debug (Xdebug) so I have concerns about >> how to property use this. >> >> For example, in my current setup I'd have to enable SSH so they could run >> the tests from the command line in the development server, but I am not sure >> if I could remotely use Xdebug. > > Your description (specifically, Samba) suggests that you're not using > source control. If you want to go for TDD (I don't know that you do, > but IMO it's a good direction to move in) I would suggest a > three-server setup - dev, staging and live. > > The dev server(s) are where you work. One per developer. Once you're > happy with your code and your tests, you commit your changes to source > control. This is where it gets clever. You can use pre- and > post-commit hooks to run an automated build process that pushes the > changes to a staging server, automatically runs the unit tests, and > accepts/rejects the commits based on the test results. You can even > lint the code, and reject anything that isn't in the house style. > > With larger projects, where an entire publish-and-test on each commit > becomes impractical, you can just run the build process and unit tests > every n hours, and mail out the results. > > Publishing to the live server is simply a matter of running the build > scripts with a different destination. > > On top of all that, run an issue tracker. /Everything/ goes in the > issue tracker, bugs, features, whatever. When you make a commit, that > commit should be closing an issue in the issue tracker (via commit > hooks again). That way you can track each change that's been made back > to its reason. > > All of this is opinion, of course, there's no Right Way. Just take > what's useful to you. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Los sabios buscan la sabiduría; los necios creen haberla encontrado. Gabriel Sosa -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
