How can I improve my development and deployment strategy?

Question

I am working on a web application that runs on the LAMP stack (Linux Apache Mysql PHP), and I need some recommendations for improving my workflow.

I have 3 environments:

• My local machine AKA my development environment
• Intermediate account on my dedicated server so I can test the web application
• Active products on my dedicated server

I do all the development on my local computer and use the subversion server, which is located on my dedicated server. I set the script hook so that whenever I make a transaction, my intermediate account is updated with new code.

From time to time, I make sure that everything works fine on the intermediate account and pushes the changes to my production account using a small script.

This works pretty well, for the most part, but there are a few annoyances:

• My domain name is hardcoded in several places, which makes it time consuming to switch between environments. I can change the hosts file manually, but it is not very fast, and it does not work for 2 accounts (prod / staging) on ​​the same server.

• I do not support database updates in all three environments. I could use the same database for all environments, but I would have to risk ruining the production environment.

So my question is: what can I do to mitigate these problems?

UPDATE: The hard-coded domain problem is introduced by third-party software, and therefore “non-hard-coded” is not currently an option.

Answer 1

Ideally, you would like the production to be an exact copy of the product. Thus, what you see in the production can be pretty sure what you will see in the production process. Automatically clicking on the stage when you commit will not do this, since any errors that you enter with the commit are instantly sent to the stage.

What you may wish for is to set up a different environment and call it testing. This will be your automatic click on commit. Use this environment to run QA, and from there you can pack the code and press push to perform the final test. If everything goes well at the stage of setting, then click on the package for production.

As for the problem with the domain name, I would recommend not hard-coding them if you can handle it. Or at least use subdomains for different environments to make it easier to determine which software environment you are in.

In order for your database to be updated in different environments, you may want to periodically dump from production and update the experience, testing and dev environment with this dump. Once a day you need to work. Thus, you develop and test what your users see in the production process.

Answer 2

As for your last pair of points, the obvious solution seems to (1) not require hard-coding the domain anywhere, or if you should at least split it into one “local settings” file that is not updated via SVN; (2) write a script to synchronize the databases (for example, copy production data to the stage and / or your local environment, of course, not vice versa) and run it from time to time.