views:

67

answers:

4

I recently launched a service, meaning I can no longer work directly on the site, or I do so at a risk.

I haven't been able to find any "standard" or "best" way to make a development server. The two things I have seen are

a) Using a GIT or SVN to host the data (this doesn't quite solve my problem, I need to be able to develop somewhere, preferably not my home computer)

b) Capistrano (for Rails, is there something for PHP?)


The current solution I'm looking at is putting a complete copy of the server on "development.domain.com", which would then allow me to work on everything, and I can simply copy the files over to the main section.

Is this a workable solution? What's the optimal solution? (Separate server, special tools, etc.)


EDIT This system be developed by a number of developers. The server settings have been tweaked considerably to allow for the full functionality and security of the system. Having the development on my own computer is not a workable solution, nor on an intranet type of system as none of our programmers are in the same location.

I'm looking for an on-a-server solution.

A: 

I started to use a git repository as starting point. Main development is done on my local mac. At a certain point I push the changes and pull them on a development server where further testing is done. If everything is fine, I pull things on the development server. This is more or less the way, capistrano works, I think. I wrote a central script for these tasks, so I can update development or production servers with a single comand.

Juri Keller
Considering this development won't be all by myself and I can't reproduce the server's settings (at least not feasibly)
Kerry
Leveraging a system that supports virtual environments and a shared source repository can easily manage settings. All of the settings are local or can be updated via script. I have used MAMP or WAMP to develop very complex software. You do want to keep your setting dependency low. Create scripts to setup your environment, have people run them. It is worth it!
TheJacobTaylor
Do your part of the development locally with MAMP (or whatever) and check them out on the development server (check here if everything is working fine). The development server should be more or less (the more the better) identical to the production server where the final system will run. If you develop in a team, this is working fine, at least here in our team. Git is perfect for this.
Juri Keller
@Juri -- Right -- but this question is specifically about the development server, not working locally or not.
Kerry
@TheJacobTaylor -- thanks -- will look into it. Still not looking for an on-computer terminal, as I have 3 computers that I personally work off.
Kerry
+2  A: 

http://www.wampserver.com/ for windows

or

www.mamp.info for mac

or

load up a VM

Personally, I do my programming on a mac, running VMWare with suse or redhat for the server test environment. I've used mamp in the past and it works well; but sometimes I like to work in a real operating system.

That, or setup a physical test server. PHP / (choice of DB) now adays runs on anything (mac, windows, linux)

Depending on what how you want to do it, you could install VMWare right on the production server and dev in there; that is, if you run the server yourself. If your collocated or on shared hosting, you probably can't do that.

-Mario

Mario
Everything is hosted on a very secure/powerful server -- trying to duplicate its settings on my computer might be near impossible.
Kerry
The definition of secure and powerful and everyone's personal opinion. Such a definition doesn't exist.
Mario
hit enter before i could finish. If you can't reproduce the settings of the server onto another machine; how will you deal with server failure? Hard Drive failure? A security breach? You MUST be able to reproduce the server. If your concerned about source control, being able to reproduce the server in the event of a catastrophic failure is equally if not more important.
Mario
at the very least, run a disk imaging software on the server and make a ghost image of it. Norton ghost (or whatever symantec calls it now adays), VMware has one that you can turn around and use it in a vm; acronis, etc... theres many out there. New ones (most modern ones) are able to do bare metal restores.
Mario
Our server managers (firehost.com) can duplicate it fine... I don't know if I can personally do that to a local machine, esp. when I'm running windows and it's Linux
Kerry
ok, so according to firehost.com, its a VM. Setup a subdomain (dev.domain.com) or whatever, reproduce your work there and have the developers work out of that. Since its public, protect it with a .htaccess file (in addition to whatever security your code has) and your good to go. Don't forget, just cause your host passed PCI DSS, doesn't mean you did. ssh as root, minimum password security, etc... blah blah blah may be disabled or accounted for on the hosting side, doesn't mean your code is secure. go search for owasp and test your code yourself if security is a concern.
Mario
+1  A: 

Your development, staging, and production environments should be exactly the same otherwise you risk the change of something bombing as you move between environments. Obviously your development environment will have development settings (e.g. PHP's display_errors on, possibly a remote debugger, etc) but otherwise they should be as identical as possible.

As everyone else has mentioned if you aren't using version control you as asking for trouble. Not only is this a good practice for development but also eases deployment between your different environments. This is especially true when there are multiple developers working on a project.

KayakJim
I would argue there is a need for the testing and production environments to be nearly identical while the development environment can safely be quite different.
meagar
+2  A: 

Three suggestions:

1) You are on the right track with making sure that your source code is in some form of source control (git and svn are both excellent choices). This should be priority #1.

2) Have EVERYTHING that has deviated from a standard configuration be in some form of source control. This means your apache configs, your php.ini, database configs, etc. Then when you setup your staging and dev servers you can be (relatively) assured that everything is the same across all of your servers, otherwise you are just guessing.

3) Look into some sort of build scripts, either ant, phing, or anything that you can use to reliable build your environment from scratch on any machine.

There are tons of other things you can do, but if you implement these three you'll be well on your way to having the ability to easily setup a dev/staging server. This will also give you the added benefit of ensuring that all of your developers have a similar environment when doing their development as well.

jsuggs