Geek Answers Handbook

PHP MySQL and proper development / configuration before sending to the production server

I just launched my production site. I still have a lot of work, and now I understand what is needed for the development server, before pushing changes at the workplace (with users) - obviously ...

This topic (and much more on Stack) describes me: Best / Best / Best Way to Set Up a Stage / Development Server

Anyway ... Reading these threads is directly confusing from time to time, with all the terminology thrown around and my lesser knowledge of CentOS / Apache.

My goal:

  • If necessary, make some changes to the files.
  • Check the changes on the same server to make sure the settings are identical.
  • If everything is in order, now I can save the version of this place, maybe there is enough space at the moment (does Bazaar seem like such an opportunity?)
  • Finally, replace all modified files via SSH or SFTP or something like that.

My worries:

  • Download changes when users are logged in.
  • How to download only those files that have been modified.

I would very much like someone to contact the great guide, what I think (which leaves nothing to imagine what I hope for) - or some suggestion / etc ... I run in circles try out various SVNs and progarms to manage them, etc.

I am the only one developing and just want a repeatable, trustworthy solution that can work for me without making my life too pathetic, trying to set it up (and save it).

Thank you very much.

+4
source share
4 answers

Thanks to everyone for the tips / hints / etc.

I finally found the perfect solution for my needs, SpringLoops ... http://www.springloops.com/v2/

It manages my SVN (which I use SVN Tortoise) - and will actually implement changes to my two sites: production and production.

I highly recommend it works wonderfully so far.

Thanks!

+1
source

If you have the opportunity to create an intermediate subdomain on a production server, here is how I would (and did) process it:

Develop on your development machine by storing your code in VCS. I use subversion, but you can find another one that you prefer. After making the changes, you check your code.

On your production server, you create a subdomain in Apache VirtualHost that is identical but isolated from your VirtualHost product. Issue your code from VCS to the intermediate domain of a subdomain. After making the changes, you then start the update from your VCS, which pulls out only the changed files. Installations and manufactures have the same data set, or you may have a separate database for each.

The reason for using a subdomain instead of just another directory is that it allows you to use the same DocumentRoot for production and production. It is also easy to determine where you are if you use something like staging.example.com .

When you are sure that everything works as it seems to you, you can run the VCS update on the production side to update the code.

It is important to make sure that you tell Apache to deny access to VCS metadata directories (.svn, .git, whatever).

Adding

To restrict access to .svn directories, use a rewrite rule, for example:

 RewriteEngine on RewriteRule .*\.svn/.* - [F]

This will send 403 to them. You can also redirect them to the main page to make it less obvious, even if they are present.

+3
source

In terms of concern # 1, remember that even StackOverflow is periodically disabled for maintenance when people use it. Just provide a good mechanism for switching the site to maintenance mode (and vice versa), and everything will be fine.

+1
source

You need a version control system like Subversion, Git, or Mercurial.

When changing files, you make these changes to the repository. This keeps track of all the changes you have made and allows you to undo them if it turns out that you did something stupid. It also allows you to recover files that you accidentally deleted or lost.

In addition, it makes deploying updates as simple as typing 'git update' or 'svn update' on a production server. Only files that have been modified are transferred and put in place.

You will receive this advice no matter how many times the question is re-asked. You need version control.

0
source

More articles:


All Articles