What is the more effective dev/test/prod environment setup for PHP development..?

Question

Unfortunately, I've never had a senior developper or mentor to show me some of the best practices. So I develop sites (php/mysql) on my Windows machine with WAMP, I test in hidden (password restricted) folders on the production server and finally move sites to production folder.

I would like to have a more fluid/practical/error-proof setup so that from development > test > production, there is no hiccups.

The important points/questions are (you probably can come up with a lot more):

• Ease of use
• Easy to dev/test modifications after site is live (to avoid tests on production site)
• No server difference between local/test/prod (error reporting, apache setting, etc)
• Avoid problem with DB differences (ex: if columns were added, how do you add them to prod DB.?)
• Do you skip the test environment or do dev AND test on the same.?
• etc...

How do you guys develop PHP/MySQL websites.?

Do you use SVN.? Do you use IDEs.? Do you use VMs.?

Thanks.

Answer 1

My development process is still a bit rough, and I am looking forward to the answers also.

What I do for large projects is setup a git repo on my linux desktop and my windows desktop. I will test locally if possible. As components as finishinged I will push my changes to the centrally hosted git repo (private git hub account usually), or pull them to dev (i setup dev as a repo and pull from ssh). All MySQL updates are stored in update files, and I use netbeans for development (although I have used eclipse and others, netbeans just works for me).

Answer 2

Here's my recommendations:

• have a dev environment purely for development. keep a staging and/or a live environment based on the resources you have at your disposal. the staging environment is where you test and ensure there are no serious issue(s) with your application. the live environment is basically your production setup. in fact, the staging and live should ALWAYS be the same. It is useful to reproduce issue(s) on the staging and do a bit of troubleshooting without modifying the code. Bear in mind, this also holds true for any associated databases.

• Use SVN or some form of version control. This way you will have the ability to fall back to any stable version of the application if someday the world falls apart!

• If you are using Linux environments you can write simple scripts to synchronize the setup with your latest (STABLE) development environment. Ideally, you do your development and conduct unit tests to ensure everything works as per design. Run a script and the staging environment is updated with the latest codebase. Conduct functional tests on staging and ensure that everything works as per specs. Run another script and your latest changes are moved into live/production environment.

Answer 3

This is a kind of frequent question - this is why most seasoned devs do not reply on - and generally end up in a flame war with torrid opinions. So, be careful about that.

But you seem to be an nice guy intending to get on the right paths, seeking for some really productive paths. And I recognize a little about myself on this a few years ago.

OK, first thing to keep in mind is: do not blind follow anyone on anything. Anyone can claim to be a great master, but you can find at least 10.000 guys far way better and completely anonymous. So, for anything you hear about do the following: listen, test, and take your own conclusions. If there is just one golden rule this is it. Everything else is crappy until your own conclusions appear. You are your final judge.

That said, let me begin for the one of the most current question: IDE. What you should use? You should use the one you can produce more and makes you more comfortable. Netbeans, Eclipse, VIM, Notepad++, Notepad, gedit, kate, quanta plus.... You have many options, and each person has it's own opinion. Test what you think interesting and go ahead with the one you choose.

This is true also for any methodology, framework or tool. Use, learn, and get critic about it. Stick with the one which makes you more comfortable and productive.

Same thing for developing environment. Does not matter that much if you develop on Windows, Mac or Linux. The important is get the resources you need available. The resources you need can and generally do change from one project to another.

So the best environment to develop a certain project is one that reflects the real environment where the production will run. What if you develop with PHP 5.3 OOP resources and at the end you get on a PHP 5.1? That's the point. The final environment is who tells you what is the best environment to develop, not the inverse.

For testing, you should trace a strategy. I'm talking about that as a 5 years Test Team Lead inside IBM. This because there are a LOT of testing you can perform, but not all can be really interesting to the current project.

First decide, according to project needs, what you are going to test. Security, performance, UI display, UI effects, error handlings, load and balance, usability, accessibility...

Take notes of what you are going to test (what, when, where, success criteria), and make a report of success and failures.

As I said before, the project needs is what guides you on every step. Testing is not different. If you just need to check the display on different browsers, feel free to use different machines, or VM's.

Generally this is sufficient. But if the project requires performance or load testing, then you will need specific load testing softwares. I will not get deep in this subject as it is very extensive.

It takes some time to find a ideal process and tools match, and after achieve that, you will always discover a new tool to test or a process to make you save a little time. This is IT.

Answer 4

I think you hit on all the important points. Personally, I

• run the same OS and server software on the production server and my development system. Same versions of PHP, Python, MySQL, Django, etc.
• I don't change DB structure often. I set up the DB tables on the dev. system, then use mysqldump to produce the table creation SQL. I install it on the sever using mysql <name_of_sql.file. When I do make changes, I back up the DB and then just do it through the command line interface. For PHP, I use Doctrine just for the table structure/migration support.
• I write everything in Kate (Linux), Komodo Editor(Mac), or Notepad++ (Windows). I don't like IDEs very much, I much prefer to-the-point text editors.
• I upload files to a staging dir, and check them with diff before copying them to the actual location.

This isn't the most sophisticated set up, but it's worked quite well for me. I'm the only dev working on the projects I'm involved with, which probably explains a lot. The most important part, that isn't really just personal preference, is the first one - match your dev/test system as closely to the production system as possible, including the OS.