: Best practice for running development and production servers I've been doing web development for some years now and have always questioned my methods when it comes to deploying a site, or doing

@Becky754

Step 1: CYA. Make sure that you have enough backups of the site before deploying that you can absolutely restore from. Do not count on most backup schemes and software too much as they tend to over complicate matters and may not always give you what you want. Practice backing up and redeploying a site as a recovery method. I prefer simple file copies and database dumps. Make sure you have more than one copy and use your deployment notes if need be.

Step 2: Live copy of the site. It is not always possible, but I do like to create live copies of the site. I have a couple of computers I can use for this. Some sites are in directories and one site in particular has it's own machine. This way, I have a working copy of the live site to ensure that a deployment will go well. As I deploy the site changes over the live copy (not the live site but a copy of the site that represents the live site), I make meticulous notes and often use the previous notes as a starting point. Some sites will not need this of course, but you do want to make sure you at least list what has changed as you develop so that nothing escapes your memory. Your live copy server does not have to be much, just enough to represent the live site. I tend to use older reliable computers for this. It does not have to be fast or have a lot of memory. Just enough.

Step 3: Keep a separate development server. This will be what you are using now. You can keep each site in a directory. I sometimes use a directory for coding and just make sure that my deployment notes tell me where I have to make changes to remove any references to the directory. As well, I will occasionally modify the path of the root web directory so that as I work on a site, I do not have to reference the directory at all. Since this is an easy thing to do and only takes seconds, this may be enough for you. You can use this method on your live copy too.

In Total:

It sounds like you have done a fairly good job of things so far. I would just say take what I have written and add what works for you to it.

I used to work in a production environment where there was a development server, a test/user acceptance server (UAT), and the production server. Each development group had a live copy of their website as a part of their development environment unless the work was really simple. At each stage of the way, the development team would test deploying their development onto their live copy. The production team would test the deployment on the test/UAT server, then if all goes well, deploy the site with roll back procedures often a restore procedure that is more manual in nature. This was good enough for a global telecom with over 1000 public facing web servers.

In regard to sub-domains:

I do not like this solution generally, though it can be something to consider. The reason is, the sub-domain will be sniffed out rather quickly and will be available to anyone including search engines unless you find a away to secure it. Others use them as rolling updates where the site is deployed on the sub-domain, tested, and if it all works out okay, then the sites path is changed to use the sub-domain. While this can be done, it is a level of added complexity that may not be necessary and can give headaches from time to time. You have to decide this for yourself.

Simple sites require simple solutions. Do not over complicate things. But do make sure that all your bases are covered and that any deployment goes smoothly for the customer. That is the key. CYA, make sure things go smoothly, and keep the customer happy including the idea of a rollback if necessary.

Vote Up Vote Down