What is the more efficient setup of the dev / test / prod environment for developing PHP ..?

Question

Unfortunately, I have never had a senior developer or mentor to show me some of the best practices. Therefore, I develop sites (php / mysql) on my Windows machine using WAMP, I test hidden (password-limited) folders on the production server, and finally move the sites to the production folder.

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

Important points / questions (you can probably come up with a lot more):

• Ease of use
• Ease of development / testing after the site is live (to avoid tests on the production site).
• There is no difference in the server between local / test / prod (error reporting, apache settings, etc.)
• Avoid problems with differences in DB (for example: if columns have been added, how to add them to the prod database)?
• Are you skipping the test environment or doing the dev AND test for the same thing.?
• etc...

How do you guys design PHP / MySQL. Websites?

Do you use SVN? Do you use an IDE? Do you use virtual machines?

Thanks.

Answer 1

This is a kind of frequent question — that’s why most experienced developers don’t answer them — and generally end in a fiery war with heated opinions. So be careful.

But you seem to be a good guy, intending to go the right way, looking for some really productive ways. And a few years ago I found out a little about myself.

Well, the first thing to keep in mind is: do not watch anyone for anything. Anyone can pretend to be a great master, but you can find at least 10,000 guys much better and completely anonymous. So, for everything that you hear, do the following: listen, check and draw your own conclusions . If there is only one golden rule, it is. Everything else is crap until your own conclusions appear. You are your last judge.

However, let me start with one of the most pressing issues: the IDE. What should you use? You must use one that you can produce more and makes you more comfortable. Netbeans, Eclipse, VIM, Notepad ++, Notepad, gedit, kate, quanta plus .... You have many options, and each has its own opinion. Experience what you find interesting and continue what you choose.

This is true for any methodology, structure or tool. Use, learn and shout about it. Stick to what makes you more comfortable and productive.

The same goes for the development environment. It doesn’t matter if you are running on Windows, Mac or Linux. Getting the necessary resources is important. The necessary resources can and usually vary from one project to another.

Thus, the best environment for developing a specific project is one that reflects the real environment in which production will operate. What if you develop PHP 5.3 OOP resources and end up with PHP 5.1? This is the point. The ultimate environment is who tells you which is the best development environment, not the reverse.

For testing, you should follow the strategy. I talk about this as a 5 year experience at IBM. This is because there are many tests that you can perform, but not all can be really interesting for the current project.

First decide, according to the needs of the project, what you are going to test. Security, performance, UI mapping, UI effects, error handling, loading and balance, usability, accessibility ...

Take notes on what you are going to test (what, when, where, success criteria), and report on successes and failures.

As I said, the needs of the project are what guides you at every step. Testing is no different. If you just need to check the display in different browsers, feel free to use different machines or virtual machines.

In the general case, this is enough. But if a project requires performance or load testing, you will need special load testing programs. I will not delve into this topic because it is very extensive.

It takes some time to find the perfect process and tools, and after that you will always find a new testing tool or process so that you can save a little time. This is IT.

Answer 2

Here are my recommendations:

• have a dev environment exclusively for development. keep an intermediate and / or live environment based on your resources. An intermediate environment is the place where you review and ensure that there are no serious problems with your application. living environment is basically your production facility. in fact, the production and the concert should ALWAYS be the same. It is useful to reproduce problems at the stage and perform some troubleshooting operations without changing the code. Remember that this is also true for any related databases.

• Use SVN or some form of version control. Thus, you will have the opportunity to return to any stable version of the application if the world ever falls apart!

• If you use Linux environments, you can write simple scripts to synchronize the installation with your latest (STABLE) development environment. Ideally, you carry out your development and conduct unit tests to ensure that everything works according to design. Run the script and the middleware is updated with the latest code base. Carry out functional tests during the installation and make sure that everything works according to the specifications. Run another script and your latest changes will be transferred to the live / production environment.

Answer 3

My development process is still a little rude, and I look forward to the answers.

What I am doing for large projects is setting up git repo on the Linux desktop and my Windows desktop. I will check locally if possible. As the components are separated, I will redirect my changes to the centrally hosted git repository (private git account) or pull it into dev (I install dev as a repo and pull from ssh). All MySQL updates are stored in update files, and I use netbeans for development (although I used eclipse and others, netbeans just works for me).

Answer 4

I think you attacked all the important points. I personally

• run the same OS and server software on the production server and my development system. The same versions of PHP, Python, MySQL, Django, etc.
• I do not often change the structure of the database. I installed DB tables on dev. then use mysqldump to create the SQL table creation file. I install it on the server using mysql <name_of_sql.file . When I make the changes, I back up the database and then simply execute it through the command line interface. For PHP, I use Doctrine only to support table / migration structure.
• I write everything in Kate (Linux), Komodo Editor (Mac) or Notepad ++ (Windows). I do not really like the IDE, I prefer text editors.
• I upload the files to the staging directory and check them with diff before copying them to the actual location.

This is not the most difficult setup, but for me it was very good. I am the only developer who works on projects with which I am associated, which probably explains a lot. The most important part, which is not really a personal preference, is the first - it is compatible with your dev / test system as close to the production system as possible, including the OS.