Hi,
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.

Thanks.

2008/5/10 robert mena <robert.mena@gmail.com>:

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

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 <david@otton.org> wrote:
> 2008/5/10 robert mena <robert.mena@gmail.com>:
>
>> 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

Hi,
Thanks for all answers. Please let me add that I do use CVS (migrating to
SVN) and the reason to use samba is that doing this allows the developer
machine (windows) to access the shares hosted in a linux server so when
he/she tests it will be run in the 'same' environment that the staging and
production servers and because in order to assure browser compatibility they
have to test from firefox/IE.

So, in order to allow phpunit to be ran, have the firefox/IE support and use
xdebug I have two basic options:
a) stay with windows, install XAMPP (or any other all-in-one). And live
with the fact that some things will have to be taken care of (such as
PATH differences between unix/windows)
b) switch to linux with the development stack, enable a windows server to be
connected from rdesktop so they can test the IE

In both cases I'll have extra work in order to maintain the developer's
machine somewhat synchronized with the production server.

Am I missing a third/fourth (better) etc option?

thanks.

On Sat, May 10, 2008 at 8:44 PM, Gabriel Sosa <sosagabriel@gmail.com> wrote:

> 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 <david@otton.org> wrote:
> > 2008/5/10 robert mena <robert.mena@gmail.com>:
> >
> >> 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
>

> Thanks for all answers. Please let me add that I do use CVS (migrating to
> SVN) and the reason to use samba is that doing this allows the developer
> machine (windows) to access the shares hosted in a linux server so when
> he/she tests it will be run in the 'same' environment that the staging and
> production servers and because in order to assure browser compatibility they
> have to test from firefox/IE.

If you only have a small number of developers, you could do away with
Samba completely and use SftpDrive, which allows you to map a drive to
an SFTP account (essentially the same as an SSH account).

http://www.phpguru.org/sftpdrive

--
Richard Heyes

+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+

On May 19, 2008, at 8:45 AM, Zoltán Németh wrote:

>> Hi,
>> Thanks for all answers. Please let me add that I do use CVS
>> (migrating
>> to
>> SVN) and the reason to use samba is that doing this allows the
>> developer
>> machine (windows) to access the shares hosted in a linux server so
>> when
>> he/she tests it will be run in the 'same' environment that the
>> staging and
>> production servers and because in order to assure browser
>> compatibility
>> they
>> have to test from firefox/IE.
>>
>> So, in order to allow phpunit to be ran, have the firefox/IE
>> support and
>> use
>> xdebug I have two basic options:
>> a) stay with windows, install XAMPP (or any other all-in-one). And
>> live
>> with the fact that some things will have to be taken care of (such as
>> PATH differences between unix/windows)
>> b) switch to linux with the development stack, enable a windows
>> server to
>> be
>> connected from rdesktop so they can test the IE
>>
>> In both cases I'll have extra work in order to maintain the
>> developer's
>> machine somewhat synchronized with the production server.
>>
>> Am I missing a third/fourth (better) etc option?
>
> why not switch everything to linux and run IE in wine or vmware on the
> developer's machine? that way you don't have to maintain windows
> machines
> at all

Or depending on your budget, Switch the developers to Macintosh
computers, install windows via parallels, and then you can test in Mac/
Unix/Windows all from 1 computer

--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruim@raoset.com

> Hi,
> Thanks for all answers. Please let me add that I do use CVS (migrating
> to
> SVN) and the reason to use samba is that doing this allows the developer
> machine (windows) to access the shares hosted in a linux server so when
> he/she tests it will be run in the 'same' environment that the staging and
> production servers and because in order to assure browser compatibility
> they
> have to test from firefox/IE.
>
> So, in order to allow phpunit to be ran, have the firefox/IE support and
> use
> xdebug I have two basic options:
> a) stay with windows, install XAMPP (or any other all-in-one). And live
> with the fact that some things will have to be taken care of (such as
> PATH differences between unix/windows)
> b) switch to linux with the development stack, enable a windows server to
> be
> connected from rdesktop so they can test the IE
>
> In both cases I'll have extra work in order to maintain the developer's
> machine somewhat synchronized with the production server.
>
> Am I missing a third/fourth (better) etc option?

why not switch everything to linux and run IE in wine or vmware on the
developer's machine? that way you don't have to maintain windows machines
at all

greets,
Zoltán Németh

>
> thanks.
>
> On Sat, May 10, 2008 at 8:44 PM, Gabriel Sosa <sosagabriel@gmail.com>
> wrote:
>
>> 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 <david@otton.org> wrote:
>> > 2008/5/10 robert mena <robert.mena@gmail.com>:
>> >
>> >> 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
>>
>

> Or depending on your budget, Switch the developers to Macintosh
> computers, install windows via parallels, and then you can test in
> Mac/Unix/Windows all from 1 computer

And watch everyone quit... :-)

--
Richard Heyes

+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+

Hi Zoltan,

If the windows would be used just for IE I think it's cheaper to have one
windows machine (server 2003/2008), have the users connect via terminal
service (rdesktop). I think it's easier than having to install/maintain
than multiple windows installations, even if it is a virtual machine.


>
> why not switch everything to linux and run IE in wine or vmware on the
> developer's machine? that way you don't have to maintain windows machines
> at all
>
> greets,
> Zoltán Németh
>
>

Unfortunately this is not an option due to budget I use Mac myself (with
VMWare fusion) but would not be feasible to depoly this with all the devel
team.


>>
> Or depending on your budget, Switch the developers to Macintosh computers,
> install windows via parallels, and then you can test in Mac/Unix/Windows all
> from 1 computer
>
>

On May 19, 2008, at 520AM, robert mena wrote:
> So, in order to allow phpunit to be ran, have the firefox/IE support
> and use
> xdebug I have two basic options:
> a) stay with windows, install XAMPP (or any other all-in-one). And
> live
> with the fact that some things will have to be taken care of (such as
> PATH differences between unix/windows)

This is what we do where I work. XAMPP has been configured and put
into Perforce (our revision control system) so anytime a change is
made or we decide to update to a new version of XAMPP, all the devs
need to do is grab the latest version. This makes it very nice when
people need setting something up as we all have the exact same
setup.

We've created some template vhost files for setting up new sites, so
getting a new site setup on the local machine is much easier now,
especially for those devs who still don't know all that much about
Apache. Once a vhost file is working properly, we check it into
perforce so that if we need to reinstall XAMPP later, or if someone
else needs to work on the site it's as simple as getting the latest
version of the file from perforce.

For the path differences, we are starting to move the include_path
setting out of .htaccess where we've been setting it and into the
vhost configuration for the site. Of course this also needs to be done
on the server, but it only takes a couple minutes to do.

I'd much rather be using a Mac or Linux at work and using vmware for
IE testing, but that's not up to me.

> b) switch to linux with the development stack, enable a windows
> server to be
> connected from rdesktop so they can test the IE

I would get feedback from your devs about this before making such a
drastic switch. Personally, I'd love to ditch windows on my box at
work, but I know that some of the devs I work with would not be very
happy about that. It also depends on what software your devs are
using, and if it's available on Linux. Sure, there are alternatives to
everything, but learning to use and becoming efficient with an
alternative isn't nearly as productive as continuing to use the same
tools.

Brady

> Hi Zoltan,
>
> If the windows would be used just for IE I think it's cheaper to have one
> windows machine (server 2003/2008), have the users connect via terminal
> service (rdesktop). I think it's easier than having to install/maintain
> than multiple windows installations, even if it is a virtual machine.

one server is cheaper than multiple vmware windozes, but multiple wine
instances with IE are free.

greets,
Zoltán Németh

>
>
>>
>> why not switch everything to linux and run IE in wine or vmware on the
>> developer's machine? that way you don't have to maintain windows
>> machines
>> at all
>>
>> greets,
>> Zoltán Németh
>>
>>
>